Apache OpenOffice (AOO) Bugzilla – Issue 12697
non-printing chars not aligned right between Chars in 1.1Beta
Last modified: 2003-09-24 13:14:41 UTC
nothing to describe. In 1.0.2 non printing chars appear neatly between the characters, in 1.1 it seems they've shifted to the right, enough so to make the display ugly and hard to read. Very problematic for anyone who works with text a lot.
Appearance is fine, placement OK in the Linux version. This may be specific to the Windows version...
Could you pleaase attach a screenshot which show the problem? Thanks.
Created attachment 5399 [details] screenshot
hi. uploaded screenshot, of very enlarged display, so you can see the effect. this is on win2k, sr3, ati all in wonder pro 128 AGP, with NEC Multisync LCD1700v. the dots in between characters are shifted right as compared to 1.0.2, where they were nicely in between the characters, and plainly visible, right now, even with non-printing on it is sometimes hard to see if you do or don't have a space, because the dots merge with the characters some times.
this issue may be related to certain (proportional?) fonts. I'm just reviewing a document in Courier New, and there the display of the non-printing characters is fine. I hope that info helps...
Created attachment 5406 [details] Screen dump 1.0.1 compared to 1.1 Beta
Appearance is *not* fine in Linux !! (rather: ugly). And nothing to do with strange fonts. Find included two screen-shots, same document, same size, opened at the same time with 1.0.1 and 1.1Beta on the same machine. Look at "that foreign language as objective" in the center of either! In Beta 1.1 it rather reads "foreign lan gua geas objective". In print it is worse; the paper is not printable. (I didn't do a scan, though) This is due to the fact, that in 1.1 Beta bold words following a blank are advanced into (!!) the previous un-bold word and print over the last char of that unbold word. Only in Beta 1.1; again; while the same file prints nicely in 1.0.1. Running RedHat 8.0; rather out of the box, installed according to ./install and setup.
Created attachment 5408 [details] Character Definitions for previous shot (5406)
HI->US: Especially the space-dots are very close to the letters.
Not reproducible.
Fail to understand the comment "not reproducible" I do copy editing, and this feature is killing me. It does depend on the fonts however, but I work on a nec multisynclcd1700V, in 1280x1024, and still can hardly see the space dots clearly with a great many fonts. So if this falls back till 2.0, I'd say see you at 2.0 (maybe).
pls. state which fonts are affected, attach a bugdoc and at least one of the affected fonts. US->HI: if you were able to reproduce this issue, pls. take care for this one and retarget to 1.1 Beta2 if appropriate.
There is another issue that is possibly related: Not only is the problem so severe that there are a number of fonts I cannot use in OpenOffice because of these display problems. With some fonts it is also impossible to "hit" the yellow notes and mark them for deletion, whereas with other fonts it is easy. I suspect this is merely another form of the same problem, and I think that if you think you can put this off till 2.0 you're making a really grave mistake.
HI->HDU: I think it is another Fontreplacement story. Please have a look for it.
Depends on issue 13779
Fixed in CWS vcl15.
HDU->US: please verify (related to #110745#)
HDU->US: Forget the comment above, #110745# isn't related enough. The problems shown in the screenshots with the shifted glyphs that Uwe confirmed is fixed in recent versions, if the font used has MidDot- (U+00B7) and Paragraph-Signs (U+00B6). In some related situtations the problem could reappear though: a) If the width of a font's MidDot sign is different from its Space sign (U+0020) b) If the font used doesn't have a MidDot or Paragraph-Signs and the font which is used to rescue these signs has a different MidDot width than the space of the original font. (example: SunSans) An easy workaround is to install and use a font that has the required characters and the MidDot has the correct width. HDU->FME:To optimally place the MidDot even in the cases a) and b) described above the difference of their widths needs to be taken into account to center them. Should we open a different issue for this? It would have quite a similar title and description to this one except that this issue would focus on fonts which show width differences.
FME->HDU: Yes, please submit a new bug for any remaining issues. If this is only a very rare special case, it should get a lower priority.
The gsl fixes for this issues are in >= CWS vcl15, the Writer fixes are to be handled in newly submitted issue 18215, as suggested by FME. Since this issue is about the gsl part I suggest to close it.
HDU->FME: since issue 18215 blocks this issue it cannot be verified and closed, so I think the most appriate status for this issue is to be assigned to you until issue 18215 is fixed. When it has been fixed please reassign also this issue to QA for verification and closing.
As suggested by FME, since everything remaining is handled in issue 18215 I'm closing this one.
.
closing