bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate
Date: Sun, 28 May 2023 15:37:48 +0300

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 63731@debbugs.gnu.org,  steven@stebalien.com
> Date: Sun, 28 May 2023 12:29:48 +0200
> 
> >>>>> On Fri, 26 May 2023 20:43:37 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     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.

But what is "the correct font", when the sequence of codepoints is
CHAR+0xFE0E?  How do we identify such a font?  Do you know of a font
that produces the correct glyph for this sequence, when HarfBuzz is
used as the shaping engine?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]