Summary: int overflow with large font size values
--- Comment #0 from Jeremias Maerki <jerem...@apache.org> 2009-08-04 10:34:45
Created an attachment (id=24099)
FO File that demonstrates the int overflow problem
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
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.
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.