The problem is a rounding matter rather than ceiling values. Try this: i-p-d1 = 22cm + 1cm (gives 595275mpt) i-p-d2 = 21cm + 2cm (gives 595274mpt)
i-p-d2 - i-p-d1 will give a non-zero value after conversion to mpt (with only 2 terms in formula) For example, that can occur when alternating the margins of region-body. Cf. https://issues.apache.org/bugzilla/show_bug.cgi?id=53163 2012/9/25 mehdi houshmand <[email protected]>: > We're digressing from the remit of fop-users, so I've posted to fop-dev. > > I must confess, my understanding of the layout-engine side of things is > limited; I don't think I have a full appreciation of the intricacies and the > nuances. Maybe another of the devs will have more constructive feedback, > however, I'm still not convinced that replacing integers with longs will > necessarily help. As I said previously, the integer range allows up to 29826 > inches!!! Why would anyone create a document that's 1/2 a mile long? > > As for the rounding thing, I don't really have much useful input on that, my > understanding of the layout engine just isn't mature enough for me to form > an informed opinion. > > On 25 September 2012 08:44, Pascal Sancho <[email protected]> wrote: >> >> Hi, >> >> Regarding the length format, what is not good is rounding at computing >> time. >> Integer remains acceptable at rendering time. >> My first idea was to replace fop native unit (mpt) with one that >> should give always an integer value after conversion, but that doesn't >> cover the case when division is made (for example, 1in div 3). >> So, an acceptable design shouldn't be?: >> - compute and store length as long >> - introduce a tolerance for equals() >> - cast to integer for renderer >> WDYT? >> >> 2012/9/25 mehdi houshmand <[email protected]>: >> > 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 <[email protected]> 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 <[email protected]>: >> >> > 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 <[email protected] >> >> >> <mailto:[email protected]>> 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 >> >> >> <[email protected] <mailto:[email protected]>> 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
