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: Robert Pluim <rpluim <at> gmail.com>
Cc: 63731 <at> debbugs.gnu.org, steven <at> stebalien.com
Subject: bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate
Date: Tue, 30 May 2023 19:32:23 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: 63731 <at> debbugs.gnu.org,  steven <at> stebalien.com
> Date: Tue, 30 May 2023 15:30:58 +0200
> 
> >>>>> 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:
> 
> 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).

OK, here's the scoop: there's no composition there.  "C-u C-x =" says
there is, but that's a lie: when I look in GDB at the glyphs actually
shown there, there's no composition glyphs, only the glyph for U+1F44D
followed by a glyph for U+FE0F.

> but
> 
> (set-char-table-range
>  composition-function-table
>  #x1F44D 
> '(["\U0001f44d\ufe0f" 0 font-shape-gstring]))
> 
> gives me this, where the two '|' align perfectly.

Here, there _is_ a composition.

So there are two issues here: (a) why there's no composition in the
first case, and (b) why does "C-u C-x =" says there is when there
isn't.

Previous Next

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