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

Previous Next

Full log

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63731 <at> debbugs.gnu.org, steven <at> stebalien.com
Subject: Re: bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F)
 where appropriate
Date: Tue, 30 May 2023 15:30:58 +0200

[Message part 1 (text/plain, inline)]

>>>>> On Tue, 30 May 2023 15:10:45 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    Eli> Which means it _is_ composed.  Moreover, with Noto Color Emoji we get
    Eli> a single glyph.  On my system, I have Noto Emoji, from which I get two
    Eli> glyphs:

    Eli>   [0 1 128077 422 17 1 15 12 2 nil]
    Eli>   [0 1 65039 3 17 0 1 0 1 [0 0 0]]

    Eli> (in which case I can understand why the second one is displayed as a
    Eli> hex box if I customize glyphless-char-display-control).

But I also get a hex box if I customize
glyphless-char-display-control, even though 'C-u C-x =' claims thereʼs
only one glyph.

    Eli> So, given that this is the case, why is this wrong, again?  If the
    Eli> font and the shaper produce two glyphs, or one glyph that looks like
    Eli> two, why should we think it's an Emacs's problem?

Because Emacs behaves differently depending on whether we have a
composition rule for FE0F that looks backwards or one for 1F44D that
looks forwards. The sequence in both cases is

U+1F44D U+FE0F U+7C U+61
U+1F44D U+7C U+61

(set-char-table-range
 composition-function-table
 #xFE0F
 '(["\\c.\ufe0f" 1 font-shape-gstring]))

produces the following:

[backward-composition.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

There is a (very) thin space that shouldnʼt be there between the 1f44d
and the '|' on the line that has the FE0F (and since it follows the
value of glyphless-char-display-control, I donʼt think
it comes from the shaping engine).

but

(set-char-table-range
 composition-function-table
 #x1F44D 
'(["\U0001f44d\ufe0f" 0 font-shape-gstring]))

gives me this, where the two '|' align perfectly.

[forward-composition.png (image/png, inline)]

[Message part 5 (text/plain, inline)]

(as an experiment, I hacked 'produce_glyphless_glyph' to skip
displaying variation selectors, and the problem disappears).

thanks

Robert

Previous Next

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