GNU bug report logs - #39799
28.0.50; Most emoji sequences don’t render correctly

Previous Next

Full log

View this message in rfc822 format

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, mfabian <at> redhat.com
Cc: rgm <at> gnu.org, 39799 <at> debbugs.gnu.org
Subject: bug#39799: 28.0.50; Most emoji sequences don’t render correctly
Date: Fri, 24 Sep 2021 13:41:07 +0200

>>>>> On Tue, 21 Sep 2021 21:20:07 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

    >> This turns out to be a pretty small change, so if we donʼt get to the
    >> bottom of it we have an alternative.

    Eli> AFAIU, this means we will add 1F3FB..1F3FF to the characters that can
    Eli> follow each of those which have rules with zero lookback.

Yes. Iʼve now pushed exactly that to master. There are two types of
sequences that donʼt work:

1. Where the base character has Emoji_Presentation = No, hence we
donʼt consider it for composition. These are all in the U+2xxx range,
since we explicitly override this for those in the U+1xxxx range. They
do have Emoji_Modifier_Base = Yes, but we donʼt currently do anything
with that info. I guess if we managed to store it in a codepoint
property somewhere, we could teach set-fontset-font or the composition
code about it, but itʼs far too close to emacs-28 for that.

2. Ones I canʼt test because my version of Noto Color Emoji doesnʼt
have glyphs for the base character (essentially these are all the new
14.0 emoji codepoints).

(this does not include the change for choosing emoji presentation for
codepoints followed by VS-16; that still needs some work).

Thanks for the testing and the feedback so far.

Robert
-- 

Previous Next

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