You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by m....@gmx.de on 2002/09/20 10:30:11 UTC
?Bug in width calculation?
> Kevin Yeung wrote:
> > I am having troubles with long strings and table cells.
>
> The common approach is to put zero width spaces into
> the product number in order to give FOP a chance to
> break the line. Note that 0.20.4 appears to have a bug
> in the width calculation, you'll probably have to get
> the code form the CVS maintenance branch.
> But see also the thread about hyphenation.
>
> J.Pietschmann
I am trying to solve a problem wich could well be connected with some width
calculation. Could you please point me to the bug your quoting?
--
Thanks a lot!
Markus Schäffler
------------------------------------------------------
Werden Sie mit uns zum "OnlineStar 2002"! Jetzt GMX wählen -
und tolle Preise absahnen! http://www.onlinestar.de
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: ?Bug in width calculation?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
m.schaeffler@gmx.de wrote:
> I am trying to solve a problem wich could well be connected with some width
> calculation. Could you please point me to the bug your quoting?
The problem is that all Unicode spaces which don't have
a glyph in the selected font (i.e. none other than  )
get the with of "#" assigned if the "#" character has
a glyph in the font.
All other unmapped characters also get the "#" width,
or the width of the character which happens to have
to code 0x23, but usually this doesn't matter because
you'll see the wrong character in the PDF.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org