[
https://issues.apache.org/jira/browse/FOP-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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
(v7.6.3#76005)
