[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appr
From: |
Eli Zaretskii |
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@gmail.com>
> Cc: 63731@debbugs.gnu.org, steven@stebalien.com
> Date: Tue, 30 May 2023 15:30:58 +0200
>
> >>>>> 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).
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.
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, (continued)
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Eli Zaretskii, 2023/05/28
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Robert Pluim, 2023/05/29
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Eli Zaretskii, 2023/05/29
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Robert Pluim, 2023/05/29
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Eli Zaretskii, 2023/05/29
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Robert Pluim, 2023/05/29
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Eli Zaretskii, 2023/05/29
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Robert Pluim, 2023/05/30
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Eli Zaretskii, 2023/05/30
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Robert Pluim, 2023/05/30
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate,
Eli Zaretskii <=
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Robert Pluim, 2023/05/31
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Eli Zaretskii, 2023/05/31
bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Steven Allen, 2023/05/26