Re: Zero width space isn't zero in Acrobat 5, is zero in fop viewer

["J.Pietschmann" <j3...@yahoo.de>]

Keiron wrote:
>>Richard Bondi wrote:
>>>Is this an Acrobat bug or an fop bug? If I send the code below to the 
>>>fop awt viewer, the zero width spaces are indeed zero width; if I send 
>>>them to a pdf and open it in Acrobat, they are not.

Got it: the getCharWidth() code in the line area formatting
lets the font map the char, and because the standar fonts
don't have a mapping, they return "#". All U+200* spaces
therefore get the same width as a "#".
Another instance of things biting back.
I think I'll fix this by checking spaces if the mapped
character is "#" but the original was not.

> The hair space should be "thinner than a thin space" and thin space is
> em/5.
> The zero width space should be zero (it appears 0 has a special meaning
> at the moment, this needs to be changed).
There are other anomalies, for example U+2003 gets
currentFontState.getFontSize(); assigned which seems
unprudent (the font size is in points, isn't it?).

I think I'll change
  2002 -> en (was em/2)
  2003 -> em (see above)
  200A -> em/10 (was 5)
  200B -> 1 (was 100)

> It [zero width space] can expand with
> justification unless the xsl spec overrides this.

This strikes me rather unintuitive, a fixed width space should
not expand for justification. I vaguely remember to have read
exactly this (the U+200B ZWS can expand) in one of the Unicode
papers though... Do I remember correctly the width of U+FEFF
is fixed to zero?

Actually, in FOP *all* spaces except those in leaders or used
for leader alignment are resizable, despite comments claiming
for example that non-breaking spaces all have the standard space
width.
Which spaces should actually be treated as fixed?

J.Pietschmann