[Webkit-unassigned] [Bug 191976] [FreeType] Noto Color Emoji is partially used

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Nov 27 01:03:53 PST 2018


https://bugs.webkit.org/show_bug.cgi?id=191976

Akira TAGOH <akira at tagoh.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |akira at tagoh.org

--- Comment #2 from Akira TAGOH <akira at tagoh.org> ---
I'm not totally sure how webkit picks up fonts. as I told on the fontconfig bug reported above, looking up "emoji" would be preferrable way as Pango does and is quite simpler. fontconfig will returns Noto Color Emoji as long as they are installed.
But if the html rendering engine like webkit has own font management thing as they have own character classification, they need to be improved. that's why I said this is an application issue. they need to identify emoji and use the special font family for them instead of sans/serif/mono.

Doing the sort of this thing in the code:
$ fc-list :charset=0x1f600
/usr/share/fonts/dejavu/DejaVuSansCondensed-Oblique.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Oblique,Oblique
/usr/share/fonts/dejavu/DejaVuSansCondensed-Bold.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Bold,Bold
/usr/share/fonts/dejavu/DejaVuSans.ttf: DejaVu Sans:style=Book
/usr/share/fonts/dejavu/DejaVuSans-Bold.ttf: DejaVu Sans:style=Bold
/usr/share/fonts/gdouros-symbola/Symbola.ttf: Symbola:style=Regular
/usr/share/fonts/dejavu/DejaVuSansCondensed.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed,Book
/usr/share/fonts/dejavu/DejaVuSansCondensed-BoldOblique.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Bold Oblique,Bold Oblique
/usr/share/fonts/google-noto-emoji/NotoColorEmoji.ttf: Noto Color Emoji:style=Regular
/usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf: DejaVu Sans:style=Oblique
/usr/share/fonts/dejavu/DejaVuSans-BoldOblique.ttf: DejaVu Sans:style=Bold Oblique

behaves wrong and no surprise even if emoji is renderred as B&W.
Hmm, so I was about to propose a workaround if you do something like the above. but I found a bug in fontconfig that something like this doesn't work:
$ fc-list :charset=0x1f600:color=true

and fixed this in https://gitlab.freedesktop.org/tagoh/fontconfig/commit/67dcfeb4f6e544ec2f380717e04b25e724669856

I don't know if this is really the case for this but maybe worth trying.
Anyway, after this fix, the result of the above command is:
$ fc-list :charset=0x1f600:color=true
/usr/share/fonts/google-noto-emoji/NotoColorEmoji.ttf: Noto Color Emoji:style=Regular

This looks not perfect to me since there are no way to change the behavior if someone prefers B&W rather than colored. or you could make an option to use B&W emoji perhaps.

Anyway, hope that helps.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181127/add3b669/attachment.html>


More information about the webkit-unassigned mailing list