Colorful typography on the web: get ready for multicolor fonts

May 19, 2014

Fonts on the web have always been a single color deal. But with emoji’s rising popularity, support for multicolor fonts is coming. When can we start using them? How is this going to work in older browsers? And will multicolor fonts actually take off once support is here?

The current situation

On the web, giving color to text is straightforward. We take an element…

<div>I'm single color...</div>

…and color the text inside it with CSS:

div { color: pink; }

The result is something like this:

I'm single color...

Nothing very exciting, right?

What if we want to add some more colors to our letters? Say we’d like to have the letters in dark gray, with a green shine and a pink center:

Until very recently, we couldn’t — there simply was no technique that supported multicolor fonts. OpenType, the font format used on all major computer platforms, has always only dealt in single color. Even in the print world color type is a rarity, and the few font formats that support them are pretty uncommon.

Without a true multicolor font format for the web, we had to work our way around this problem. We’ve been doing stuff like:

1. Overlapping text layers in HTML. This means printing the text in three different fonts, each representing one color layer. When overlapped, they combine to one multicolor font.

2. Image sprites. Instead of letters in our document, we use elements like a span for each letter. We can then use a big image with all characters of the multicolor font, and slide the desired letter into view. This is what Typopixo does, for instance.

3. Fall back to images. We just ditch the whole typographic approach, and create the text in a graphic editor or a script, just like the old days. We simply use an image instead of text.

Each of these solutions gets the job done, to some extent. But complexity, impact on SEO, low accessibility and hefty downloads are just some of the arguments against these techniques. It’s not that they’re all bad, it’s just that they are what they are: workarounds and hacks.

What we need is a true multicolor font format, something that produces selectable, searchable, zoomable, and high-DPI friendly text. Luckily for us, this is coming to browsers soon!

The dawn of multicolor fonts: emoji

Seemingly out of nowhere, big guys like Apple, Google, Microsoft, Mozilla and Adobe are proposing multicolor font formats, and rushing to have them implemented in browsers and OSes. This sudden interest is not so much fueled by typographers, designers or web developers, but by an unlikely group: teenagers.

More specifically: teenagers who demand their communication apps to provide a set of colorful emoji.

Emoji, a specific flavor of smileys, have been unified in a loosely knit semi-standard in Japan for more than a decade. A few years ago, Apple started supporting them on iOS, and in 2010 a selected set of 722 emoji characters were added to the Unicode standard. With emoji being a part of Unicode meant rendering them on the screen was now a job for fonts.

These colorful little icons took off, and today many mobile messaging apps offer them. Twitter even implemented an image fallback for them in their web interface. To some it may look like an unfortunate step back to the AOL-style web of the 90s, to others it’s the moment we’ve been waiting for: support for multi colored fonts!

How to draw multicolor fonts: four proposals

For computers to know how to render these new colorful characters, we need to agree on a way for them to do this — a format. The format in use for most computer platforms is OpenType, and it only knows single color characters. So it needs to be updated on how to deal with colored characters, and proposals have been made by various web companies on how to do that.

These proposals all add tables to a font. Tables are the building blocks of fonts, and each table fulfills a specific function. For instance, the CMAP table maps Unicode letters to the internal glyphs, the little vector images that make up the letters in a font. Others hold copyright information, the vertical metrics, or which ligatures can be used. The new tables will tell the font render software how to handle multicolor fonts.

These are the current proposals, all in varying stages of readiness:

1. Google’s PNG images (CBDT/CBLC tables). Google proposed an implementation which uses PNG images for the glyphs. The glyphs are simply replaced by good old images. This works fine for smaller icons, and obviously brings all the creative freedom of bitmap images, but doesn’t scale very well. Blow up a glyph big enough, and you’ll encounter blurred pixels. It’s also going to be hard, if not impossible, to change the color of the glyphs with CSS. Interesting is that they specify that there should be no GLYF table in their implementation — the table that holds the uncolored “normal” glyphs — so it looks like there’s no fallback for when this format isn’t supported. It’s already implemented in FreeType, which is used on Android and Linux, but a proposal for OpenType would bring this to Windows and Apple machines as well.

2. Microsoft’s overlapped glyphs (COLR/CPAL tables). Microsoft proposed a simple idea that works with what’s already well implemented in OpenType: normal glyphs. Each glyph has one or more accompanying color glyphs, and when they are overlapped they create the final colored glyph. It doesn’t quite have the versatility of PNG images or SVG — it’s just solid shapes on top of each other. They already released their own implementation in Windows 8.1, and Mozilla is working on supporting this in Firefox.

3. Mozilla and Adobe’s SVG (SVG table). These two web giants got together for the most ambitious format: SVG in OpenType. Instead of mapping a Unicode char to a glyph, we map it to an SVG image. This brings us all the lovely extra’s of SVG, including gradients, embedded bitmap images and even animation. It’s already been supported in Firefox since version 26!

There’s one more implementation out in the wild today: Apple’s PNG images (SBIX table), a proprietary system similar to Google’s. It uses PNG images, so it runs into the same scaling problems. Support for this format is in iOS4+ and OSX 10.7+. This spec hasn’t oficially been published by Apple and doesn’t seem to be supported outside the Apple ecospace, and as far as I understand, it’s not been submitted to become an official part of the OpenType format.

Browser support: what’s coming, and what’s already here

So, all these proposals have been accepted to the standard by the Moving Picture Experts Group. This is the organisation responsible for maintaining the Open Font Format — the format better known by Microsoft’s proprietary name OpenType.

Next step: actual browser support.

Browsers can take two approaches to supporting multicolor fonts: they can ask the OS to render those fonts for them, or they can take matters into own hands and draw the fonts themselves.

Microsoft decided to let Windows take care of the rendering for Internet Explorer. Starting from Windows 8.1, a system-level API called DirectWrite can be called upon by Windows applications to draw multicolor fonts with Microsoft’s own COLR/CPAL technique. Internet Explorer 11 is one of the applications that does this. The upside of this approach is that other browsers can use this API to delegate the rendering to the OS, which saves them a lot of work. But that’s also its downside: if the OS doesn’t support it, the browser doesn’t support it. Microsoft’s implementation will then only work on Windows 8.1 and newer, and only in browsers which use this new part of the API.

Firefox takes a different approach: they take care of their own rendering, independent of what the OS supports. They already did this with their own SVG-in-OpenType proposal, and this has the very pleasant upside that this now works in all versions of Firefox: Windows, Linux, Android, etc. Its support depends on whether SVG is implemented in the browser, so it looks like they just need to hook up those two techniques.

Mozilla has also been working on implementing Microsoft’s idea in Firefox. According to this thread, the implementation is being tested now and could hit the streets soon. Mozilla chose to build the support into Firefox itself, instead of relying on the OS-layer, so this too will work on any Firefox browser!

Chrome is working on Microsoft’s approach. It looks like they will let the high level API do the rendering, so this’ll probably be a Windows 8.1+ deal only. They haven’t supported their own proposal anywhere, as far as I can tell.

Safari and Android browsers are somewhere in-between with support: they only render multicolor fonts when they’re installed on the system. That’s why the color emoji samples on the wiki page show up on those browsers, but webfonts included with @font-face don’t.

So, to summarize: Internet Explorer on Windows 8.1+, Firefox on all platforms, and Safari 9+ on OSX and iOS are the only browsers with at least one implementation for webfonts out there today.

And what happens on a browser that doesn’t have multicolor font support? Both Mozilla/Adobe’s and Microsoft’s solution will fall back to normal, single-color glyphs. Both Google’s and Apple’s solution don’t offer fallbacks — you’ll see nothing.

Testing your browser

The table below contains four icons, each drawn with a different multicolor font technique. If the technique is supported by your browser, the checkmark will turn green. If it’s grey, shows an “x” or is missing altogether, there’s no support.

You can also view this test on a standalone page. I mapped the result of my own tests in the following table:

green = fully supported
orange = caveats (only on Windows 8.1 and newer, for instance)
red = no support

Are you using a different or bleedinger-edger browser and you see a green checkmark in the test? Let me know in the comments or on Twitter!

How about icon fonts?

Emoji in Unicode have the advantage that we agreed which Unicode value maps to which character. If we can be sure U+12345x always maps to a barfing smiley, we can google for it. If you’re a restaurant owner, you might be interested in pages mentioning your restaurant in combination with a barfing smiley. Screen readers and other accessibility tools could easily map those icons to plain text descriptions, “Smiley face looking sick and barfing up green bile” – or something more eloquent maybe.

Custom icons don’t share this advantage. We’ll always be mapping random characters to custom images, and no screenreader or webspider will ever know what we meant by U+EF00x.

So will color icon fonts be a thing? Icon fonts have been losing somewhat of its popularity lately. SVG is a more semantic and very well supported contender in this area, and those are a lot easier to create. Common tools like Illustrator and Inkscape can be used, instead of wieldy esoteric tools like FontForge. Icon fonts are a creative hack, but it looks like the web is ready to move on.

But icon fonts might get a second life by using the emoji Unicode range for UI elements. It contains a lot of icons we use in our web interfaces: magnifying glass, folders, user icons, etc. If your custom font isn’t supported, or your website is read by assistive technology like screen readers, at least the browser knows which icon you meant.

Multicolor fonts are definitely coming, but will they work on the web?

While emoji seem hard on their way of earning a place in how we communicate, there’s of course still one thing that’s even more widespread: letters.

Fancy, full color typefaces are reserved for decorative uses: logos or customized magazine-like headlines. Stuff you want the full art-direction of. So why not create that title in Illustrator, and serve the finished product as a single, lean PNG or SVG? Images are already universally supported, after all. It sure beats downloading a huge font file to render a headline of just a couple of words. And it saves you the headache of FOUT.

Before we embrace them, we should consider:

• These fonts can be huge. Even Microsoft’s lightweight solution would triple the amount of glyphs needed just for a simple duo-tone font. Luckily WOFF automatically supports these new OpenType tables, and does a good job in compressing the original TTF file. WOFF2 is coming soon, which should result in even smaller files. But still, the emoji WOFF font on Firefox’s emoji test page is half a megabyte large. Do we want to let our visitors download a couple of MB just to get fancy letters or icons?

• Support in different browsers. You’ll have to serve up an individual font file for each technique. Today this’d mean two font files, one for IE11 on Windows 8.1 and newer, and one for Firefox. I don’t think there’s a way to do feature testing for this, so you’d either have to sniff user agent strings, or serve them both to each visitor. Theoretically the proposals could live together inside one file, but I haven’t found any tools to do this with yet. Which version the browser would choose when it’d support them all remains to be seen.

• Colors are determined by the font maker. The color scheme is hardcoded in the font. This might not be a big problem for emoji, but if you’re going to use a fancy colored font, you want it to fit the design and style of the rest of your website. One might see how Microsoft’s solution could perhaps be addressed from CSS (maybe with an extension to CSS like color-layer1: red;) — but that’s assuming the font shares one palette. If each character has its own set of colors, like emoji, this is going to get messy fast. And changing color of PNGs or SVGs seems nearly impossible.

• Render performance. Getting that font to show up might be CPU intensive, especially on mobile. Implementations will surely be optimized over time, but for now this Mozilla test page seems to be very slow on my PC.

• Accessibility. Color can spice up your design, and it can add meaning to text or UI elements — but only when done well. Multicolor fonts can reduce legibility of text, especially when the human using your website is color blind. There is currently no way to force the multicolor font to use its non-color fallback.

Conclusion

How will multicolor fonts change the face of the web? Will we go crazy with ‘em in our websites, once they’re well supported? Will they make the web better, more beautiful, or will it add bloat and fragmented support? It’s hard to predict, but you can bet we’ll find an excuse to use them.

Two browsers out there already support them. Maybe your next web project could benefit from a little colorful text!

If you’d like to read more about the tech behind these font proposals, this article by Adam Twardoch in an excellent start.