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

Previous Next

Package: emacs;

Reported by: Mike FABIAN <mfabian <at> redhat.com>

Date: Wed, 26 Feb 2020 14:30:03 UTC

Severity: normal

Found in version 28.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Mike FABIAN <mfabian <at> redhat.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Robert Pluim <rpluim <at> gmail.com>, 39799 <at> debbugs.gnu.org
Subject: bug#39799: 28.0.50; Most emoji sequences don’t render correctly
Date: Sat, 29 Feb 2020 09:01:37 +0100
Eli Zaretskii <eliz <at> gnu.org> さんはかきました:

>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: 39799 <at> debbugs.gnu.org,  mfabian <at> redhat.com
>> Date: Fri, 28 Feb 2020 22:22:15 +0100
>> 
>> One other thing: the #x24C2 is not composed with the following #xFE0F
>> when itʼs displayed using Google Noto Sans. If I get it to display
>> with Noto Color Emoji it *is* composed, even though I haven't set up
>> any composition-function-table entries for it. Where is that
>> composition coming from?
>
> Emacs can only compose characters if the font supports all of the
> codepoints that are being composed.  So you need to choose a font that
> supports these compositions.

I think there are no fonts supporting both the emoji representations and
text representations of emoji which have both.

-- 
Mike FABIAN <mfabian <at> redhat.com>
睡眠不足はいい仕事の敵だ。





This bug report was last modified 3 years and 256 days ago.

Previous Next


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