GNU bug report logs - #54970
28.1; Some emoji no longer display

Previous Next

Full log

View this message in rfc822 format

From: Howard Melman <hmelman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Robert Pluim <rpluim <at> gmail.com>, 54970 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>
Subject: bug#54970: 28.1; Some emoji no longer display
Date: Sun, 17 Apr 2022 14:46:25 -0400

[Message part 1 (text/plain, inline)]

> On Apr 17, 2022, at 2:34 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Howard Melman <hmelman <at> gmail.com>
>> Date: Sun, 17 Apr 2022 14:09:25 -0400
>> Cc: Robert Pluim <rpluim <at> gmail.com>,
>> Alan Third <alan <at> idiocy.org>,
>> Lars Ingebrigtsen <larsi <at> gnus.org>,
>> 54970 <at> debbugs.gnu.org
>> 
>> I'm reading a lot about unicode and fontsets and trying to wrap
>> my head around it.  I can't quite answer this yet, the font to display
>> U+1F37D is Apple Color Emoji.  I get that emacs might not want
>> to enable that font by default, but emacs does use it by default to show
>> some emoji, though I don't see it listed when I do M-x describe-fontset.
> 
> The question is why didn't Emacs find that font when asked to display
> U+1F37D, and why did that produce the "blank" display instead of the
> expected tofu.
> 
>>> Okay, try with codepoints between D800 and DB7F: what does that produce?
>> 
>> I'm sorry I don't follow what you want me to do, can you be more specific?
> 
> "C-x 8 RET d800 RET" and tell what you get.



Sorry, same thing.  db7f is the same as well.

Hoawrd

[Message part 2 (text/html, inline)]

[Screen Shot 2022-04-17 at 2.45.29 PM.png (image/png, inline)]

Previous Next

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