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

Previous Next

Full log

Message #86 received at 63731 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F)
 where appropriate
Date: Mon, 29 May 2023 17:55:49 +0300

> 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

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?

Previous Next

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