bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate

[Robert Pluim <rpluim@gmail.com>]

>>>>> On Fri, 02 Jun 2023 15:58:05 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> CHAR+VS-15 and CHAR+VS-16 correctly choose text and emoji
    >> representation, but CHAR+VS-15 results in the text representation only
    >> if CHAR is not an emoji. If it is an emoji, the font selected for it
    >> will always be the emoji font.

    Eli> And an Emoji font, when presented with CHAR+VS-15 sequence doesn't
    Eli> produce a textual-representation glyph for CHAR?  I'd expect it to.

No.

    Eli> If Emoji fonts don't produce textual-representation glyphs in this
    Eli> case, I wonder how can this work at all.  Because if we select some
    Eli> non-Emoji font, it will probably not know about VS-15, so we will be
    Eli> left with VS-15.  Are we supposed to handle that ourselves, instead of
    Eli> relying on the font and the shaping engine?

    >> Iʼve tried forcing font_range to use the font for the 'symbol' script
    >> for EMOJI+VS-15, instead, but that resulted in composition
    >> failing.

Itʼs finding what appears to be the default system font, not whatʼs
specified in the fontset for 'symbol', so thatʼs one reason why
composition fails. Even with 'use-default-font-for-symbols' nil.

    Eli> That's what I'd expect: non-Emoji fonts don't know about VS-15.

Right

    Eli> What does HarfBuzz's hb-view do with such sequences, when using Noto
    Eli> Color Emoji font?

Sequence       Font             Result
23e9 fe0e      system           black box
23e9 fe0e      Symbola          correct text representation
23e9 fe0e      NotoEmoji        correct text representation
23e9 fe0e      NotoColorEmoji   blank

And on emacs-29, Symbola and NotoEmoji compose that sequence
correctly. Now I just need to persuade emacs-30 to use one of them.

Robert
--