victoriavargas updated FOP-1690:
    Attachment: h13-623-Exam-Dumps-2019.pdf

> int overflow with large font size values
> ----------------------------------------
>                 Key: FOP-1690
>                 URL: https://issues.apache.org/jira/browse/FOP-1690
>             Project: FOP
>          Issue Type: Bug
>          Components: font/unqualified
>    Affects Versions: trunk
>         Environment: Operating System: All
> Platform: All
>            Reporter: Jeremias Maerki
>         Attachments: h13-623-Exam-Dumps-2019.pdf, 
> h13-623-Exam-Dumps-2019.pdf, svg-text.fo
> A rather nasty bug: In XSL-FO, we usually have font sizes under 11'000 points.
> No problem. Switch to SVG and define a viewBox with relatively high values and
> you can quickly end up with a font size of 11'000 (units not points). It
> happened to me when I ran an SVG that was produced by the SVG document handler
> in the FOP sandbox. That one just sets up FOP's internal millipoint coordinate
> system in SVG. No SVG editor/viewer has a problem with that.
> So, the problem is, for example, the generated Helvetica class' getWidth(int 
> i,
> int size) method which returns an int. Multiply a number in the 1000 range 
> with
> the font size that has been multiplied by 1000 (pt -> mpt conversion for 
> normal
> FO).
> 950 * (1000 * 11000) = 10450000000 (0x26EDE5880)
> That result is bigger than a 32-bit int.
> For comparison, the usual case in FO:
> 950 * (1000 * 11) = 10450000 (0x9F7450)
> I've locally added long variants of the problematic methods (getWidth() ->
> getWidthLong()) to see if this really solves the problem and it does indeed.
> Just replacing int with long everywhere is not a good idea because of
> backwards-compatibility. We know that some people are using these classes
> outside of FOP. To me, the additional long variants look like the cleanest
> solution, but maybe someone has a better solution.

This message was sent by Atlassian JIRA

Reply via email to