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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mike FABIAN <mfabian <at> redhat.com>
Cc: rgm <at> gnu.org, rpluim <at> gmail.com, 39799 <at> debbugs.gnu.org
Subject: bug#39799: 28.0.50; Most emoji sequences don’t render correctly
Date: Tue, 21 Sep 2021 15:37:45 +0300

> From: Mike FABIAN <mfabian <at> redhat.com>
> Cc: rpluim <at> gmail.com,  rgm <at> gnu.org,  39799 <at> debbugs.gnu.org
> Date: Tue, 21 Sep 2021 14:27:39 +0200
> 
> >> Should that also fix the skin tones?
> >
> > It should, and I thought HarfBuzz on Cairo already supported that?
> 
> Yes, and I think my screenshot shows that it does because my Screenshot
> uses Pango (and the rest of the rendering stack including HarfBuzz and
> Cairo). 

Now I'm confused: what do you mean here by "it does"?  Does Emacs
support that, or does some other program support it?  If Emacs, then
why did you just tell there was a problem?

When I said "I thought HarfBuzz on Cairo already supported that", I
meant Emacs that uses HarfBuzz on Cairo.  I'm pretty sure we do
support color Emoji in that configuration.

> > Can you try this with hb-view and see if HarfBuzz produces a single
> > glyph/grapheme from this sequence?
> 
> $ hb-view --annotate --font-file=/home/mfabian/.fonts/joypixels-6.6/android/joypixels-android.
> ttf --font-size=50 --text="👩🏽"
> 
> looks like:

The image looks partial and pixelated.  Can you produce PNG or JPEG
or some other color image file, and attach it?

Anyway, if hb-view produces a single glyph, then I guess we need to
debug ftcrfont.c and/or hbfont.c to see why we we produce 2 glyphs in
that case.

Previous Next

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