Color fonts. Overview of the proposals for color extensions of the OpenType font format.

By Adam Twardoch on 2013-09-19 in News

Although Fontlab Ltd. debuted the Photofont technology some 8 years ago, the typographic community did not show much interest for multi-color fonts or typography. In 2013, it changed. Actually, this started a few years ago with Apple introducing the color emoji font into iOS, and then Mac OS X 10.7. Now, all major industry players (Apple, Adobe, Mozilla, Google and Microsoft) have proposed their formats, which aim to extend the OpenType font format by the ability of including color glyph information. The proposals differ in many aspects. Below is a discussion of the proposals along with some personal comments.

This article is very technical. No completeness or correctness of the information presented below, and all views are personal.

The video tutorial by Adam Twardoch accompanies this article by providing a more practical take on color font creation issues.

Concepts

There are several conceptual approaches for “color fonts” that can be considered, in increasing order of complexity:

• a] per-PPM bitmap strike definition, without any scaling
• b] scalable bitmap glyphs with multiple “master PPM sizes”
• c] one scalable bitmap glyph definition across all PPMs
• d] layered outline glyphs, one solid fill per layer
• e] static outline glyphs with complex fills and optional bitmap content
• f] animated variant of e]

Approaches

We have now four distinct approaches from the major vendors, in increasing order of complexity:

• GOO: Google CBDT/CBLC tables — a] or b], unclear
• APP: Apple sbix table — b] concept
• MIC: Microsoft COLR/CPAL tables — d] concept
• SVG: Joint Adobe and Mozilla SVG  table — e] concept, possibly expandable to f]

Considerations

There are also several considerations, or aspects, which each implementation needs to address.

• Co-existence: regardless of the possible size inflation, whether several approach can co-exist within the same SFNT font file. This includes questions such as precedence (what should happen if a consuming platform “understands” multiple approaches) or structure sharing (whether the same structure, e.g. the PNG image data or a color palette, can be shared by multiple approaches). In particular, the question of co-existence of the new structures with old ones (glyf or CFF  table) is important.
• External modification: especially with the outline approaches, whether the colors specified within the SFNT font file can somehow be manipulated/modified externally by the consuming platforms. This also includes more specific questions such as, in case of the SVG-based approaches, controlling animation or, if the consuming platform is a web browser, interaction with the document’s DOM.
• Fallback/degradation: related to co-existence, how the color data should be represented in environments that only support grayscale or even monochrome data. Adobe’s Leonard Rosenthol has raised a number of fundamental issues on this in context of the SVG discussion. The discussion makes, I hope, an interesting read: the “Glyph bbox concerns” thread, [1] and [2].
• [1]  http://​lists​.w3​.org/​A​r​c​h​i​v​e​s​/​P​u​b​l​i​c​/​p​u​b​l​i​c​-​s​v​g​o​p​e​n​t​y​p​e​/​2​0​1​2​J​u​n​/​t​h​r​e​a​d​.​h​tml
• [2]  http://​lists​.w3​.org/​A​r​c​h​i​v​e​s​/​P​u​b​l​i​c​/​p​u​b​l​i​c​-​s​v​g​o​p​e​n​t​y​p​e​/​2​0​1​2​A​u​g​/​t​h​r​e​a​d​.​h​tml

Detailed discussion of approaches

GOO: Google CBDT/CBLC tables

Bitmap-based (PNG) glyphs, either as per-PPM bitmap strike definition, without any scaling, or as scalable bitmap glyphs with multiple “master PPM sizes” — this is unclear (see below for details).

Announced in May 2013 on the Google blog [GOO1], this is an approach which specifies two tables (CBDT/CBLC, [GOO2]), which in turn extend the existing OpenType EBDT/EBLC tables [GOO3], [GOO4] by adding the ability to include uncompressed color images or PNG images. Those, in turn, are extended version of Apple’s original bdat/bloc tables which have a long history.

Google hosts a “Color Emoji” project dedicated to this [GOO5], have created a Python tool which embeds PNGs into that table [GOO6] and have provided sample fonts. FreeType 2.5 now also includes support for this [GOO7], added on May 29^th.

APP: Apple sbix table

In the current implementation: bitmap-based (PNG) glyphs, as scalable bitmap glyphs with multiple “master strikes” per PPM. The sbix spec has provisions to hold other types of glyph definitions, such as TIFF, SVG, PDF or even movie clips, but this is not very clearly specified nor implemented.

Apple’s is the first implementation that has been officially deployed. It was introduced to iOS 4 and also runs in CoreText applications Mac OS X 10.7 and newer. It does not run on ATSUI applications such as Pages 09 or Keynote 09, but does work in CoreText applications such as TextEdit or Safari. Support for sbix table with PNG glyph has also been added to FreeType.

The spec of the table has not been officially published by Apple, but has been shared with interested developers. The implementation hosts PNG data inside the sbix table, with multiple PPM “master bitmaps” possible per glyph. The scaler is responsible for choosing the most appropriate PPM size and scale it to other PPM sizes as needed.

It seems that per “master strike”, both the PPM and DPI information can be provided. For the metrics, the implementation relies on the bounding boxes stored in the glyf table. It seems that, very unfortunately, the Apple implementation renders the contents of a glyf table glyph, and the on top it renders its associated bitmap — so if bitmaps are available in the sbix table for a particular glyph ID, the corresponding glyf glyph ID slot has to be empty.

Mac OS X 10.8 includes one font with the sbix table: Apple Color Emoji, while iOS 6 includes the former along with Apple Color Emoji@2 (the latter hosting the glyphs in double DPI resolution, it appears).

A reverse-engineered incomplete and faulty spec has been published [APP1] and [APP2], and a patch for fontTools/TTX has been published [APP3]. Those do not seem to work correctly, though. However, Fontlab Ltd. has implemented its own sbix reading and writing, which seems to work correctly. Fontlab Ltd. also has its own sbix renderer, and I have successfully built Latin-script color fonts with the sbix table and OpenType Layout features such as calt, and that font works as expected in Mac OS X 10.7 and 10.8 (hooray!).

MIC: Microsoft COLR/CPAL tables

The newest member in the family of solutions, announced by Microsoft’s Michelle Perham and Si Daniels on June 26^th [MIC1], the Microsoft proposal looks quite simple and clever to me, judging from the announcement. It adds a relatively lightweight baggage of COLR and CPAL tables which results in layered outline glyphs with one solid fill per layer.

The MIC approach is implemented in Windows 8.1, with a new Segoe UI Emoji font being included in the OS. A video from Microsoft’s Dan McLachlan talk where he presents the approach is available [MIC2] (about 9 minutes into the talk). Also, Michelle Perham made a presentation at TypeCon 2013 dedicated to the topic.

The approach uses a base glyph (glyf or, presumably, also CFF ) which is used for non-color situations. The COLR table refers from this glyph into other outline glyphs (which exist within the same table), which serve as layers. Each “layer glyph” has its own z‑order and a single color references. The color references are handled has palette indices, with a separate table, CPAL in OpenType that resolves the RGBA colors actually used for the glyph. Therefore, both the COLR and the CPAL tables should be quite small in size, all the heavy-lifting being done by the traditional rendering methods. It was announced that Microsoft plans to publish the specs for the tables within the next few weeks.

SVG: Joint Adobe and Mozilla SVG  table

The “full Monty” outline+bitmap (SVG) glyphs with possible animation.

This is a proposal formulated by Mozilla’s Edwin Flores and Cameron McCormack, with input from Robert O’Callahan and Adobe’s Sairus Patel, which has been submitted as an unofficial editor’s draft a Final Community Group Specification to the W3C [SVG1]. There is a reasonably well-working SVG OpenType community for this [SVG3] and a public mailing list [SVG2]. As indicated on Robert O’Callahan’s blog [SVG4], this proposal has been implemented in Firefox — it’s off by default but can be enabled by toggling gfx.font_rendering.opentype_svg.enabled in about:config. Also, a tool, written in Python, is available to create such fonts [SVG5].

This is the by-far most complex proposal, as it puts the bar quite high for implementers (it requires a full SVG renderer, and has provisions for animated glyphs). On the other hand, its great advantage is that, once an app has access to the SVG renderer, it can delegate the rendering of the glyphs completely to the SVG library. So the app only needs to call an OpenType Layout library to perform the layout, and then call the SVG renderer for each glyph, and position the rendered bitmaps. So in fact in an SVG-compatible environment using the SVG table would be trivial.

The SVG proposal allows for designs that cannot be achieved by the other solutions: it implements “rich color” (with gradients etc.), allows for drawing various strokes and, of course, intermixing vectors and bitmaps. So it’s potentially very very powerful.

Sairus Patel explained to me at TypeCon that he considers the current proposed spec as “good to go”, and that’s the spec that is implemented in Firefox.

Personal conclusion

In my view, each of the presented approaches has its advantages and disadvantages.

The Proposals

The APP proposal is great in so far that it’s actually already implemented. However, the interaction of the sbix and glyf tables as implemented in Apple OSes has its serious drawbacks (no fallback scenario). Also, it’s unknown whether the sbix table would ever make its way into the official ISO OFF or OpenType specs.

The MIC proposal only “goes color” in a limited scope — it provides a way to render multilayer glyphs with solid fills. But they’re outline glyphs, so they should scale nicely.

The GOO and APP proposals use PNG as their vehicle, so they can have complex fills but would fail in high-resolution scenarios. FreeType already implements the APP proposal with PNG glyph definitions, and the GOO proposal — so it looks like adding support for them was quite easy.

The GOO approach has advantages in so far that it ties into an existing infrastructure of tables, but my fear is that these existing table concepts may be abused (no reference to how scaling should happen). Also, GOO’s insistence over non-presence of the glyf table is very limiting, and not understandable: they say they want their extensions to go into the official EBDT/EBLC tables, but those tables make no such requirement.

In principle, the MIC and GOO approaches could be easily “married together”: the MIC proposal would be useful for multilayer glyphs with solid fills, the GOO approach for glyphs which require more refined bitmap treatment, and fallback scenarios could be defined rather well.

The SVG approach is very welcome, and, as I said, a kind of “2.0” thing. I believe the discussion on them should continue, even if implementations of those could be confined to only the web browser context. Also, Firefox actually already implements the SVG approach, which is very good news.

Color Palettes

As for color palettes, I consider its addition to font formats (whether through a unified and further developed CPAL table or through several separate mechanisms) as third element of typographic user control.

Historically, the first user control mechanism was just the cmap table: the user’s control over a font was limited to just entering a string of Unicodes, and picking the font size — and the rest would be done by the font.

The second mechanism was the addition of the GSUB/GPOS tables: user’s control was extended by the ability to specify OpenType Layout features that should be applied to the text.

And now, we’re extending the user’s control by adding ability to specify multiple colors through the font’s color palette.

Relation to Existing Solutions

When comparing the outline color font format proposals, I would use the following analogy:

• First personal computers had black-and-white monitors so they only could display one color. That’s like the current monochrome font formats.
• Then, computers could display 16 colors at the time, and later even 256 colors. The GIF graphics format dominated the early days of the web, and it supported up to 256 colors. So that was the “flat color” implementation, and that’s exactly what the MIC proposal is.
• Finally, computers gained the possibility to display over 16 million colors, and graphic formats such as JPG and PNG were developed to support this. That allowed for “rich color” applications, and this is analogous to the SVG proposal.

Before color fonts, OpenType had three separate possible glyph sources:

• embedded bitmaps, which could be monochrome or grayscale, in the bdat/bloc/EBDT/EBLC/EBSC tables
• TrueType outlines in the glyf table, which was a very straightforward structure that allowed little design flexibility but through its sophisticated hinting mechanism gave the designer a lot of control over the rasterizer
• PostScript outlines in the CFF  table, which did not give that precise control over the rasterizer through hinting, but was a relatively complex structure that came “supercharged” with some features that were not fully explored to date: fractional point coordinates, the FontMatrix mechanism which allowed on-the-fly skewing, scaling or rotation, and even Multiple Master, which was dropped from the spec.

All three solutions “co-existed peacefully” in the monochrome font world.

The GOO proposal plugs directly into the embedded bitmaps mechanism, but extends it with color.

The MIC proposal extends the glyf table and provides a simple solution for “flat colors”, but is quite limited beyond that. Yet it allows precise hinting.

The SVG proposal is a cousin of the CFF  table: it’s technically the most complex, and requires a very smart, “active” rasterizer. It does not offer hinting but allows more complex design solutions than the other proposals.

I hope that a similar “peaceful co-existence” can emerge for the color proposals that had existed for the monochrome solutions. Each of them has its merits and none of them is sufficient by its own.

Finiteness

There is one more consideration that I should mention: “finiteness” of the proposals. By that I mean whether the limitations of what a given formats aims to achieve in the end is now clearly defined. This is closely related to stability of implementations, meaning: if, as a developer, I invest the time to implement a given format now, will I have to revisit it in the future?

Superficially, an “extensible” structure is appealing. “Oh, this structure is infinitely extensible, we can add so many cool stuff to it later”. But in many cases, an infinitely extensible structure also poses risks. Software developers have limited time windows to devote to fonts and text technology. They often want to implement something and be done with it for the next years. So somewhat paradoxically, a proposal that clearly and consciously states its limits is actually attractive because it doesn’t leave open questions.

The GOO proposal seems to be the best example of such self-limiting format. It extends the existing embedded bitmap formats by adding just two or so new subformats, and that’s it. There may be one or two open questions now (the scalability issue I discussed), but once those are answered, and developers add support for it, it’s a done deal. The GOO proposal does not leave many loose ends.

In other words, the GOO proposal doesn’t try to cook many dishes at the same time or doesn’t try to be a “catch all solution”. Instead, it aims to do just one thing, and to do it very well. Which is, I believe, where its real beauty lies. Also — just like the older embedded bitmap formats — it can be used to host bitmap-only glyph data, without any outline fallback. This actually is quite desirable for some scenarios such as fixed-size devices — simple electronic displays (brick phones, scrolling electronic banners, diplays in car radios or other portable electronics).

In constrast, the APP proposal limits itself very vaguely. The sbix table spec says that it can host a huge variety of possible glyph formats, from PNG through TIFF and JPEG, SVG and PDF to even movie clips. Attractive in principle, it also may be a bit “scary”. The current APP implementation isn’t actually sbix. It’s “sbix with PNG glyph data”. But there could be “sbix with SVG data” or “sbix with MOV clips”. This means that develpers who choose to implement “sbix as a whole” may end up struggling to support various glyph data sources, and they may never be sure whether something new wouldn’t pop up in future.

The MIC proposal quite cleanly defines its current scope, though Greg Hitchcock has suggested during the TypeCon meeting that Microsoft may in future extend their format to support “more things”, like gradients. However, knowing Microsoft’s practice, they would most likely extend it in a transparent, backwards-compatible way (so, for example, a gradient would fall back to a solid color). At the current stage of the proposal, CPAL and COLR are nicely defined. CPAL may undergo some revisions, especially if (hopefully) both the COLR and the SVG  tables make use it, i.e. if Adobe, Microsoft and Mozilla come to common terms regarding some minor CPAL extensions.

Interestingly, the SVG in SFNT proposal, although very ambitious in terms of graphic effects you can achieve, is actually fairly clearly limited. Again, some wrinkles need to be ironed out, and animation is a big open question, but if we limit ourselves to static SVGs, the principle is very simple: the SVG in SFNT format only defines a container format for the data, and clearly delegates everything else to the SVG standard proper.

This is actually a fairly stable proposal. It means that, as a developer who implements it, you’ll need to keep up with the evolution of SVG proper, but — if you do have an SVG renderer implementation — you’ll want to do it anyway. But the SVG in SFNT makes (more less) a promise that they won’t bother you greatly with doing big changes in future that will be font-specific. So as long as you’ve implemented the SFNT SVG  table once (hopefully the revised one which shouls reuse CPAL), you’ll be done at the font end. Then, you’ll just need to keep up with your general SVG renderer as you normally would.

So with SVG, if your application does not have an SVG renderer, it’s a “big step” that you’d need to do, but you’d only need to do it once. (And perhaps it would be a good idea to do it anyway, since SVG is a graphics format that may be useful is supporting regardless of fonts). But once you’ve done it, all future steps you’ll have to do will likely be very small and will “just happen”.

In fact, I think the GOO mechanism would serve as an ideal fallback to SVG. Since SVG can contain scalable graphics which intermix vectors and bitmaps, the results can be very complex. But they could be pre-rendered and put into the CBDT/CBLC tables as well. It could be similar to how pre-rendered PNG bitmaps are (or used to be) often served by websites to older browsers which don’t support SVG. You’d lose the smooth scalability, but you would at least get the intended glyphs appearance.

Support by FontLab apps

Fontlab Ltd. will soon be releasing a free app for Mac and Windows called FontLab Pad which will allow users on both OSes to use fonts that implement any of the above proposals (currently the APP and MIC formats are implemented but more support is being added as we speak). Also, FontLab’s TransType 4 allows simple creation of MIC-compatible fonts through overlaying existing “layered fonts” and assigning each layer a color. TransType can also output APP-compatible fonts with the same contents. In combination with FontLab’s BitFonter 3, TransType 4 can be used to produce sophisticated full-bitmap color fonts in the APP-compatible format.

At FontLab, we are very happy with this development and support it fully. Our upcoming font editors will support multicolor fonts natively, with layers and potentially also complex fills, so fonts in all color formats (including SVG) can be created.

Adam Twardoch

Adam Twardoch is Director of Products at FontLab, and a font consultant specializing in font technology, multilingual typography, CSS webfonts, Unicode and OpenType. Co-designer of Lato, the world’s most-popular independently made font family (by Łukasz Dziedzic), and of Milka (by Botio Nikoltchev). Co-creator of OpenType Font Variations and CSS Fonts specs. In 2000–2014, technical and linguistic consultant at MyFonts, the world’s largest online font distributor, and board member of Association Typographique Internationale (ATypI). Adam regularly teaches workshops in font creation. He lives and works in Warsaw and Berlin.