DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6474>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6474 FOP doesn't handle non-integer font-sizes (e.g. 10.5) correctly. Summary: FOP doesn't handle non-integer font-sizes (e.g. 10.5) correctly. Product: Fop Version: 0.20.2 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] While examining my bug #6458, I found that FOP has problems handling non-integer font-sizes (non-integral point sizes). The summary of my source browsing and debugging is this: - FOP accepts non-integral point sizes - FOP hands non-integral point sizes over to formatters (e.g. PDF) - Character widths of the default fonts (I checked with Helvetica) are calculated as if they had the next lower integral font size. This may be so either because the metrics file generator is broken or because of a bug in FOP - I did not check this). - The PDF renderer DOES handle non-integral font sizes correctly. Because the renderer partially performs his own calculations, the result will - depending on the circumstances - either look good (but measure wrong) or totally broken. One effect that can happen is described in #6458. - I rated this bug as major, because this bug can be very difficult to diagnose for uses - lots of wasted time. The current workaround is not to use non-integral font sizes. - As a consequence, at least FOP should round font sizes in formatting objects down to the next lower integral point size. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
