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: Fri, 02 Jun 2023 15:58:05 +0300

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 63731@debbugs.gnu.org,  steven@stebalien.com
> Date: Fri, 02 Jun 2023 14:25:28 +0200
> 
>     Eli> Thanks, please install this on the emacs-29 branch.
> 
> Closing.
> Committed as 2f94f6de9d6

Thanks.

>     >> Proper VS-15 support is harder, I need to think about that some more.
> 
>     Eli> Can you describe here the current problems with VS-15?
> 
> 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.

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

If Emoji fonts don't produce textual-representation glyphs in this
case, I wonder how can this work at all.  Because if we select some
non-Emoji font, it will probably not know about VS-15, so we will be
left with VS-15.  Are we supposed to handle that ourselves, instead of
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.

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

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





reply via email to

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