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

Reply via email to