bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39799: 28.0.50; Most emoji sequences don’t render correctly


From: Mike FABIAN
Subject: bug#39799: 28.0.50; Most emoji sequences don’t render correctly
Date: Sat, 29 Feb 2020 11:26:11 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

>> From: Mike FABIAN <mfabian@redhat.com>
>> Cc: Robert Pluim <rpluim@gmail.com>,  39799@debbugs.gnu.org
>> Date: Sat, 29 Feb 2020 09:01:37 +0100
>> 
>> > 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.
>
> Sorry, I don't understand: what does "which have both" refer to?

There are some emoji which have both emoji and text representations,
for example:

$ grep 24C2 emoji-variation-sequences.txt
24C2 FE0E  ; text style;  # (1.1) CIRCLED LATIN CAPITAL LETTER M
24C2 FE0F  ; emoji style; # (1.1) CIRCLED LATIN CAPITAL LETTER M
$ grep 24C2 emoji-data.txt
24C2          ; Emoji                # E0.6   [1] (Ⓜ️)       circled M
24C2          ; Extended_Pictographic# E0.6   [1] (Ⓜ️)       circled M
$

Other (most) emoji have only emoji representation, for example:

$ grep 1F600 emoji-data.txt
1F600         ; Emoji                # E1.0   [1] (😀)       grinning face
1F600         ; Emoji_Presentation   # E1.0   [1] (😀)       grinning face
1F600         ; Extended_Pictographic# E1.0   [1] (😀)       grinning face
$

> Emacs doesn't create the text and emoji presentations, it just hands
> the sequences to the font backend and asks the backend to provide the
> font glyphs to display that sequence.  The rest is between the font
> backend and the font.  And of course all this depends on
> composition-function-table being set up to support these sequences.

I think the specification in Unicode is quite vague on how this should
be implemented. It doesn’t say anything about whether the fonts should
do it or the application.

If I understand it correctly, with the current implementation in Emacs,
it would work if a font had glyphs for both variation selectors.

I.e. if there was a font which had a colour glyph for

24C2 FE0F  ; emoji style; # (1.1) CIRCLED LATIN CAPITAL LETTER M

*and* a black and white glyph for

24C2 FE0E  ; text style;  # (1.1) CIRCLED LATIN CAPITAL LETTER M

Then it would work in Emacs and 24C2 FE0F would display in colour
and 24C2 FE0E in black and white.

But there are no such fonts (yet??). Symbola doesn’t support the
variation selectors at all, i.e. when using Symbola

(set-fontset-font nil '(#x2460 . #x24FF) '("Symbola" . "iso10646-1") nil 
'prepend)

one gets the three variants

Ⓜ 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.

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

(I attached the emoji-representation-test.txt file and how it is
displayed by pango-view).

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.

The specification in Unicode does not seem to say that this is not
allowed and that the font has to do it, it seems a bit vague there.

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

Ⓜ U+24C2
Ⓜ︎ U+24C2 U+FE0E
Ⓜ️ U+24C2 U+FE0F

Attachment: pango-view-emoji-representation-test.txt.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]