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 <psancho....@gmail.com> 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 <med1...@gmail.com>:
> > 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
>
>

Reply via email to