[
https://issues.apache.org/jira/browse/FOP-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640553#comment-14640553
]
Thanasis Giannimaras commented on FOP-1777:
-------------------------------------------
Fix for handling kerning for unencoded characters.
Patch based on work provided by Luis Bernado with few changes.
For mitigating potential performance issues, kerning has been disabled by
deault (default option was true).
As i could not include Nimbus Sans L font in fop, due to its license, for junit
testing i used Bitstream Charter Regular
(http://www.math.utah.edu/~beebe/fonts/charter-1.0.zip) which come with a more
open, less restrictive license.
> Support for Font Kerning is Broken
> ----------------------------------
>
> Key: FOP-1777
> URL: https://issues.apache.org/jira/browse/FOP-1777
> Project: FOP
> Issue Type: Bug
> Components: font/unqualified
> Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
> Reporter: Vincent Hennebert
> Attachments: bchr.README, bchr.afm, bchr.pfb, fop.xconf, kerning.fo,
> kerning.pdf, kerningTrunk.patch, kerningTrunk.pdf,
> screenshot-openoffice-writer.png
>
>
> The method o.a.f.fonts.Font.getKernValue expects two Unicode code points and
> returns the amount of kerning between the two corresponding glyphs. However,
> the implementation for Type 1 fonts interprets the two integers as character
> codes in the font's internal encoding (see o.a.f.fonts.type1.AFMFile.java).
> Those usually have nothing to do with Unicode code points.
> Moreover, trying to get kerning between two characters is inherently wrong:
> kerning applies to glyphs and not characters. A font may have several glyph
> variants for a same character, and kerning is likely to be different for each
> variant.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
