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
>>>>> On Tue, 21 Sep 2021 14:58:35 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Mike FABIAN <mfabian <at> redhat.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, rgm <at> gnu.org, 39799 <at> debbugs.gnu.org
>> Date: Tue, 21 Sep 2021 13:48:17 +0200
>>
>> > Iʼve just pushed a change to master that should fix (almost) all the
>> > issues with displaying emoji sequences (except for keycaps). Feedback
>> > welcome.
>>
>> Should that also fix the skin tones?
Eli> It should, and I thought HarfBuzz on Cairo already supported that?
It does, but with 'Noto Color Emoji' it doesnʼt work for all
codepoints.
Eli> Can you try this with hb-view and see if HarfBuzz produces a single
Eli> glyph/grapheme from this sequence?
For reference, since the documentation of hb-view is sadly lacking:
hb-view --output-file=foo.svg --font-size=14 \
/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf -u 1f469
produces a glyph with no skin tone. And
hb-view --output-file=foo.svg --font-size=14 \
/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf -u 1f469,1f3fd
Produces one with a medium tone. The skin tones are working for other
code points, so I donʼt know what's causing this particular problem.
Robert
--
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.