Post-GUADEC distractions

Like everybody else, I had a great time at GUADEC this year.

One of the things that made me happy is that I could convince Behdad to come, and we had a chance to finally wrap up a story that has been going on for much too long: Support for color Emoji in the GTK+ stack and in GNOME.

Behdad has been involved in the standardization process around the various formats for color glyphs in fonts since the very beginning. In 2013, he posted some prototype work for color glyph support in cairo.

This was clearly not meant for inclusion, he was looking for assistance turning this into a mergable patch. Unfortunately, nobody picked this up until I gave it a try in 2016. But my patch was not quite right, and things stalled again.

We finally picked it up this year. I produced a better cairo patch, which we reviewed, fixed and merged during the unconference days at GUADEC. Behdad also wrote and merged the necessary changes for fontconfig, so we can have an “emoji” font family, and made pango automatically choose that font when it finds Emoji.

After guadec, I worked on the input side in GTK+. As a first result, it is now possible to use Control-Shift-e to select Emoji by name or code.

This is a bit of an easter egg though, and only covers a few Emoji like ❤. The full list of supported names is here.

A more prominent way to enter Emoji is clearly needed, so i set out to implement the design we have for an Emoji chooser. The result looks like this:

As you can see, it supports variation selectors for skin tones, and lets you search by name. The clickable icon has to be enabled with a show-emoji-icon property on GtkEntry, but there is a context menu item that brings up the Emoji chooser, regardless.

I am reasonably happy with it, and it will be available both in GTK+ 3.92 and in GTK+ 3.22.19. We are bending the api stability rules a little bit here, to allow the new property for enabling the icon.

Working on this dialog gave me plenty of opportunity to play with Emoji in GTK+ entries, and it became apparent that some things were not quite right.  Some Emoji just did not appear, sometimes. This took me quite a while to debug, since I was hunting for some rendering issue, when in the end, it turned out to be insufficient support for variation selectors in pango.

Another issue that turned up was that pango did place the text caret in the middle of Emoji’s sometimes, and Backspace deleted them piece-meal, one character at a time, instead of all at once. This required fixes in pango’s implementation of the Unicode segmentation rules (TR29). Thankfully, Peng Wu had already done much of the work for this, I just fixed the remaining corner cases to handle all Emoji correctly, including skin tone variations and flags.

So, what’s still missing ? I’m thinking of adding optional support for completion of Emoji names like 😀 directly in the entry, like this:

But this code still needs some refinement before it is ready to land. It also overlaps a bit with traditional input method functionality, and I am still pondering the best way to resolve that.

To try out color Emoji, you can either wait for GNOME 3.26, which will be released in September, or you can get:

  • cairo from git master
  • fontconfig from git master
  • pango 1.40.9 or .10
  • GTK+ from the gtk-3-22 branch
  • a suitable Emoji font, such as EmojiOne or Noto Color Emoji

It was fun to work on this, I hope you enjoy using it! ❤

4 thoughts on “Post-GUADEC distractions”

  1. Yeeeah, I love that. This Will mean that I will be able to see emojis en gnome terminal?

  2. Really good news! And nice work. This is so good to hear. Thank you a lot 🙂

    I have some questions:

    * Is the emoji picker accessible from the contextual menu of any text field?

    * Is there a keyboard shortcut to open it from any text field? (similar to how macOS has ^⌘space)

    * Is an emoji font going to be shipped by default with Gnome? The previews show Noto, in a version previous to the unreleased redesign (and which is unlikely to ship before 3.26 anyway).

    * If this is the font Gnome is going with, there’s the issue of it only being up to date with Emoji 4 (Unicode 9) and not Emoji 5 (Unicode 10). Do you plan then to update the font along with Android releases?

    * If not, the only remaining freely-licensed font is Twemoji, which will is actually a very good option. Have you considered shipping with it? It’s also more neutral in its design and won’t immediately scream “Android!” to users.

    * Out of curiosity, are every colour font formats that are, and will be, supported by freetype now working thanks to the cairo patch? Since work on layered vector fonts seems to be on the way, and maybe SVG-in-OT one day, I wonder if it will need more work to get them working in Gnome too, or if getting colour for one makes it work for all.

    * Is the list of Emoji symbols in the picker hard-coded or generated from the glyphs the font have? In the former, that’s something to update every year when Unicode release a new version of Emoji. Also there’s the case of not having every Emoji symbols supported by the current installed font, what happen in these cases?

    * Does the work cairo, fontconfig and pango goes beyond Gnome and means support for colour Emoji in other desktop environments? Both GTK based and not. (I’m hoping, perhaps wrongly, that this is full Emoji support for every Linux user!)

    * Is the Emoji picker part of GTK, or Gnome? I mean, will it be reusable easily by other desktop environments which haven’t worked on Emoji UI yet?

    * Last one: it would be nice to have a link between this and the Characters app. Both as a link from the Emoji picker to the full app (like macOS has) so we can also use it as a shortcut for more symbols, and as an updated “Emoticons” section in Characters, with up-to-date and complete Emoji list, possibly with the categories sorting.

    Sorry the amount of questions, I’m just really excited since I’ve been following the state of Emoji on Linux for a while: the news open a lot of thoughts. If some of these points would be better placed elsewhere than in the comments section of your blog, I’ll keenly move them there if necessary. Have a nice Sunday 🙂

Comments are closed.