bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate

[Eli Zaretskii <eliz@gnu.org>]

> 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?