GNU bug report logs - #63731
[PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, 63731 <at> debbugs.gnu.org, steven <at> stebalien.com
Subject: bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate
Date: Fri, 26 May 2023 20:43:37 +0300

> Cc: 63731 <at> debbugs.gnu.org, steven <at> stebalien.com
> Date: Fri, 26 May 2023 20:27:26 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Robert Pluim <rpluim <at> gmail.com>
> > Cc: 63731 <at> debbugs.gnu.org,  steven <at> stebalien.com
> > 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.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.