Hi,

1st, this discussion should move to fop-dev list now.
2nd, there is definitively some issues that are due to length handled
as integer (char width you pointed here, i-p-d changes from page to
page because length is rounded when it result in float value (metric
to imperial conversion,  divisions, etc.)
So, I wonder whether integer is the appropriate type for length values
(I'm sure it is not).

2012/9/24 Matthias Reischenbacher <matthias8...@gmx.at>:
> 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

-- 
pascal

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org

Reply via email to