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

Previous Next

Full log

Message #8 received at 63731 <at> debbugs.gnu.org (full text, mbox):

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

> From: Steven Allen <steven <at> stebalien.com>
> Date: Thu, 25 May 2023 20:18:02 -0700
> 
> This patch imports the full list from unicode.org instead of
> special-casing a few characters as was done previously.
> 
> With this patch, '👍️' (1F44D FE0F) should look the same as '👍' (1F44D).
> Without it, it will look like '👍‌️'.
> 
> As a simple regression test, '✔' (2714) should still as "text" while '✔️'
> (2714 FE0F) should still display as an emoji.
> 
> Fixes https://github.com/alphapapa/ement.el/issues/137
> 
> NOTE: I'm not a Unicode expert, nor do I understand how Emacs handles
> Unicode (beyond what was required to implement this patch). But this
> patch appears to work and I can't find any regressions.

AFAIU, this change will populate composition-function-table for many
"normal" characters, including ASCII digits and symbol/punctuation
characters from the 0x2xxx blocks.  E.g., after you build Emacs with
this patch, what do the following evaluations yield:

  M-: (aref composition-function-table ?0) RET
  M-: (aref composition-function-table #x2122) RET

If they yield non-nil values, it could mean dramatic slowdown of
redisplay with these characters.  Which is precisely what we wanted to
avoid when we made the decision which parts of the Unicode-defined
Emoji sequences to support in Emacs, and how to arrange for that
support to work.

The issue you site is strange: according to the "C-u C-x =" display
there, Emacs did compose #x1f44d with VS-16 using the Noto Color Emoji
font, so I don't quite understand why VS-16 is then also shown as an
empty rectangle.  On my system Noto Color Emoji doesn't work, and "C-u
C-x =" says this instead:

  Composed with the following character(s) "️" using this font:
    harfbuzz:-outline-Noto Emoji-regular-normal-normal-mono-15-*-*-*-c-*-iso10646-1
  by these glyphs:
    [0 1 128077 422 19 2 17 14 2 nil]
    [0 1 65039 3 19 0 1 0 1 [0 0 0]]
  with these character(s):
    ️ (#xfe0f) VARIATION SELECTOR-16

which explains why I see two glyphs and not 1.  But in the display
shown in the above issue, I see

  Composed with the following character(s) "️" using this font:
    ftcrhb:-GOOG-Noto Color Emoji-regular-normal-normal-*-18-*-*-*-m-0-iso10646-1
  by these glyphs:
    [0 1 128077 569 22 0 23 17 5 [0 0 136]]
  with these character(s):
    ️ (#xfe0f) VARIATION SELECTOR-16

which describes only one glyph, not two.  So the result ought to be
what you expect.

Robert, what am I missing here?

Previous Next

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