GNOME Bugzilla – Bug 753312
Font not properly loaded on MacOSX (example attached)
Last modified: 2016-04-24 09:51:35 UTC
Created attachment 308841 [details] Sample code des Using the attached program, it seems that Emoji/Emoticons unicode symbols are not handled by Gtk on MacOSX while it is working fine on Debian. I tested with gtk+ 2.24.28, gtk+ 3.16.4 (installed from HomeBrew) and on another Mac with gtk+ 2.24.25 (installed from MacPorts) with always the same result. I can see that Gimp is also affected by this bug.
Created attachment 308842 [details] Program output for 3 different setups
Could you tell us which Pango version you are using on Mac OS X? Are you using a specific font on Mac OS, or the default one? It's most likely a Pango issue, so we might want to reassign when we have the additional information. Also we need to verify if the Emoji unicode symbols are actually included in the used Mac OS font.
On first MacOSX, Pango 1.36_8.1 built from https://github.com/Homebrew/homebrew/blob/master/Library/Formula/pango.rb On second 1.36.8 from Macports. I am only using the given program (so default font), compiled with: gcc hello-world.c `pkg-config --libs --cflags gtk+-3.0` Which ends with: gcc hello-world.c -D_REENTRANT -I/usr/local/Cellar/gtk+3/3.16.4_1/include/gtk-3.0 -I/usr/local/Cellar/glib/2.44.1/include/gio-unix-2.0/ -I/usr/local/Cellar/cairo/1.14.2_1/include/cairo -I/usr/local/Cellar/libepoxy/1.2/include -I/usr/local/Cellar/pango/1.36.8_1/include/pango-1.0 -I/usr/local/Cellar/atk/2.16.0/include/atk-1.0 -I/usr/local/Cellar/cairo/1.14.2_1/include/cairo -I/usr/local/Cellar/pixman/0.32.6/include/pixman-1 -I/usr/local/Cellar/fontconfig/2.11.1/include -I/usr/local/Cellar/freetype/2.5.3_1/include/freetype2 -I/usr/local/Cellar/freetype/2.6_1/include/freetype2 -I/usr/local/Cellar/libpng/1.6.17/include/libpng16 -I/usr/local/Cellar/gdk-pixbuf/2.30.8/include/gdk-pixbuf-2.0 -I/usr/local/Cellar/libpng/1.6.17/include/libpng16 -I/usr/local/Cellar/glib/2.44.1/include/glib-2.0 -I/usr/local/Cellar/glib/2.44.1/lib/glib-2.0/include -I/usr/local/opt/gettext/include -L/usr/local/Cellar/gtk+3/3.16.4_1/lib -L/usr/local/Cellar/pango/1.36.8_1/lib -L/usr/local/Cellar/atk/2.16.0/lib -L/usr/local/Cellar/cairo/1.14.2_1/lib -L/usr/local/Cellar/gdk-pixbuf/2.30.8/lib -L/usr/local/Cellar/glib/2.44.1/lib -L/usr/local/opt/gettext/lib -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl On MacOSX, Emoji symbols seems to be in font "Apple Color Emoji" and not on the default font (which seems to be "Helvetica Neue", but I am not totally sure about that). On Debian, the default font does not contain emojis but I guess that this is still working because there are contained in another font (ttf-ancien-fonts and/or ttf-symbola at least) with automatic fallback(?).
(In reply to Gautier Pelloux-Prayer from comment #3) > > On MacOSX, Emoji symbols seems to be in font "Apple Color Emoji" and not on > the default font (which seems to be "Helvetica Neue", but I am not totally > sure about that). Very well possible and we need to ensure that Pango is falling back on the Emoji font properly.
Can you confirm me that I have nothing more to do yet? If not, what can I do to help on this matter?
Hello - did you manage to reproduce this issue or should I try to provide you a simpler program without Gtk but only Pango?
I can reproduce on 10.10 with glib/gtk+/pango from git master branches. Harfbuzz-1.0.2 Pango git 1.37.3..aa12788659f2a65314bdcc005d50105a5f4a63cd Gtk+ 3.17.7..09567d19a73b7992f702605790d7dc43139650e9
(In reply to Gautier Pelloux-Prayer from comment #6) > Hello - did you manage to reproduce this issue or should I try to provide > you a simpler program without Gtk but only Pango? Yes I can reproduce the issue too. Also I can confirm that the 0x1f600 character is included with the Apple Color Emoji font and that the Apple Color Emoji font is included in the cascade list (fallback font list) that is used. We appear to need fixes in two places: 1) The code that translates coverage bitmaps from what is obtained from CoreText to what is needed by Pango only handles the BMP plane and needs to be extended to handle non-BMP planes. I have a half finished patch to do this now which I will clean up. 2) The CoreText shaper engine needs to be fixed/extended to be able to handle 32-bit code points. Since we didn't support non-BMP, this was never done. Hope I'll have patches during the weekend.
Note that in order to get this to work, we depend on the patch in the following Cairo bug to be applied: https://bugs.freedesktop.org/show_bug.cgi?id=63771 I updated that patch today and requested it to be reviewed and accepted.
Created attachment 310767 [details] [review] [PATCH 1/3] coretext: properly handle UTF32 characters in CFStrings
Created attachment 310768 [details] [review] [PATCH 2/3] coretext: remove useless calls to pango_coverage_set()
Created attachment 310769 [details] [review] [PATCH 3/3] coretext: implement obtaining coverage of supplementary planes
I just attached the necessary Pango patches to get this to work. Note that in addition to this you need the Cairo patched I referenced in comment 9. It looks like this patch will land in Cairo after the 1.14 release. When rendered, the Emoji glyphs look like they are slightly cut off. I haven't investigated why this is happening, I would propose a separate bug is opened for this after the above patches have landed.
Awesome work! Thanks for investigating this issue. I will try that asap!
Moving this to pango then. Thanks, Kris!
*** Bug 763536 has been marked as a duplicate of this bug. ***
Any update here anyone?
As far as I know, the attached patches fix the issue and are waiting to be reviewed. In conjunction with this, the Cairo patch linked in command 9 (https://bugs.freedesktop.org/show_bug.cgi?id=63771) is waiting to be pushed.
lgtm. Please push. Thanks!
Pushed to master. Hope the necessary Cairo improvements will follow suit. commit 7e6fe2c381c307619215a1f7661dd5c609b22c39 Author: Kristian Rietveld <kris@loopnest.org> Date: Sat Sep 5 23:13:18 2015 +0200 coretext: implement obtaining coverage of supplementary planes commit 550fba61eea3cae292d4b2abbffbe8a7a99a50b4 Author: Kristian Rietveld <kris@loopnest.org> Date: Sat Sep 5 22:58:28 2015 +0200 coretext: remove useless calls to pango_coverage_set() Since Pango coverage is initialized to PANGO_COVERAGE_NONE, it makes no sense to perform calls to pango_coverage_set for characters that will be set (or rather left) to none. commit 783544ddfc23225f894a26eb31fcc4bc3990ce22 Author: Kristian Rietveld <kris@loopnest.org> Date: Sat Sep 5 22:52:48 2015 +0200 coretext: properly handle UTF32 characters in CFStrings