Chromatic fonts are coming

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing.

Outline fonts historically define their constituent glyphs with just two "colors": the foreground color inside the character's contours, and the background color that lies everywhere else. On a generic document, those colors usually equate to black and white, although both can be assigned to other colors in virtually every application. But this situation is misleading; when applied to digital fonts, the term historically only takes one back a few decades. Typefaces in other media have existed for centuries, and were never restricted to black and white. So it should come as no surprise that there is a push to adapt digital font formats to natively support multiple colors. At TypeCon 2013 in Portland, there were in fact two competing proposals under discussion: one advocated by Microsoft, and one backed by Adobe and Mozilla.

In graphic design circles, the term "chromatic fonts" is used to describe fonts built to support multiple colors. Today, chromatic fonts are generally incorporated into designs by taking a set of fonts with complementary shapes and layering them in software, one color per layer. A good example would be the HWT American Chromatic system from Hamilton Wood Type, a digitized font family based on 19th Century woodblocks. The different layers would be combined in layout software, such as Adobe InDesign, Photoshop, or Inkscape. For the web, there are other approaches, such as Colorfont.js, which we looked at in 2012. But even with software support, layering and aligning blocks of text in multiple fonts is tedious and error-prone. It would be simpler if the font could support regions of different colors out of the box.

There is, however, a use case for multi-color glyph support in fonts that is completely unrelated to multi-color type as graphic designers use, which is what leads to the two competing proposals. The second use case is emoji, the character-sized pictographs popular in text messages and online chat applications. While emoji are relatively popular everywhere, as Microsoft's Michelle Perham explained in her TypeCon talk, they are a far bigger deal in Japan, where they originated with mobile phone operator NTT DoCoMo. DoCoMo and its two largest competitors in Japan, KDDI and SoftBank, standardized on a common set of emoji in the mid-2000s.

While the standard was originally only used in Japan, it was accepted into the Unicode 6.0 specification in 2010, incorporating 722 symbols. The standard emoji set has since spread to many other mobile and Internet platforms, with one of the most notable being Apple's iOS. iOS 5 was the first Apple release to support emoji in every region of the globe, but iOS 6 took things a step further in late 2012 by rendering the emoji glyphs in multiple colors. As would be expected, this proved to be a big hit among the demographics that care about emoji, and, in June, Microsoft announced at one of its developer events that Windows 8.1 would feature color emoji, too.

My emoji

However, while Apple's color emoji implementation was a custom iOS-only solution, Perham said, Microsoft decided instead to implement its color support by adding a set of extensions to the OpenType font format. OpenType already supports a large set of extensions through the use of "feature" tags, which are text tables that usually describe character-matching expressions, substitution rules, spacing adjustments, and so on.

Microsoft's new tags operate a bit differently from the most common OpenType tags. The first is called colr (following the convention of four-letter-or-less tag names). The base emoji glyph is a black-and-white outline character as it is in existing fonts; a colr table is attached to it, which contains a list of additional glyphs, one for each color used, along with an indexed color value for each glyph (these indexes are mapped to colors in another structure, discussed below). The list also indicates the z-order in which the color glyphs are meant to be stacked. If the device or application wants to display the color version of the character, it just looks up the components in the colr table and composites them together. If it does not care about color, it can use the black-and-white base glyph like normal.

The actual color that each of the components should be rendered in is listed in the second addition to OpenType, the cpal (for "color palette") table. The cpal table encodes a color palette as a list of RGBA values. The table must include one such palette (palette number 0), but it can offer alternate palettes as well, leaving it up to the software how best to expose the palette options to the user. Perham pointed out that Apple's color emoji font took a great deal of criticism by rendering all of the human face emoji in decidedly Caucasian-looking colors; supporting multiple palettes offers a relatively simple and space-efficient fix.

At the moment, Perham said, creating these color fonts is a manual process, since no font editing software supports the new tables or rendering in color. But Microsoft is moving forward with the fonts for Windows 8.1, and believes the system is flexible enough to be used for other multi-color symbols or for general typographic usage. Currently, Microsoft's proposal is under discussion on the mpeg-OTspec mailing list; one must join the list to read the messages or the posted files (including the specification), but joining is not restricted or moderated. Microsoft has also announced its intention to formally submit the proposal for standardization by the ISO, which maintains OpenType as ISO/IEC 14496-22.

SVG

While Microsoft's solution is sure to reach users in short order, it is not the only proposed system for adding color glyph support to OpenType. There is one competing extension that can also be tested today: the SVG glyphs for OpenType proposal, which is being developed by a World Wide Web Consortium (W3C) community group with most of the input coming from Adobe and Mozilla. Mozilla and Adobe had each drafted its own proposal, but the two were merged into a single draft specification in July 2013.

The draft adds a single table to OpenType named svg. This table can contain any number of SVG objects, and an index that associates each object with a glyph encoding slot in the font. In that sense, it differs considerably from Microsoft's specification, because it references a completely different data type for the "color version" of each supported glyph. There is also a color-palettes subtable, which lists one or more sets of RGBA colors that can be used to draw the SVG elements.

Just before TypeCon, Mozilla's Robert O'Callahan posted an update on the draft proposal. O'Callahan has added support for SVG-in-OpenType fonts to his personal builds of Firefox, and has also made a web application to add SVG support to existing OpenType font files.

The most frequently-cited advantage of the SVG-based approach is that, by adopting an existing and well-known standard for the color elements, OpenType avoids defining yet another graphics format. The software stack would have to be modified in order to render the SVG glyphs, but it could simply hand that duty off to the system's existing SVG renderer. In comparison, the Microsoft colr approach would require modification to the text rendering process as well, but with entirely new code.

In addition, although at the moment the emphasis of both proposals is on relatively simple, flat-color rendering, the SVG proposal can also include other design features that would be of appeal to graphic designers, such as color gradients, without further alteration. It can also incorporate animated elements, which seems to be regarded by many as the next step in the "evolution" of emoji. The principal drawback, of course, is that SVG itself is a large and complex standard. Incorporating SVG in OpenType fonts would by necessity require defining a "safe" subset of SVG to support; no one is keen on the notion of embedding streaming video elements into font glyphs.

Or at least no one seems interested in such a feature today.

The future

The reality on the ground, though, is that no one is quite sure what type designers will come up with when creating chromatic fonts with either proposal. Gradients, of course, seem like a natural fit; one can already see graphic designers applying gradient effects to plenty of typefaces on the web and in print, and it is a clear analog to the effects that can be produced with ink and a letterpress. Animation is not quite as easy to predict; it is simple to imagine terrible eyesores created with animated fonts, but then again one can already design terrible eyesores with any number of existing web standards today.

Both proposals have a long road ahead before making it into a standard. Microsoft, of course, is marching ahead with its own implementation in the meantime. The SVG-glyphs-for-OpenType group held a meeting during TypeCon (which I did not attend); there is more discussion scheduled for the coming weeks and months. As a practical matter, what the industry's type designers and graphic designers find more useful is ultimately what matters the most, but it could still be many years before chromatic fonts become widespread. On Sunday, type designer Crystian Cruz gave a presentation showcasing many of the advanced effects that are already possible with OpenType's existing features—including randomization, contextual substitutions, and character forms that adapt to fit the available space. But the majority of these features are rarely, if ever, employed by existing fonts, and they have scant support in software. Whether the popularity of emoji is enough to spark a larger revolution in chromatic fonts remains to be seen.