GNU bug report logs -
#39799
28.0.50; Most emoji sequences don’t render correctly
Previous Next
Reported by: Mike FABIAN <mfabian <at> redhat.com>
Date: Wed, 26 Feb 2020 14:30:03 UTC
Severity: normal
Found in version 28.0.50
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Mike FABIAN <mfabian <at> redhat.com>
> Date: Wed, 26 Feb 2020 15:28:58 +0100
>
> As can be seen in the attached screenshot, some
>
> 👩🦰 U+1F469 U+200D U+1F9B0 woman: red hair
> 🧑🦰 U+1F9D1 U+200D U+1F9B0 person: red hair
>
> don’t render correctly in the screenshot, although they work using the
> same font (“Joypixels”, version 5.5) elsewhere, e.g. in gedit.
>
> Same result in Emacs when using "Noto Color Emoji", both emoji sequences
> are rendered as 2 characters each in Emacs
Not 2, 3. Look more closely, and you will see that the U+200D ZWJ
character is displayed as a thin (1-pixel) space between the 2 emoji.
> When loading
>
> http://www.unicode.org/Public/emoji/12.0/emoji-zwj-sequences.txt
>
> into Emacs one can see that most sequences don’t render correctly
> (actually *all* sequences, as far as I can see).
That's just a matter of setting up composition-function-table to
support these sequences. For example, try the above again after
evaluating:
(set-char-table-range composition-function-table '(#x1F9B0 . #x1F9B3)
(list
(vector
"[\U0001F468-\U0001F469]\u200D[\U0001F9B0-\U0001F9B3]"
2
'compose-gstring-for-graphic)))
Patches are welcome to convert the emoji-related files in Unicode's
character database into appropriate composition-function-table setup,
similar to the example above. Some script to be run at Emacs build
time and produce, say, lisp/emoji.el to populate
composition-function-table, would be nice (see the Awk scripts in
admin/unidata as one source of inspiration).
> Also, when loading
>
> http://www.unicode.org/Public/emoji/12.0/emoji-sequences.txt
>
> into Emacs, one can see that the Flag sequences and skin colour
> sequences don’t render correctly either (not a font problem, both
> “Noto Color Emoji” and “Joypixels” support these):
If you mean they are not displayed in correct colors, then Emacs
doesn't yet support color emoji, we lack some infrastructure for
that. Again, work in that area is welcome, it should be relatively
easy since we now have HarfBuzz support for text shaping.
Thanks.
This bug report was last modified 3 years and 256 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.