RFR: 8269806: Emoji rendering on Linux [v18]

[Nikita Gubarkov]

On Wed, 15 Feb 2023 02:00:19 GMT, Phil Race <prr at openjdk.org> wrote:

>> 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

Yes, that's the problem I'm trying to solve - determine default mono/emoji presentation for a code point.
And second part of this problem is how to alter this presentation with variation selectors.
I will try this approach with the lookup table and then we'll discuss this in more details.

Regarding native apps, I tested this on Windows 11 (and Windows 10 when I was implementing this) by copying this string into textfields of different apps:
❤ ❤︎ ❤️ 🔥 🔥︎ 🔥️
It's a plain emoji, then with mono selector, then with emoji selector, then repeat with different unicode.
The difference is that "heart" emoji is mono and "fire" is colored by default, so if app correctly handles VS, it should display like this:
M M C C M C

My results:
Notepad - works correctly, including VS. Mono from Symbol and colored from Emoji.
WordPad - uses Symbol (mono) with plain unicode, base (mono) glyphs from Emoji font when VS is present.
Address bar in Explorer - always mono, using base glyphs from Emoji font.
Google Chrome - works correctly, like Notepad if using search field on google.com, always colored when using address bar, preview of this comment shows all colored as well.

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

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