Skia doesn't seem to honor the emoji variation selector (FE0F)

[matej...@gmail.com]

This causes emoji rendering issues in Flutter (https://github.com/flutter/flutter/issues/100964), as well as google Chrome.

Background: The red heart emoji (♥️ U+2665) has the same code point as black heart (♥). To force emoji rendering an unicode variant selector (0xFE0F) is appended to the character. That should force use of emoji font even if the primary font already contains the glyph.

This what core text seems to do as well as Firefox (https://hg.mozilla.org/mozilla-central/rev/65421ad99b13)

It seems that maybe FontMgrRunIterator should peek after the current codepoint to see if the selector is present and if it is request emoji font? This might also imply the requirement of SkFontMgr being able to provide an emoji font.

Cheers,

Matt

[bungeman]

The user of SkShaper may of course implement a FontMgrRunIterator to do whatever they wish. The default one mostly exists as a way to begin using SkShaper easily, it is by no means ideal for all cases. That being said, it is disappointing that the current SkFontMgr fallback mechanism does not take a variation selector, but it is somewhat difficult to add at this point, and SkFontMgr needs to be replaced for other reasons anyway. In general SkShaper is usable and mostly functional, but was written more as a test of what a shaping API should look like. SkShaper got this wrong and there are significant issues with it (especially with regard to font fallback in general). However, it continues to exist until there is time to write a better replacement. It is unfortunate that this currently affects Flutter.

Note that nothing in SkShaper affects Chrome at all, Chrome does not (and really cannot) use it and Chrome requires a completely different approach (it's laying out css inlines which get their direction from the text they contain, it isn't layout out paragraphs of text, even if it often looks like that's what's happening). Now the SkFontMgr not supporting variation selectors does end up sometimes causing issues in Chrome, but it general Chromium tries to do its own font lookup if it can.

In any event, looks like this is currently tracked by https://skbug.com/11755 .

[matej...@gmail.com]

Small correction. I misread the OneLineShaper code. It doesn't actually seem to use FontMgrRunIterator. It is itself responsible for getting the typeface.

I missed the bug report. Thank you.