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

[Robert Pluim]

>>>>> On Tue, 30 May 2023 15:10:45 +0300, Eli Zaretskii <eliz@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:

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.

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

thanks

Robert