You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Pascal Sancho <ps...@gmail.com> on 2012/09/25 09:11:25 UTC
Re: SVG text misplaced
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 <ma...@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 <med1985@gmail.com
>> <ma...@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
>> <matthias8283@gmx.at <ma...@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
Re: SVG text misplaced
Posted by Pascal Sancho <ps...@gmail.com>.
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 <me...@gmail.com>:
> 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 <ps...@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 <me...@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 <ps...@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 <ma...@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 <med1985@gmail.com
>> >> >> <ma...@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
>> >> >> <matthias8283@gmx.at <ma...@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
Re: SVG text misplaced
Posted by mehdi houshmand <me...@gmail.com>.
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 <ps...@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 <me...@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 <ps...@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 <ma...@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 <med1985@gmail.com
> >> >> <ma...@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
> >> >> <matthias8283@gmx.at <ma...@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-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
Re: SVG text misplaced
Posted by Pascal Sancho <ps...@gmail.com>.
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 <me...@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 <ps...@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 <ma...@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 <med1985@gmail.com
>> >> <ma...@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
>> >> <matthias8283@gmx.at <ma...@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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: SVG text misplaced
Posted by mehdi houshmand <me...@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 <ps...@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 <ma...@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 <med1985@gmail.com
> >> <ma...@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
> >> <matthias8283@gmx.at <ma...@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-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
Re: SVG text misplaced
Posted by mehdi houshmand <me...@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 <ps...@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 <ma...@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 <med1985@gmail.com
> >> <ma...@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
> >> <matthias8283@gmx.at <ma...@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-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>