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


View this message in rfc822 format

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: bug#63731: [PATCH] Support Emoji Variation Sequence 16 (FE0F) where appropriate
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

This persists if I disable harfbuzz, and it behaves the same on macOS

    Eli> You are saying that the entry in composition-function-table for
    Eli> U+1F44D (and other similar characters) is used in preference to the
    Eli> entry for U+FE0F that follows it, even though there's no U+1F3FB
    Eli> etc. after it to "steal" the composition?  Did you try stepping
    Eli> through composite.c to see whether and why this is the case?

Right. It looks the the FE0F entry is ignored. Iʼve not ventured into
composite.c yet.

    >> I can change the emoji-zwj.awk script to add CHAR+FE0F for all emoji,
    >> unless someone knows how to fix composition to do the right thing
    >> here.

    Eli> I think we need first to understand the issue at hand better.  There's
    Eli> more here than meets the eye, I think.

Absolutely

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.