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