RFR: 8269806: Emoji rendering on Linux [v18]

[Phil Race]

On Wed, 1 Feb 2023 23:40:08 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> So I restored the original idea.
>> 1. Place Symbol into main font sequences to preceed the Emoji and be able to have exclusion ranges
>> 2. Exclude everything that should be colored by default
>> 3. One more hack in composite mapper - ignore exclude ranges when variation selector is specified
>> 
>> Results:
>> * No selector, default mono: will be handled by Symbol
>> * No selector, default color: skip Symbol because excluded, handle by Emoji
>> * FE0F (color): skip Symbol because it doesn't define mapping for this selector, handle by Emoji
>> * FE0E (mono): skip Symbol & Emoji & remaining fonts because they don't define this selector. No glyph found, so try again without selector, but ignoring exclusion ranges - handle by Symbol
>
> The best idea that came to my mind so far is to insert proxy "emoji" mapper into fallback sequence, which will handle default variations and stuff and then forward calls to real mono/color mapper. And this logic can also be reused in other OSes. What do you think?

If the problem we are trying to solve here is around which code points have a default emoji presentation then I think we can have an internal table based on Unicode 15's emoji-data.txt
The JDK sources include a copy of that in java.base, but I don't propose we access it - just use it to hand build a table of the 1205 default emoji.

If that ISN'T the problem you are trying to solve then you'll need to explain it again.
Also I had a VERY brief exchange about whether java.lang.Character could expose this info to us - built directly from that CLDR data. That may be the longer term solution which might start out as JDK internal API.

Then how to fiddle around multiple fonts to do this is the next question.
I really don't want to have knowledge of the code points a particular font supports
(ie the exclusion ranges) but if we just do a lookup on that table and its a hit, then we can go looking through any fonts with a  COLR table for an emoji glyph. Otherwise no need to do anything. 
We'd need to convince ourselves that it is OK that inserting a VS for emoji=off could make us find a different design from a different font. 
Or we just put the emoji font before the symbol font .. 

And as for what "native apps do", tell me how you tested this.
In my testing on Windows 11 "WordPad aka Write" seems incapable of displaying color emoji.
Notepad can .. but the variation selector is not doing anything.
And I'm not sure what font glyphs come from but I don't see it mattering as long as we do something like the above

-------------

PR: https://git.openjdk.org/jdk/pull/4798