While you may be right Pascal, I'm sure this isn't a good example of a legitimate use-case. But then what do we use? A long? Then what have we really done? Realistically we're just moving the boundaries from which FOP accurately displays text/images etc.. What I'm asking is why would a long be any more appropriate than an int?
This use-case is not a legitimate use-case in my belief. I appreciate Matthias, you said that Corel Draw (I didn't even know that was still going) was used to create it, but there must be some settings in Corel Draw to decrease the canvas or similar. The image is being drawn on a ludicrously large canvas and then scaled down... If your concern is the rounding issue, I'm not sure there's necessarily an easy solution. Though PostScript and PDF support decimal numbers, some formats e.g. AFP don't have a native concept of floating-point numbers. But that's a whole 'nother can of worms. I've made my thoughts on the issues with FOP's cavalier attitude towards rounding in AFP clear previously in a bug report. On 25 September 2012 08:11, Pascal Sancho <psancho....@gmail.com> wrote: > 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 > >