The shrugging woman emoji 🤷♀️ doesn't display properly in WebKitGTK. Copy/paste it into gedit or, in Epiphany, select and right-click to see proper rendering done by pango. This is U+1F937 U+200D U+2640 U+FE0F. 🤷 (U+1F937 person shrugging) displays fine.
In contrast, 🧟♀️ (woman zombie) works fine. This is U+1F9DF U+200D U+2640 U+FE0F, an almost identical sequence. I have no clue what the difference here could possibly be.
Some other nearby characters, e.g. 🤷♂️ (man shrugging) and 👨⚕️ (man health worker) and 💇♂️ (man getting haircut) have the same problem. Other seemingly-random characters like 🧞♀️ (woman genie) work fine.
Created attachment 374572 [details]
Sample rendering with WebKitGTK r247673
Here I get the same rendering in GEdit and Epiphany with
WebKitGTK built from trunk, see the attached image.
Hm, my result is with 2.25.2. Let me check trunk.
Indeed, the emoji display properly in my JHBuild environment, but they're broken in Tech Preview (2.25.2).
When I build 2.25.2 in my JHBuild environment, the emoji still work. That means something other than WebKit is probably too old in Tech Preview. There are so many font rendering libraries it's hard to know what, though: FreeType, harfbuzz, Fontconfig, cairo? Probably Carlos Garcia will know.
Created attachment 374588 [details]
Ephy Tech preview updated this morning
(In reply to Michael Catanzaro from comment #4)
> When I build 2.25.2 in my JHBuild environment, the emoji still work. That
> means something other than WebKit is probably too old in Tech Preview. There
> are so many font rendering libraries it's hard to know what, though:
> FreeType, harfbuzz, Fontconfig, cairo? Probably Carlos Garcia will know.
We have ICU 64.2 in Tech Preview, as opposed to 63.2 in Fedora 30 (used in my JHBuild environment, which works).
(In reply to Xabier Rodríguez Calvar from comment #5)
> Created attachment 374588 [details]
> Ephy Tech preview updated this morning
Let's make sure we have identical runtime versions to remove any possibility of different software versions. Please run:
$ flatpak info org.gnome.Platform//master
Subject: Export org.gnome.Platform
Date: 2019-07-17 07:35:03 +0000
Then my Tech Preview build is from an experimental repo, but it should be the same as the official one. Not that Epiphany version should matter at all: 3.33.4-24-g9f95b6c3e.
I wonder if host fonts could affect this (are host fonts used in the flatpak environment?), but my emoji that do appear look identical to Calvaris's....
Created attachment 374598 [details]
Michael's screenshot of Tech Preview
(In reply to Michael Catanzaro from comment #7)
> $ flatpak info org.gnome.Platform//master
$ LANG=C flatpak info org.gnome.Platform//master
calvaris@rachado:~$ LANG=C flatpak info org.gnome.Epiphany.Devel
I switched back to normal Tech Preview and have:
Which is probably a couple hours newer than yours. Regardless, Carlos, we know the runtime version is identical, eliminating any possibility of difference in dependency versions or WebKit itself. And the Epiphany version is nearly identical.
I'm told that flatpak exposes host fonts inside the flatpak environment, so almost surely the difference is caused by different host fonts. Perhaps Fontconfig is choosing a non-ideal font for the characters that aren't rendered properly.
So I can reproduce this bug 100% of the time on my development workstation, and 0% of the time on my travel laptop. I guessed it must be caused by a difference in host fonts, because I couldn't think of any other host config that could affect the flatpak runtime.
Using fc-list, I discovered that my development workstation has a few fonts installed that my travel laptop does not:
These fonts are provided by the Fedora packages smc-raghumalayalamsans-fonts, smc-rachana-fonts, smc-suruma-fonts, smc-anjalioldlipi-fonts, and smc-dyuthi-fonts. All other fonts are identical between the two systems. I uninstalled all these fonts from my development workstation, but it did not fix the bug. I conclude a difference in installed fonts is not to blame.
Another example: https://gankra.github.io/blah/text-hates-you/
In the case of emoji, you've probably seen the failure mode of this process before! Because some emoji are actually ligatures of several simpler emoji, a font may successfully report support for the character while only yielding the components. So 🤦🏿♀️ may literally appear as 🤦 🏿 ♀ if the font is "too old" to know about the new ligature. This can also happen if your unicode implementation is "too old" to know about a character, causing the styling system to accept a partial match in the font.
Here the first emoji is broken as described, I see a black-and-white facepalm, some weird tofu character, and then the ♀ character. (The second one is intentionally "broken" to demonstrate.)