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

From: Robert Pluim <[email-masked]>
Date: Sun, 28 May 2023 12:29:48 +0200

>>>>> On Fri, 26 May 2023 20:43:37 +0300, Eli Zaretskii <[email-masked]> said:

    >> Cc: [email-masked], [email-masked]
    >> Date: Fri, 26 May 2023 20:27:26 +0300
    >> From: Eli Zaretskii <[email-masked]>
    >> 
    >> > From: Robert Pluim <[email-masked]>
    >> > Cc: [email-masked],  [email-masked]
    >> > Date: Fri, 26 May 2023 18:24:02 +0200
    >> > 
    >> > It requires something that answers the question "what font would we
    >> > use for this codepoint if it was not an emoji?". Maybe we can have a
    >> > separate fontset that pretends that the emoji script is equivalent to
    >> > symbol? Or invent some kind of 'text-presentation-font' property to
    >> > put somewhere?
    >> 
    >> I'm not sure I understand why we don't select the right font by
    >> default.  Selecting a non-Emoji font for a non-Emoji codepoints should
    >> not need any special tricks.

    Eli> Actually, I don't understand why there's an issue here with font
    Eli> selection.  Are you saying that using Noto Color Emoji with
    Eli> CHAR+0xFE0E, when CHAR is an Emoji character, doesn't produce the
    Eli> textual representation of CHAR?  If so, isn't that a problem with the
    Eli> font?  I thought all we needed to do was to hand the combination to an
    Eli> Emoji-aware font, and the font would do the rest.  Now you seem to be
    Eli> saying that we somehow need to select a non-Emoji font?  But if so,
    Eli> who'd guarantee that a font that cannot display Emoji will know what
    Eli> to do with the combination CHAR+0xFE0E?

Iʼm not sure: gedit displays the text representation, and libreoffice
displays the emoji presentation. And the google color emoji website
only shows colour glyphs. So I think itʼs up to the application to
select the correct font.

Robert
--