[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: |
Mon, 29 May 2023 17:55:49 +0300 |
> From: Robert Pluim <rpluim@gmail.com>
> Cc: 63731@debbugs.gnu.org, steven@stebalien.com
> Date: Mon, 29 May 2023 16:43:00 +0200
>
> >>>>> On Mon, 29 May 2023 16:58:43 +0300, Eli Zaretskii <eliz@gnu.org> said:
>
> >> display: composed to form "👍️" (see below)
>
> Eli> This is not what I see. I didn't use the above set-char-table-range
> Eli> expression literally, but instead started "emacs -Q", and then
> Eli> evaluated in *scratch*:
>
> Eli> (set-char-table-range
> Eli> composition-function-table
> Eli> #xFE0F
> Eli> '(["\\c.\ufe0f" 1 compose-gstring-for-graphic]))
>
> Eli> After that, the sequence U+1F44D U+FE0F displays as a single glyph,
> Eli> and there's no thin space after it. What am I missing? Is this
> Eli> somehow specific to ftcrhb font driver or something?
>
> Itʼs a single glyph, but that glyph contains a thin-space. I used this
> to check, the second 'a' is slightly offset
>
> 👍️a
> 👍a
That's because the first one shows two glyphs that are
"pseudo-composed": not by the font, but by our hand-made "composition"
in compose-gstring-for-graphic. Try this instead:
(set-char-table-range
composition-function-table
#xFE0F
'(["\\c.\ufe0f" 1 font-shape-gstring]))
so that we only see a composition if the font indeed agrees to
compose. What do you see?
- 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/26
- bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate, Robert Pluim, 2023/05/28
- 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/28
- 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 <=
- 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, 2023/05/30
- 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