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

Previous Next

Package: emacs;

Reported by: Steven Allen <steven <at> stebalien.com>

Date: Fri, 26 May 2023 03:19:01 UTC

Severity: normal

Tags: fixed, patch

Fixed in version 29.1

Done: Robert Pluim <rpluim <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #89 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: Mon, 29 May 2023 18:13:14 +0200
>>>>> On Mon, 29 May 2023 17:55:49 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: 63731 <at> debbugs.gnu.org,  steven <at> stebalien.com
    >> Date: Mon, 29 May 2023 16:43:00 +0200
    >> 
    >> >>>>> On Mon, 29 May 2023 16:58:43 +0300, Eli Zaretskii <eliz <at> 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

    Eli> That's because the first one shows two glyphs that are
    Eli> "pseudo-composed": not by the font, but by our hand-made "composition"
    Eli> in compose-gstring-for-graphic.  Try this instead:

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

    Eli> so that we only see a composition if the font indeed agrees to
    Eli> compose.  What do you see?

It still displays a single glyph with a thin-space. If I customize
`glyphless-char-display-control' to display hex codes for VS, then it
display a hex box.

So I guess that means weʼre not composing?

Robert
-- 




This bug report was last modified 1 year and 350 days ago.

Previous Next


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