GNOME Bugzilla – Bug 789264
Support for color emoji in message body
Last modified: 2018-11-05 16:25:37 UTC
Created attachment 361978 [details] Screenshot of the compose window with working color emoji in all fields except message body. Message body does not seem to support a fontconfig with color emoji. The following is a fontconfig which enables the Noto Color Emoji almost everywhere in the GNOME desktop, apart from the evolution message body: <?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'> <fontconfig> <match> <test name="family"> <string>sans-serif</string> </test> <edit name="family"> <string>Noto Color Emoji</string> </edit> </match> <match> <test name="family"> <string>serif</string> </test> <edit name="family"> <string>Noto Color Emoji</string> </edit> </match> <match> <test name="family"> <string>monospace</string> </test> <edit name="family"> <string>Noto Color Emoji</string> </edit> </match> <match> <test name="family"> <string>Apple Color Emoji</string> </test> <edit name="family" mode="prepend" binding="strong"> <string>Noto Color Emoji</string> </edit> </match> <match target="font"> <edit name="rgba" mode="assign"> <const>rgb</const> </edit> </match> <match target="font"> <edit name="hinting" mode="assign"> <bool>true</bool> </edit> </match> <match target="font"> <edit name="hintstyle" mode="assign"> <const>hintslight</const> </edit> </match> <match target="font"> <edit name="antialias" mode="assign"> <bool>true</bool> </edit> </match> <dir>~/.fonts</dir> </fontconfig>
Thanks for a bug report. As I'm not that familiar with the fontconfig background, what am I supposed to do with that XML blob exactly, please? When it's on its place and the rest of the desktop knows about it (thus it's in action), what do I do to write that green snake (or what's that supposed to be), please?
Thanks for taking a look Milan! For the font config, the XML should be in the file $HOME/.config/fontconfig/fonts.conf. The font cache can then be regenerated using fc-cache -fv The XML I provided uses the Noto Color Emoji font, which needs to be installed prior. The new gnome-characters app introduced in 3.26 can display the various color emoji, and will let you copy the characters to paste where needed. I know it's not the most pressing of issues but it would be a nice feature to have. I found it curious that the font works pretty much everywhere else in GTK except for in Evolution. I should note that the characters also don't display in received messages, either. I have toggled "Use Unicode Characters for Emoticons" on and off with no effect on the issue.
Created attachment 362198 [details] fonts.conf file
Created attachment 362200 [details] A screenshot of the composer window with B&W emoji displayed
Thanks for the update. The message body is provided by WebKitGTK+. I tried with webkitgtk4-2.18.1-1.fc28 and run: /usr/libexec/webkit2gtk-4.0/MiniBrowser --editor-mode And when I had opened the gnome-characters with the green snake in the clipboard, pasting it into the MiniBrowser body showed it as black&white snake. Pasting it into the address bar showed it as a green snake (both with Ctrl+V). From that I believe it's a question of webkitgtk4, maybe (at least partly) related to: https://bugs.webkit.org/show_bug.cgi?id=82889 Michael/Tom, would you prefer a new WebKit bug, or I can close this in a favour of the existing? (Because GtkEntry and GtkTextView show the green snake after pasting as expected.)
It might require WebKit trunk or something. Carlos Garcia worked on color emoji support quite recently.
(In reply to Michael Catanzaro from comment #6) > It might require WebKit trunk or something. Carlos Garcia worked on color > emoji support quite recently. Yes, it landed in http://trac.webkit.org/changeset/221909/webkit. He's not planning to backport that due to risk of regressions, so you should expect this feature in WebKitGTK+ 2.20.
Thanks a lot for the pointers, Michael. The idea of not adding the change into current stable is understandable. Here's a link to the referenced bug report in the above commit: https://bugs.webkit.org/show_bug.cgi?id=156579
I have webkit2gtk3 2.20.x and 2.22.3, but none of them show colored emojicons. May I setup something in the system to have it working specifically for WebKitGTK+? It works out of the box for gtk+/cairo/pango. Here [1] is a similar issue, apart of black&white emojicons, where some parts of gtk/cairo/pango can merge certain symbols into one, while other parts (not only WebKitGTK+) show them as three separate symbols. I won't mind, it only confuses users. [1] https://gitlab.gnome.org/GNOME/evolution/issues/204
When I visit https://unicode.org/emoji/charts/full-emoji-list.html I see lots of color emoji. WebKit doesn't support emoji modifiers/joiners so it's not going to join the heads, and in my experience such characters are not colored either. You can see this by scrolling down the page. That explains why the heads aren't joined or colored in #204. It's probably easy to implement for anyone who worked on the gtk/cairo/pango bits, but we don't know how. The final trick is that the font used has to support it. When I copy
Well apparently a Santa emoji is too much for Bugzilla, but my last paragraph was something along the lines of: the font matters, and I'm not sure that any special logic exists to ensure a color emoji font gets preferred to a normal emoji font when performing font fallback. I can definitely see color Santa on unicode.org, but not here in the Bugzilla input form, because the font is different.
Thanks Michael. Do you mean that Evolution should use different font? Depending on the settings, Evolution uses the same font as the system (that's by default). It's not an emoji font, of course. > It's probably easy to implement for anyone who worked on the gtk/cairo/pango > bits, but we don't know how. Yeah, understood, I've also no idea how to do it.
(In reply to Milan Crha from comment #12) > Do you mean that Evolution should use different font? No, not at all. I mean: someone who understands fonts and color emoji needs to investigate font selection, inside WebKit. I'm just guessing that font selection is probably to blame, not sure. None of the WebKit developers have the right expertise to deal with this issue, so we're probably going to leave it unfixed.