Emoji: Fonts, Technically
Making Faces (and Other Emoji)
Hey all! I’m Colin (@colinmford, here and on twitter), a typeface designer. I write short posts about the history, design, and technical details of emoji from a type designer’s perspective. You can find the other posts here. I also run workshops occasionally that help you design and build your own emoji from scratch.
The last post laid some foundation regarding some of the technical history of emoji fonts. This post will discuss specific OpenType tables in-depth, as well as a way to get them on the web while support for emoji coalesces, and emoji ligatures!
We left off last time with an overview of the four table “formats” of emoji: Google/FreeType’s CBDT/CBLC, Apple’s sbix, Microsoft’s COLR/CPAL and Adobe/Firefox’s SVG . Let’s talk about the advantages and disadvantages each one.
Google’s CBDT/CBLC and Apple’s sbix
The Google/FreeType CBDT and CBLC tables get first mention here because they are the most simple. Their 4-letter table names translate to “Color Bitmap Data Table” and “Color Bitmap LoCation”, respectively. The tables build off of a set of tables that were made for black-and-white and grayscale bitmaps, a hold over from the early days of TrueType. Together the two tables allow PNG images to be used in place of letters in a font. The CBDT holds the bitmaps, the CBLC contains instructions on when to use them. The tables are currently implemented in FreeType, which forms the basis for text rendering in many environments, such as Android, many Linux platforms, and some versions of the Firefox browser.
Apple’s sbix table is very similar, but it does all this in one table. Sbix is currently only implemented on OS X and iOS, and only in applications that use the system’s font renderer, like TextEdit and Safari. It’s currently also the only table here that is proprietary—while Apple freely publishes its details, all the other tables are a part of the OpenType specification and sbix is not. “Sbix” stands for (I think) “Scalar Bitmaps”, which will make sense in a moment.
The ability for fonts, which have been vector files since the first PostScript fonts in the mid 80’s, to employ full-color bitmap PNGs is a little strange at first. But it allowed for the glossy, high-resolution, gradient- and drop shadow-rich skeumorphic design (😄) that Apple wanted in their emoji (which matched their iOS interface design up until iOS 7 📱). But still, the emoji font they are contained in can be used like any other vector font—scaled to any size. How do they get around having scaled up or scaled down pixellated emoji PNGs?
To me, the coolest thing about the Google and Apple tables is you can specify multiple images per emoji, one each for a range of sizes. The system can tell the font what size it is set at, allowing the designer to optimize a PNG for specific range of pixels. This way one image doesn’t have to stretch to cover every size. Each size-specific bitmap is called a strike. Between each strike size, the font will scale down the next largest bitmap to fit. For instance if your strikes are at 20ppm, 128ppm and 512ppm (“pixels per em”), the operating system should show the 20ppm image up till 20px, the 128ppm image from 21px to 128px, and the 512ppm image from 129px to infinity. If you’ve ever made a responsive website using css breakpoints, the concept is very similar.
Using strikes, you can adapt your design to its intended size. For instance, you can make some details bigger the smaller the type size — super-size facial features to play to the back of the theater, for instance. Conversely, you could make the larger emoji more proportionally accurate and add details that would otherwise complicate the smaller sizes. Apple doesn’t take advantage of this in their current set of emoji, but it is a very common practice in another area of their operating systems: application icons. All icons in OS X and iOS come as a package of icon images. The multiple sizes act like strikes, and allow Apple to make subtle adjustments to clarify the design at every size.
In a strange way, these tables, made for emoji, give type designers something they’ve always wanted: optical size responsive fonts. Being able to adjust the design of a font based on the point size would be huge news if not for a few catches. First, this responsiveness only lives in the sbix table, on Apple systems, for now. Second, if you wanted to use it for fonts, the user would not be able to change the color of the type (because they are images). And Third, this method makes the files HUGE. If you were to put an sbix emoji font on a web page, you would essentially be forcing your visitors to download a folder of thousands of PNGs. Apple’s emoji font file is 69.1MB presently, so big it would probably make most web developers faint. Ironic that the most responsive format results in files too big to put on the Internet.
In the future, the sbix table might support vector PDFs or even MOVs instead of just images. PDFs would allow for detailed, more file size-efficient emoji that would easily scale between strikes. MOVs, while certainly increasing the file size quite a bit, would allow designers to create animated emoji, like from the SoftBank and KDDI days. The only problem is there’s no OS X or iOS version that supports them yet. In a blog post, Adam Twardoch (of FontLab) says this sort of “catch-all” approach might open a Pandora’s box.
Microsoft’s COLR/CPAL
One option for non-bitmap emoji that is available today is the Microsoft COLR and CPAL tables. The benefit is that it uses the same scalable vector outlines that are the basis for all OpenType files. The layers of the emoji are split up by color into differs glyphs and recombined in the program. COLR specifies the order of the outlines and CPAL specifies the color palette. Using COLR and CPAL, you can reuse components of your designs over and over, like faces, eyes, and colors, without including them more than once. You can even specify multiple color palettes for the end user to choose between (potentially, I’m not sure any interface actually implements this quite yet). Useful if you wanted to use a colorful version in one situation but a grayscale version in another, for example.
COLR/CPAL is supported on Windows and in modern versions of Firefox on most platforms, making it the most widely supported format so far.
The COLR set up requires you to separate colors into individual glyphs, which is a strange design pattern and takes some getting used to. Also, the vector format does not allow for the gradients and glossy finishes that is the bread and butter of many emoji sets (though apparently they are thinking about adding support in the future). This is not a problem for Microsoft’s own emoji, however, because they chose a look that is very “flat”. Those wanting to recreate an Apple look, however, might find this format currently lacking.
Adobe/Firefox SVG
The “SVG ” table is sort of a compromise. It is refreshingly easy to understand: the table just serves as a container for SVG documents, 1 per glyph. It is supposed to support everything SVGs support, like gradients and transparency, even SVG animation. There are no strikes, but in some places SVGs support media queries, so it’s possible that in the future the SVG table could provide the responsive qualities of sbix. At this time “SVG-in-OT”, as it’s called, is only supported by the Firefox browser (if you are using that, you can see a demo here). Though other browsers might still take up the charge, as the specification is with the W3C, the standards body of the Internet. I also assume that when Adobe Creative Suite programs support emoji, this is the format they would choose—but as of yet I don’t know of any plans. More on the format on Adobe’s TypeKit blog.
These days the state of emoji support very much reminds me of the early days of web font support. Around 2012 there were half a dozen formats supported variously by browsers, but now support had mostly coalesced around WOFF. I suspect something similar will take place in the emoji world, but it might be some time.
If you want to see which tables your favorite browser supports, check out the great ChromaCheck tool by Roel Nieskens, also available on GitHub.
Javascript Emoji
The last option I would like to discuss was also a common way to support fonts on the web before web fonts: hack it with JavaScript. Twitter and Facebook, instead of using emoji fonts in one of the formats above, simply search their pages for certain Unicode characters and replace them with inline images. Twitter has open sourced their emoji (“Twemoji”) and the javascript behind it on Github. If you know how to work with JavaScript, it would probably not be too hard to adapt it to your own site and swap out the emoji images for your own.
This might be the quickest and most web-standard way of getting custom emoji to your audience (if your audience is on the web, that is). Your users don’t have to download a 1000-some glyph emoji font on page load, just images or SVGs as-needed (no need to download that mahjong emoji 🀄️ unless you really need to). It would support animation (if you swap in animated GIFs, MOVs, SVGs, or what have you), and maybe even strikes if you wanted to build that into the JavaScript. But there are reasons why JavaScript font replacement fell out of use in favor of a pure web font option (sIFR or Cufón, anyone?), and those reasons apply here as well.
Emoji Ligatures and the ZWJ
The final two things I want to mention are modifiers and emoji ligatures. Ligatures, in a normal font, are a combination of glyphs into a single glyph, like “f” and “i” into “fi”. They get more interesting with emoji.
In these three seemingly innocuous emoji “🇯🇵 👨👩👧👦 👍🏽” are actually 9 different glyphs. One glyph in particular is used 5 times! Let’s unpack each example.
Flag emoji like 🇯🇵 are ligatures of special country code glyphs called “Regional Indicators”. There are 26 of them, one for each letter of the Latin alphabet, and two combine to make a flag. For instance, there is no Unicode number for the Japanese flag emoji 🇯🇵, it is made up of two indicators: REGIONAL INDICATOR SYMBOL LETTER J + REGIONAL INDICATOR SYMBOL LETTER P.
A family set like 👨👩👧👦 is a more complex ligature. It is composed of a man (👨), a woman (👩), a girl (👧), and a boy (👦), all conjoined by what is called a “zero-width joiner” or “ZWJ”. A ZWJ is like the glue in emoji ligatures. It is invisible to users and cannot be typed on a keyboard. So as such, one cannot type out a man, woman, girl and boy and expect them to be automatically combined. Vendors and the Unicode Consortium probably thought this would be unintuitive. If sent from a platform that supports this ligature to one that doesn’t, the ligature will fall back to its parts, just like an “fi” ligature will separate to an f and an i.
Ligatures like these are called “ZWJ Sequences” by the Unicode Consortium, you can find a full list of them here.
Finally 👍🏽 is an emoji ligature of the thumbs up 👍, a ZWJ, and a skin color swatch called a “skin tone modifier”. The skin tones are based on the Fitzpatrick scale, which categorizes human skin tones on how frequently they burn or tan when exposed to Ultraviolet light. There are six divisions on the Fitzpatrick scale, from whitest white to darkest brown. The Unicode Consortium combines the first two types, so in emoji there are five skin tone modifiers.
The inclusion of the skin tone modifier in Unicode 8.0 seemed to have opened the floodgates because now there are proposals for gender, direction, and even hair color. The implications of allowing users to customize the look of emoji with modifiers might be best discussed in another post.
ZWJ glyphs aren’t unique to Emoji. Before they were tasked with bringing families together and changing skin colors, they made themselves useful in scripts like Devanagari, Kannada, Arabic, and Malayalam. In Malayalam, up until Unicode 5.0, Unicode support was lacking for a few key glyphs. ZWJ ligatures helped to enable the transmission of those characters until Unicode caught up. Essentially ZWJ ligatures can be a way to fill in support for glyphs that Unicode hasn’t standardized yet.
These ligatures can get really fun with emoji. For instance you might want to make ZWJ ligature with the rainbow emoji (🌈) and a white/blank flag (🏳) to make a a rainbow flag emoji! Another example might be to combine the “no” emoji (🚫) with the dancer (💃) to make a no dancing emoji (useful if you are Kevin Bacon’s dad in Footloose). If these ligatures aren’t supported in another emoji font, the pairs will just fall back to their rebus forms: 🌈🏳 and 🚫💃, respectively. To implement these in your emoji font you can use OpenType features to make a many-to-one ligature.
That’s it! Next article I really want to show how to use the RoboChrome tool to make emoji fonts in each of these table formats.
Thanks for getting to the end of a very technical article. And thanks for all the great comments! If you liked it, check out my other articles on emoji, maybe subscribe to the mailing list, and/or click the “recommend” button 👇
