Issue 12697 - non-printing chars not aligned right between Chars in 1.1Beta
Summary: non-printing chars not aligned right between Chars in 1.1Beta
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 1.1 Beta
Hardware: Other Windows 2000
: P3 Trivial (vote)
Target Milestone: OOo 2.0
QA Contact: issues@sw
Depends on: 18215 13779
  Show dependency tree
Reported: 2003-03-26 21:40 UTC by vliscony
Modified: 2003-09-24 13:14 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

screenshot (3.75 MB, image/gif)
2003-04-01 16:10 UTC, vliscony
no flags Details
Screen dump 1.0.1 compared to 1.1 Beta (170.87 KB, image/png)
2003-04-02 05:26 UTC, udippel
no flags Details
Character Definitions for previous shot (5406) (159.84 KB, image/png)
2003-04-02 05:38 UTC, udippel
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description vliscony 2003-03-26 21:40:29 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 
Comment 1 settantta 2003-03-28 04:55:15 UTC
Appearance is fine, placement OK in the Linux version. This may be
specific to the Windows version...
Comment 2 h.ilter 2003-04-01 09:53:55 UTC
Could you pleaase attach a screenshot which show the problem? Thanks.
Comment 3 vliscony 2003-04-01 16:10:26 UTC
Created attachment 5399 [details]
Comment 4 vliscony 2003-04-01 16:12:53 UTC
hi. uploaded screenshot, of very enlarged display, so you can see the 

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.
Comment 5 vliscony 2003-04-01 18:18:32 UTC
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...
Comment 6 udippel 2003-04-02 05:26:18 UTC
Created attachment 5406 [details]
Screen dump 1.0.1 compared to 1.1 Beta
Comment 7 udippel 2003-04-02 05:26:44 UTC
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.

Comment 8 udippel 2003-04-02 05:38:34 UTC
Created attachment 5408 [details]
Character Definitions for previous shot (5406)
Comment 9 h.ilter 2003-04-09 15:53:13 UTC
HI->US: Especially the space-dots are very close to the letters.
Comment 10 ulf.stroehler 2003-04-14 09:46:54 UTC
Not reproducible.
Comment 11 vliscony 2003-04-14 12:56:19 UTC
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).
Comment 12 ulf.stroehler 2003-04-14 13:17:50 UTC
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.
Comment 13 vliscony 2003-04-15 06:48:24 UTC
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.
Comment 14 h.ilter 2003-04-28 10:48:08 UTC
HI->HDU: I think it is another Fontreplacement story. Please have a 
look for it.
Comment 15 2003-04-30 06:59:58 UTC
Depends on issue 13779 
Comment 16 2003-08-08 09:31:18 UTC
Fixed in CWS vcl15. 
Comment 17 2003-08-08 09:34:05 UTC
HDU->US: please verify (related to #110745#) 
Comment 18 2003-08-08 13:01:20 UTC
HDU->US: Forget the comment above, #110745# isn't related 
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: 
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. 
Comment 19 frank.meies 2003-08-08 16:04:41 UTC
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.
Comment 20 2003-09-24 12:47:56 UTC
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.
Comment 21 2003-09-24 12:59:00 UTC
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.
Comment 22 2003-09-24 13:12:53 UTC
As suggested by FME, since everything remaining is handled in issue
18215 I'm closing this one.
Comment 23 2003-09-24 13:13:38 UTC
Comment 24 2003-09-24 13:14:05 UTC
Comment 25 2003-09-24 13:14:41 UTC