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

Previous Next

Full log

Message #182 received at 39799 <at> debbugs.gnu.org (full text, mbox):

From: Mike FABIAN <mfabian <at> redhat.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, 39799 <at> debbugs.gnu.org
Subject: Re: bug#39799: 28.0.50; Most emoji sequences don’t render correctly
Date: Sat, 29 Feb 2020 12:36:51 +0100

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

Eli Zaretskii <eliz <at> gnu.org> さんはかきました:

>> Ⓜ U+24C2
>> Ⓜ︎ U+24C2 U+FE0E
>> Ⓜ️ U+24C2 U+FE0F
>> 
>> all in black and white and for the two variants which have the variation
>> selectors one sees a narrow box in Emacs.
>> 
>> When using “Noto Color Emoji” or “Joypixels”, one gets all three
>> variants in colour, and a box is only shown for the line in the middle
>> with the U+FE0E text style selector because neither “Noto Color Emoji”
>> nor “Joypixels” seem to implement that one. The emoji style selector
>> U+FE0F does not show a box though, if I understand you correctly that
>> means that apparently both “Noto Color Emoji” and “Joypixels” implement
>> the U+FE0F variation selector.
>
> OK, but then characters such as Ⓜ U+24C2 are supposed to be displayed
> in their text presentation by default,

Yes.

> so the sequence Ⓜ︎ U+24C2 U+FE0E
> seems redundant, as it should display the same as just Ⓜ U+24C2.

Yes, it seems a bit redundant. I was also surprised when I discovered
U+FE0E. I think *all* the emoji which can be followed by U+FE0E (all
those in
http://www.unicode.org/Public/emoji/12.0/emoji-variation-sequences.txt)
have text representation by default anyway, so why is U+FE0E needed at
all?

> So this is not such a big loss for Emacs: you could use a font which
> supports only the Ⓜ️ U+24C2 U+FE0F sequence, and use just Ⓜ U+24C2 for
> the text presentation.

Yes.

>> If I paste these 3 lines into gedit (or anything else which uses pango
>> for this) I see that different fonts  are used. Can also be seen with
>> 
>> pango-view --font="DejaVu Sans" ~/emoji-representation-test.txt
>
> You could have the same in Emacs if you define a special face that
> uses the other font, and then put that face on the sequence which
> isn't composed using the font selected by Emacs.

I think I don’t understand that completely. But you seem to say that it
is possible to make Emacs use different fonts for U+24C2 and the
sequence U+24C2 U+FE0F ? That sounds nice and would probably make it
work better.

>> (I attached the emoji-representation-test.txt file and how it is
>> displayed by pango-view).
>
> I see only a small image showing the font name, and nothing else.
> Some problem with sending the attachment?

Oh, sorry, I apparently clicked on the title bar of the window
when making the screenshot with the “import” tool. New screenshot
attached.

>> I specified the DejaVu Sans font on the command line (which is used for
>> the ASCII text in that screenshot. For the emoji, different fonts are
>> used, on my system where I made that screenshot it happens to be the
>> font “MS Gothic” for the emoji in the first two lines and “Noto Color
>> Emoji” for the last line. So pango uses different fonts for a text
>> representation emoji sequence than for emoji representation.
>
> Like I said, we need a more detailed understanding of how the font is
> selected by Pango in these cases.

-- 
Mike FABIAN <mfabian <at> redhat.com>

[pango-view-emoji-representation-test.txt.png (image/png, attachment)]

Previous Next

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