[
https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030875#comment-15030875
]
Andreas L. Delmelle commented on FOP-2540:
------------------------------------------
Thinking some more about the current state of "codepoint-to-glyph" mappings,
and IIUC, the 1-1 correspondence that is currently enforced by the code would
be insufficient for a number of cases, i.e. not only the extra roman-to-symbol
mappings that are supported by Windows and Mac Symbol fonts.
I am thinking that, more generally, there may be cases where a font simply does
not have a glyph for a certain codepoint, but wants to map that codepoint to
another glyph. Example would be different types of dashes or spaces. A
non-breaking space could theoretically be mapped to the very same 'glyph'
(representing an empty space, obviously) as a regular space. An em-dash could
be mapped to a regular minus sign. Things like that... This would not be
supported by the current code, if I catch correctly, since as soon as an
"eight-bit-glyph" is mapped once, it cannot be mapped again.
In the other direction, it would likely be very rare situations. I cannot
immediately think of use cases for mapping a single codepoint to more than one
glyph...?
> Enhance TTF/OTF support beyond Windows
> --------------------------------------
>
> Key: FOP-2540
> URL: https://issues.apache.org/jira/browse/FOP-2540
> Project: FOP
> Issue Type: Improvement
> Components: font/opentype
> Affects Versions: 2.0
> Environment: OS X
> Reporter: Andreas L. Delmelle
> Assignee: Andreas L. Delmelle
> Priority: Minor
> Attachments: FOP-2540.patch, test_osx_fonts_after_1.log,
> test_osx_fonts_before.log
>
>
> Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3,
> i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode,
> or 1, i.e. Macintosh.
> This makes quite some system fonts bundled with OS X supposedly unusable. The
> solution is fairly trivial (patch proposal will be attached shortly),
> provided the cmap table format in the font is already supported. FOP
> currently only has support for cmap format 4 (segment to delta mapping), but
> this seems to suffice for most of the Unicode cmaps as well.
> See also FOP-2539, which triggered me to investigate this closer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
