[
https://issues.apache.org/jira/browse/FOP-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15394370#comment-15394370
]
Simone Rondelli commented on FOP-1969:
--------------------------------------
Hi Glenn,
I got a first proof of concept that renders the emoji. The first problem is
that the some emoji is composed by more then one codepoint like flags
({{🇮🇹}}) and families
({{👨‍👨‍👦}}) . I found that the
information one how to merge more codepoints (or glyph) into a unique glyph is
described in the ligatures table in the font.
The ligatures table is associated to a script and in the font that I'm using
(EmojiOne) this table is associated with {{latn}} script. The problem is in
{{GlyphMapping.processWordMapping}} where the script of the text is retrieved
using {{String script = text.getScript();}}. The value returned is {{zyyy}},
{{SCRIPT_UNDEFINED}}, for text composed by just emojies and {{auto}} for mixed
text (latn/cjk + emoji).
# Is this a bug of the font or ApacheFOP?
# What would be a good approach to fix it?
I thought that I could modify the logic inside {{GliphTable.matchLookups}} to
select {{*}} when the script is {{zyyy}} or {{auto}}. But I jhave te feeling
that this could break something. Am I right?
> Surrogate pairs not treated as single unicode codepoint for display purposes
> ----------------------------------------------------------------------------
>
> Key: FOP-1969
> URL: https://issues.apache.org/jira/browse/FOP-1969
> Project: FOP
> Issue Type: Improvement
> Components: unqualified
> Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
> Reporter: Glenn Adams
> Attachments: testing.fo, testing.fo, testing.pdf, testing.pdf,
> testing.xml, testing.xsl
>
>
> unicode codepoints outside of the BMP (base multilingual plane), i.e., whose
> scalar value is greater than 0xFFFF (65535), are coded as UTF-16 surrogate
> pairs in Java strings, which pair should be treated as a single codepoint for
> the purpose of mapping to a glyph in a font (that supports extra-BMP
> mappings);
> at present, FOP does not correctly handle this case in simple (non complex
> script) rendering paths;
> furthermore, though some support has been added to handle this in the complex
> script rendering path, it has not yet been tested, so is not necessarily
> working there either;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)