Hi Mehdi,
thanks a lot for having a closer look! You pointed me in the right
direction and I managed to read the char width with the "long" data type
and cast to int after the conversion back to pts. Since this is more a
hack than a definitive fix, I'll don't create a patch for now. What do
you think of converting all font size related variables from int to
long? I didn't do so because a lot of code would have to be modified and
I'm not sure how this would impact memory consumption.
I'm not in full control of the SVG creation (files are exported from
Corel Draw), that's the reason why the SVG file is a bit odd. Normally I
don't use <fo:instream-foreign-object/>, that was only for providing a
more compact test case.
Thanks again for your help & best regards,
Matthias
On 24.09.2012 06:14, mehdi houshmand wrote:
Ok... This one's a tricksy little badger. Basically, because you're
using a font-size that's so large (especially when you convert pts ->
mpts as FOP works in) we're basically seeing an integer-overflow issue:
2579 pts = 2579000 mpts
833mpts = width of "M" glyph in Helvetica
In Java (read: 32-bit integers), try 2579000 * 833, the result
is -2146660296, it should be 2148307000. This means when FOP attempts to
draw the glyphs with the appropriate kerning, an erroneous value is
being given as the glyph-width of the "M" character. I'm not really sure
if this is a bug, there's always going to be a limitation on the size of
the document FOP can produce because we have to work with integers that
can overflow, if that limitation is 2147483648 / 1000 / 72 inches
(or 29826 inches), I think we have enough scope there to feel assured
that we're within the bounds of reasonable use.
If you need any help changing your document to be a bit more
FOP-friendly, please feel free to ask any further questions and I/we
will try and help as much as we can.
Hope that helps,
Mehdi
On 24 September 2012 09:38, mehdi houshmand <med1...@gmail.com
<mailto:med1...@gmail.com>> wrote:
Hi Matthias,
I've just taken a quick look at this and I'm not really sure what
you're attempting to do here. Why have you made the viewBox so large
and then put scale to fit on the "<fo:instream-foreign-object>"? You
can reduce the size of the view box such that you don't need to
scale-to-fit the SVG image. Is there any reason why you're trying to
use such large fonts sizes and drawing space?
I'm going to look into why the kerning on that "M" is so far off,
but you may be able to work around this issue.
Thanks
Mehdi
On 24 September 2012 03:20, Matthias Reischenbacher
<matthias8...@gmx.at <mailto:matthias8...@gmx.at>> wrote:
Hi,
one of my clients reported a strange problem with SVG text being
misplaced in PDF output when very high font size values are
used. The sample SVG file also uses very high viewBox values. I
created a test case which reproduces the issue when increasing
the font size from 2578pt to 2579pt: suddenly the characters are
misaligned.
The issue doesn't occur when outputting PNG or PS files, so
perhaps this is only related to the PDF code. I've been
debugging for several hours, but I can't find the cause.
I'm attaching a fo file which reproduces the issue and the
current PDF output. Perhaps someone can have a look at it and
tell me which code part I should check, in order to fix the issue.
Thanks for your help.
Best regards,
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail:
fop-users-unsubscr...@xmlgraphics.apache.org
<mailto:fop-users-unsubscr...@xmlgraphics.apache.org>
For additional commands, e-mail:
fop-users-h...@xmlgraphics.apache.org
<mailto:fop-users-h...@xmlgraphics.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
