[Top][All Lists]

[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: Fri, 28 Feb 2020 18:30:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Robert Pluim <address@hidden> さんはかきました:

> One thing this has thrown up that I donʼt understand is this:
> Most of the emojis in emoji-sequences.txt can be made to use Noto
> Color Emoji, but some canʼt. e.g.
> #x24c2 Ⓜ
> is stubbornly not being displayed using Noto Color Emoji, even though
> that font has a glyph for it, and Iʼve added:
>      (set-fontset-font "fontset-default" symbol-subgroup
>                       '("Noto Color Emoji" . "iso10646-1") nil
>                       'prepend)
> just after the similar setting for Symbola in
> lisp/international/fontset.el
> Itʼs not being displayed with the default font, and setting
> use-default-font-for-symbols to nil makes no difference. Itʼs using:
>     ftcrhb:-GOOG-Noto Sans CJK 
> JP-normal-normal-normal-*-16-*-*-*-*-0-iso10646-1 (#x3F8)
> However, if I
> eval
>      (set-fontset-font nil #x24c2
>                       '("Noto Color Emoji" . "iso10646-1") nil
>                       'prepend)
> in the frame displaying the character, then it does use Noto Color
> Emoji. What am I missing?
> Robert

U+24C2 is an Emoji which has both a text and an emoji presentation. See:



U+1F600 is an emoji, which has only emoji representation:

$ 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

It displays without problems in colour in my Emacs.

Note that U+24C2 does not have the "Emoji_Presentation" tag:

$ grep 24C2 emoji-data.txt 
24C2          ; Emoji                # E0.6   [1] (Ⓜ️)       circled M
24C2          ; Extended_Pictographic# E0.6   [1] (Ⓜ️)       circled M

It has to variations, text representation and emoji representation:

$ 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

(U+1F600 is not in emoji-variation-sequences.txt as it has only emoji 

$ grep 1F600 emoji-test.txt 
1F600                                      ; fully-qualified     # 😀 E1.0 
grinning face
$ grep 24C2 emoji-test.txt 
24C2 FE0F                                  ; fully-qualified     # Ⓜ️ E0.6 
circled M
24C2                                       ; unqualified         # Ⓜ E0.6 
circled M

As you can see above, U+1F600 is already fully-qualified on its own.

If I test in gedit, U+24C2 on  its  own is displayed in black and white
(happens to use "MS Gothic" font on my system).
U+24C2 U+FE0E is displayed in black and white in gedit as well.
U+24C2 U+FE0F is displayed in colour in gedit  using the "Noto Color
Emoji" font.

These selectors don’t work in Emacs for me. U+24C2, U+24C2 U+FE0E, and
U+24C2 U+FE0F *all* display in black and white for me in Emacs.

The selectors are displayed as a narrow box.

The presence of such selectors in a currently visible buffer make my
Emacs extremely slow and unresponsive, I can hardly finish typing this

If I switch to some other buffer so that no such selectors are currently
visible, my Emacs is responsive.

Now  that I switched back to this buffer to send this e-mail, it is
terribly slow again. 

Same problem when one of the Unicode emoji data files is displayed which
contains these selectors. Emacs  becomes  unusably slow.

Mike FABIAN <address@hidden>

reply via email to

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