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 10:35:11 -0400

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

> On Apr 17, 2022, at 1:53 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> Indeed in Emacs 28 -Q if I
>> 
>> C-x 8 RET FORK AND KNIFE WITH PLATE RET
>> C-x 8 RET FE0F RET
>> 
>> I see the emoji displayed.
>> 
>> If I use the system emoji selector to insert a character into emacs
>> It only puts in "the lone U+1F37D" (at least in emacs where I can
>> check). In other apps this displays as an emoji, in emacs it's a blank.
> 
> "Blank" meaning what?
> 

> Emacs should display the character if there's a font on the system
> available to Emacs that has a glyph for that codepoint.  It just might
> not display it as an Emoji, but as a slightly different symbol, and
> usually with a different font and without the colors inherent in Emoji
> display.  That's what happens on my system.  If that character doesn't
> display at all for you, maybe your fonts don't support it?

Blank as I described in my original report where I included the output
of C-u C-x = which does say there's no font available.  Following the 
recipe with point before the added character it looks like this:



with point after the character it looks like this:



On the macport I see tofu which I think is better.

> Macport Emacs is a separate project that uses its own policies in
> these somewhat gray areas.

I realize.  I originally report this there because it did previously handle
emoji better on mac but as of Emacs 28, it's NEWS says:

    Emoji composition handling is aligned with upstream.  You may find
    some incompatibilities with the previous versions.

In email, YAMAMOTO Mitsuharu said to me about this:
"I only mentioned composition, but font selection is also affected."

When I confirmed it was not displayed by the NS port either I reported
it here.

So FYI, I think in this area the macport policies are trying to
converge with Emacs' policies, though I don't want to speak for them.

Howard

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

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

[Screen Shot 2022-04-17 at 9.37.07 AM.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.