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

By Adam Twardoch on 2013-09-19 in Color Fonts

Although Fontlab Ltd. debuted the Photo­font tech­nol­ogy some 8 years ago, the typo­graphic com­mu­nity did not show much inter­est for multi-​​color fonts or typog­ra­phy. In 2013, it changed. Actu­ally, this started a few years ago with Apple intro­duc­ing the color emoji font into iOS, and then Mac OS X 10.7. Now, all major indus­try play­ers (Apple, Adobe, Mozilla, Google and Microsoft) have pro­posed their for­mats, which aim to extend the OpenType font for­mat by the abil­ity of includ­ing color glyph infor­ma­tion. The pro­pos­als dif­fer in many aspects. Below is a dis­cus­sion of the pro­pos­als along with some per­sonal comments.

This arti­cle is very tech­ni­cal. No com­plete­ness or cor­rect­ness of the infor­ma­tion pre­sented below, and all views are personal.

Concepts

There are sev­eral con­cep­tual approaches for “color fonts” that can be con­sid­ered, in increas­ing order of complexity:

• a] per-​​PPM bitmap strike def­i­n­i­tion, with­out any scaling
• b] scal­able bitmap glyphs with mul­ti­ple “mas­ter PPM sizes”
• c] one scal­able bitmap glyph def­i­n­i­tion across all PPMs
• d] lay­ered out­line glyphs, one solid fill per layer
• e] sta­tic out­line glyphs with com­plex fills and optional bitmap content
• f] ani­mated vari­ant of e]

Approaches

We have now four dis­tinct approaches from the major ven­dors, in increas­ing 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] con­cept, pos­si­bly expand­able to f]

Considerations

There are also sev­eral con­sid­er­a­tions, or aspects, which each imple­men­ta­tion needs to address.

• Co-​​existence: regard­less of the pos­si­ble size infla­tion, whether sev­eral approach can co-​​exist within the same SFNT font file. This includes ques­tions such as prece­dence (what should hap­pen if a con­sum­ing plat­form “under­stands” mul­ti­ple approaches) or struc­ture shar­ing (whether the same struc­ture, e.g. the PNG image data or a color palette, can be shared by mul­ti­ple approaches). In par­tic­u­lar, the ques­tion of co-​​existence of the new struc­tures with old ones (glyf or CFF  table) is important.
• Exter­nal mod­i­fi­ca­tion: espe­cially with the out­line approaches, whether the col­ors spec­i­fied within the SFNT font file can some­how be manipulated/​modified exter­nally by the con­sum­ing plat­forms. This also includes more spe­cific ques­tions such as, in case of the SVG-​​based approaches, con­trol­ling ani­ma­tion or, if the con­sum­ing plat­form is a web browser, inter­ac­tion with the document’s DOM.
• Fallback/​degradation: related to co-​​existence, how the color data should be rep­re­sented in envi­ron­ments that only sup­port grayscale or even mono­chrome data. Adobe’s Leonard Rosen­thol has raised a num­ber of fun­da­men­tal issues on this in con­text of the SVG dis­cus­sion. The dis­cus­sion makes, I hope, an inter­est­ing read: the “Glyph bbox con­cerns” 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 def­i­n­i­tion, with­out any scal­ing, or as scal­able bitmap glyphs with mul­ti­ple “mas­ter PPM sizes” — this is unclear (see below for details).

Announced in May 2013 on the Google blog [GOO1], this is an approach which spec­i­fies two tables (CBDT/​CBLC, [GOO2]), which in turn extend the exist­ing OpenType EBDT/​EBLC tables [GOO3], [GOO4] by adding the abil­ity to include uncom­pressed color images or PNG images. Those, in turn, are extended ver­sion of Apple’s orig­i­nal bdat/​bloc tables which have a long history.

Google hosts a “Color Emoji” project ded­i­cated to this [GOO5], have cre­ated a Python tool which embeds PNGs into that table [GOO6] and have pro­vided sam­ple fonts. FreeType 2.5 now also includes sup­port for this [GOO7], added on May 29^th.

APP: Apple sbix table

In the cur­rent imple­men­ta­tion: bitmap-​​based (PNG) glyphs, as scal­able bitmap glyphs with mul­ti­ple “mas­ter strikes” per PPM. The sbix spec has pro­vi­sions to hold other types of glyph def­i­n­i­tions, such as TIFF, SVG, PDF or even movie clips, but this is not very clearly spec­i­fied nor implemented.

Apple’s is the first imple­men­ta­tion that has been offi­cially deployed. It was intro­duced to iOS 4 and also runs in Core­Text appli­ca­tions Mac OS X 10.7 and newer. It does not run on ATSUI appli­ca­tions such as Pages 09 or Keynote 09, but does work in Core­Text appli­ca­tions such as TextE­dit or Safari. Sup­port for sbix table with PNG glyph has also been added to FreeType.

The spec of the table has not been offi­cially pub­lished by Apple, but has been shared with inter­ested devel­op­ers. The imple­men­ta­tion hosts PNG data inside the sbix table, with mul­ti­ple PPM “mas­ter bitmaps” pos­si­ble per glyph. The scaler is respon­si­ble for choos­ing the most appro­pri­ate PPM size and scale it to other PPM sizes as needed.

It seems that per “mas­ter strike”, both the PPM and DPI infor­ma­tion can be pro­vided. For the met­rics, the imple­men­ta­tion relies on the bound­ing boxes stored in the glyf table. It seems that, very unfor­tu­nately, the Apple imple­men­ta­tion ren­ders the con­tents of a glyf table glyph, and the on top it ren­ders its asso­ci­ated bitmap — so if bitmaps are avail­able in the sbix table for a par­tic­u­lar glyph ID, the cor­re­spond­ing 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 for­mer along with Apple Color Emoji@2 (the lat­ter host­ing the glyphs in dou­ble DPI res­o­lu­tion, it appears).

A reverse-​​engineered incom­plete and faulty spec has been pub­lished [APP1] and [APP2], and a patch for fontTools/​TTX has been pub­lished [APP3]. Those do not seem to work cor­rectly, though. How­ever, Fontlab Ltd. has imple­mented its own sbix read­ing and writ­ing, which seems to work cor­rectly. Fontlab Ltd. also has its own sbix ren­derer, and I have suc­cess­fully built Latin-​​script color fonts with the sbix table and OpenType Lay­out fea­tures 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 mem­ber in the fam­ily of solu­tions, announced by Microsoft’s Michelle Per­ham and Si Daniels on June 26^th [MIC1], the Microsoft pro­posal looks quite sim­ple and clever to me, judg­ing from the announce­ment. It adds a rel­a­tively light­weight bag­gage of COLR and CPAL tables which results in lay­ered out­line glyphs with one solid fill per layer.

The MIC approach is imple­mented in Win­dows 8.1, with a new Segoe UI Emoji font being included in the OS. A video from Microsoft’s Dan McLach­lan talk where he presents the approach is avail­able [MIC2] (about 9 min­utes into the talk). Also, Michelle Per­ham made a pre­sen­ta­tion at Type­Con 2013 ded­i­cated to the topic.

The approach uses a base glyph (glyf or, pre­sum­ably, also CFF ) which is used for non-​​color sit­u­a­tions. The COLR table refers from this glyph into other out­line glyphs (which exist within the same table), which serve as lay­ers. Each “layer glyph” has its own z-​​order and a sin­gle color ref­er­ences. The color ref­er­ences are han­dled has palette indices, with a sep­a­rate table, CPAL in OpenType that resolves the RGBA col­ors actu­ally used for the glyph. There­fore, both the COLR and the CPAL tables should be quite small in size, all the heavy-​​lifting being done by the tra­di­tional ren­der­ing meth­ods. It was announced that Microsoft plans to pub­lish 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 pos­si­ble animation.

This is a pro­posal for­mu­lated by Mozilla’s Edwin Flo­res and Cameron McCor­mack, with input from Robert O’Callahan and Adobe’s Sairus Patel, which has been sub­mit­ted as an unof­fi­cial editor’s draft a Final Com­mu­nity Group Spec­i­fi­ca­tion to the W3C [SVG1]. There is a rea­son­ably well-​​working SVG OpenType com­mu­nity for this [SVG3] and a pub­lic mail­ing list [SVG2]. As indi­cated on Robert O’Callahan’s blog [SVG4], this pro­posal has been imple­mented in Fire­fox — it’s off by default but can be enabled by tog­gling gfx.font_rendering.opentype_svg.enabled in about:config. Also, a tool, writ­ten in Python, is avail­able to cre­ate such fonts [SVG5].

This is the by-​​far most com­plex pro­posal, as it puts the bar quite high for imple­menters (it requires a full SVG ren­derer, and has pro­vi­sions for ani­mated glyphs). On the other hand, its great advan­tage is that, once an app has access to the SVG ren­derer, it can del­e­gate the ren­der­ing of the glyphs com­pletely to the SVG library. So the app only needs to call an OpenType Lay­out library to per­form the lay­out, and then call the SVG ren­derer for each glyph, and posi­tion the ren­dered bitmaps. So in fact in an SVG-​​compatible envi­ron­ment using the SVG table would be trivial.

The SVG pro­posal allows for designs that can­not be achieved by the other solu­tions: it imple­ments “rich color” (with gra­di­ents etc.), allows for draw­ing var­i­ous strokes and, of course, inter­mix­ing vec­tors and bitmaps. So it’s poten­tially very very powerful.

Sairus Patel explained to me at Type­Con that he con­sid­ers the cur­rent pro­posed spec as “good to go”, and that’s the spec that is imple­mented in Firefox.

Personal conclusion

In my view, each of the pre­sented approaches has its advan­tages and disadvantages.

The Pro­pos­als

The APP pro­posal is great in so far that it’s actu­ally already imple­mented. How­ever, the inter­ac­tion of the sbix and glyf tables as imple­mented in Apple OSes has its seri­ous draw­backs (no fall­back sce­nario). Also, it’s unknown whether the sbix table would ever make its way into the offi­cial ISO OFF or OpenType specs.

The MIC pro­posal only “goes color” in a lim­ited scope — it pro­vides a way to ren­der mul­ti­layer glyphs with solid fills. But they’re out­line glyphs, so they should scale nicely.

The GOO and APP pro­pos­als use PNG as their vehi­cle, so they can have com­plex fills but would fail in high-​​resolution sce­nar­ios. FreeType already imple­ments the APP pro­posal with PNG glyph def­i­n­i­tions, and the GOO pro­posal — so it looks like adding sup­port for them was quite easy.

The GOO approach has advan­tages in so far that it ties into an exist­ing infra­struc­ture of tables, but my fear is that these exist­ing table con­cepts may be abused (no ref­er­ence to how scal­ing should hap­pen). Also, GOO’s insis­tence over non-​​presence of the glyf table is very lim­it­ing, and not under­stand­able: they say they want their exten­sions to go into the offi­cial EBDT/​EBLC tables, but those tables make no such requirement.

In prin­ci­ple, the MIC and GOO approaches could be eas­ily “mar­ried together”: the MIC pro­posal would be use­ful for mul­ti­layer glyphs with solid fills, the GOO approach for glyphs which require more refined bitmap treat­ment, and fall­back sce­nar­ios could be defined rather well.

The SVG approach is very wel­come, and, as I said, a kind of “2.0” thing. I believe the dis­cus­sion on them should con­tinue, even if imple­men­ta­tions of those could be con­fined to only the web browser con­text. Also, Fire­fox actu­ally already imple­ments the SVG approach, which is very good news.

Color Palettes

As for color palettes, I con­sider its addi­tion to font for­mats (whether through a uni­fied and fur­ther devel­oped CPAL table or through sev­eral sep­a­rate mech­a­nisms) as third ele­ment of typo­graphic user con­trol.

His­tor­i­cally, the first user con­trol mech­a­nism was just the cmap table: the user’s con­trol over a font was lim­ited to just enter­ing a string of Uni­codes, and pick­ing the font size — and the rest would be done by the font.

The sec­ond mech­a­nism was the addi­tion of the GSUB/​GPOS tables: user’s con­trol was extended by the abil­ity to spec­ify OpenType Lay­out fea­tures that should be applied to the text.

And now, we’re extend­ing the user’s con­trol by adding abil­ity to spec­ify mul­ti­ple col­ors through the font’s color palette.

Rela­tion to Exist­ing Solutions

When com­par­ing the out­line color font for­mat pro­pos­als, I would use the fol­low­ing analogy:

• First per­sonal com­put­ers had black-​​and-​​white mon­i­tors so they only could dis­play one color. That’s like the cur­rent mono­chrome font formats.
• Then, com­put­ers could dis­play 16 col­ors at the time, and later even 256 col­ors. The GIF graph­ics for­mat dom­i­nated the early days of the web, and it sup­ported up to 256 col­ors. So that was the “flat color” imple­men­ta­tion, and that’s exactly what the MIC pro­posal is.
• Finally, com­put­ers gained the pos­si­bil­ity to dis­play over 16 mil­lion col­ors, and graphic for­mats such as JPG and PNG were devel­oped to sup­port this. That allowed for “rich color” appli­ca­tions, and this is anal­o­gous to the SVG proposal.

Before color fonts, OpenType had three sep­a­rate pos­si­ble glyph sources:

• embed­ded bitmaps, which could be mono­chrome or grayscale, in the bdat/​bloc/​EBDT/​EBLC/​EBSC tables
• TrueType out­lines in the glyf table, which was a very straight­for­ward struc­ture that allowed lit­tle design flex­i­bil­ity but through its sophis­ti­cated hint­ing mech­a­nism gave the designer a lot of con­trol over the rasterizer
• Post­Script out­lines in the CFF  table, which did not give that pre­cise con­trol over the ras­ter­izer through hint­ing, but was a rel­a­tively com­plex struc­ture that came “super­charged” with some fea­tures that were not fully explored to date: frac­tional point coor­di­nates, the Font­Ma­trix mech­a­nism which allowed on-​​the-​​fly skew­ing, scal­ing or rota­tion, and even Mul­ti­ple Mas­ter, which was dropped from the spec.

All three solu­tions “co-​​existed peace­fully” in the mono­chrome font world.

The GOO pro­posal plugs directly into the embed­ded bitmaps mech­a­nism, but extends it with color.

The MIC pro­posal extends the glyf table and pro­vides a sim­ple solu­tion for “flat col­ors”, but is quite lim­ited beyond that. Yet it allows pre­cise hinting.

The SVG pro­posal is a cousin of the CFF  table: it’s tech­ni­cally the most com­plex, and requires a very smart, “active” ras­ter­izer. It does not offer hint­ing but allows more com­plex design solu­tions than the other proposals.

I hope that a sim­i­lar “peace­ful co-​​existence” can emerge for the color pro­pos­als that had existed for the mono­chrome solu­tions. Each of them has its mer­its and none of them is suf­fi­cient by its own.

Finite­ness

There is one more con­sid­er­a­tion that I should men­tion: “finite­ness” of the pro­pos­als. By that I mean whether the lim­i­ta­tions of what a given for­mats aims to achieve in the end is now clearly defined. This is closely related to sta­bil­ity of imple­men­ta­tions, mean­ing: if, as a devel­oper, I invest the time to imple­ment a given for­mat now, will I have to revisit it in the future?

Super­fi­cially, an “exten­si­ble” struc­ture is appeal­ing. “Oh, this struc­ture is infi­nitely exten­si­ble, we can add so many cool stuff to it later”. But in many cases, an infi­nitely exten­si­ble struc­ture also poses risks. Soft­ware devel­op­ers have lim­ited time win­dows to devote to fonts and text tech­nol­ogy. They often want to imple­ment some­thing and be done with it for the next years. So some­what para­dox­i­cally, a pro­posal that clearly and con­sciously states its lim­its is actu­ally attrac­tive because it doesn’t leave open questions.

The GOO pro­posal seems to be the best exam­ple of such self-​​limiting for­mat. It extends the exist­ing embed­ded bitmap for­mats by adding just two or so new sub­for­mats, and that’s it. There may be one or two open ques­tions now (the scal­a­bil­ity issue I dis­cussed), but once those are answered, and devel­op­ers add sup­port for it, it’s a done deal. The GOO pro­posal does not leave many loose ends.

In other words, the GOO pro­posal doesn’t try to cook many dishes at the same time or doesn’t try to be a “catch all solu­tion”. 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 embed­ded bitmap for­mats — it can be used to host bitmap-​​only glyph data, with­out any out­line fall­back. This actu­ally is quite desir­able for some sce­nar­ios such as fixed-​​size devices — sim­ple elec­tronic dis­plays (brick phones, scrolling elec­tronic ban­ners, diplays in car radios or other portable electronics).

In con­strast, the APP pro­posal lim­its itself very vaguely. The sbix table spec says that it can host a huge vari­ety of pos­si­ble glyph for­mats, from PNG through TIFF and JPEG, SVG and PDF to even movie clips. Attrac­tive in prin­ci­ple, it also may be a bit “scary”. The cur­rent APP imple­men­ta­tion isn’t actu­ally 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 imple­ment “sbix as a whole” may end up strug­gling to sup­port var­i­ous glyph data sources, and they may never be sure whether some­thing new wouldn’t pop up in future.

The MIC pro­posal quite cleanly defines its cur­rent scope, though Greg Hitch­cock has sug­gested dur­ing the Type­Con meet­ing that Microsoft may in future extend their for­mat to sup­port “more things”, like gra­di­ents. How­ever, know­ing Microsoft’s prac­tice, they would most likely extend it in a trans­par­ent, backwards-​​compatible way (so, for exam­ple, a gra­di­ent would fall back to a solid color). At the cur­rent stage of the pro­posal, CPAL and COLR are nicely defined. CPAL may undergo some revi­sions, espe­cially if (hope­fully) both the COLR and the SVG  tables make use it, i.e. if Adobe, Microsoft and Mozilla come to com­mon terms regard­ing some minor CPAL extensions.

Inter­est­ingly, the SVG in SFNT pro­posal, although very ambi­tious in terms of graphic effects you can achieve, is actu­ally fairly clearly lim­ited. Again, some wrin­kles need to be ironed out, and ani­ma­tion is a big open ques­tion, but if we limit our­selves to sta­tic SVGs, the prin­ci­ple is very sim­ple: the SVG in SFNT for­mat only defines a con­tainer for­mat for the data, and clearly del­e­gates every­thing else to the SVG stan­dard proper.

This is actu­ally a fairly sta­ble pro­posal. It means that, as a devel­oper who imple­ments it, you’ll need to keep up with the evo­lu­tion of SVG proper, but — if you do have an SVG ren­derer imple­men­ta­tion — you’ll want to do it any­way. 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 imple­mented the SFNT SVG  table once (hope­fully 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 gen­eral SVG ren­derer as you nor­mally would.

So with SVG, if your appli­ca­tion does not have an SVG ren­derer, it’s a “big step” that you’d need to do, but you’d only need to do it once. (And per­haps it would be a good idea to do it any­way, since SVG is a graph­ics for­mat that may be use­ful is sup­port­ing regard­less 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 mech­a­nism would serve as an ideal fall­back to SVG. Since SVG can con­tain scal­able graph­ics which inter­mix vec­tors and bitmaps, the results can be very com­plex. But they could be pre-​​rendered and put into the CBDT/​CBLC tables as well. It could be sim­i­lar to how pre-​​rendered PNG bitmaps are (or used to be) often served by web­sites to older browsers which don’t sup­port SVG. You’d lose the smooth scal­a­bil­ity, but you would at least get the intended glyphs appearance.

Support by FontLab apps

Fontlab Ltd. will soon be releas­ing a free app for Mac and Win­dows called FontLab Pad which will allow users on both OSes to use fonts that imple­ment any of the above pro­pos­als (cur­rently the APP and MIC for­mats are imple­mented but more sup­port is being added as we speak). Also, FontLab’s TransType 4 allows sim­ple cre­ation of MIC-​​compatible fonts through over­lay­ing exist­ing “lay­ered fonts” and assign­ing each layer a color. TransType can also out­put APP-​​compatible fonts with the same con­tents. In com­bi­na­tion with FontLab’s BitFonter 3, TransType 4 can be used to pro­duce sophis­ti­cated full-​​bitmap color fonts in the APP-​​compatible format.

At FontLab, we are very happy with this devel­op­ment and sup­port it fully. Our upcom­ing font edi­tors will sup­port mul­ti­color fonts natively, with lay­ers and poten­tially also com­plex fills, so fonts in all color for­mats (includ­ing SVG) can be created.

Tags: ADD, BASE, BitFonter, CBDT, CBLC, CDAT, CFF, chromatic fonts, color fonts, COLR, CPAL, DIN, EBDT, EST, FIRST, FL, font editor, font technology, Fontlab Ltd, FontLab Pad, Fonttools, GPOS, GSUB, hinting, IE, Indic, metrics, multicolor, Multiple Master, new, news, NOTE, OK, OpenType, OpenType Layout features, outlines, Photofont, PostScript, PS, Python, rendering, RIT, Rome, sbix, SECOND, SFNT, SID, SING, SVG, TransType, TrueType, TTX, US, video, WA, website, WIN, Windows

Trackback from your site.

Adam Twardoch

Adam Twardoch serves as Product and Marketing Manager at Fontlab Ltd. He also works as the glyph wrangler at MyFonts, and for other clients worldwide, specializing in font technology, multilingual typography, CSS webfonts, Unicode and OpenType. He regularly teaches workshops in font creation and is member of the Board of Association Typographique Internationale (ATypI). Originally from Poland, he lives and works in Berlin.