Open Standard Color Font Fun for Everyone
- specification for enhancements to the OpenType standard
- source changes to the FreeType rendering engine and the Skia 2D graphics library
- a tool to embed color glyphs into fonts
- three sample color fonts
Note: What appears to be color fonts in this blog post have been simulated. There is not yet a way to show these in text form until this technology makes its way into the products that you use. The work we have released is the first step in this process. We are working to get all of the other pieces in place.By Behdad Esfahbod and Stuart Gill, Font and Text Team, Google Internationalization Engineering
6 comments:
-
It's irritating to see the term "open standard" applied to something that Google has worked on in secret until announcing it today, ignoring ongoing work in public groups on related technology --- http://lists.w3.org/Archives/Public/public-svgopentype/.
It's also irritating to read "the use of color glyphs has been limited to systems doing special text processing and inserting images into the text or by using closed proprietary font formats.", when SVG Opentype glyphs are experimentally supported in Firefox already (i.e., at least as well supported as this spec).
There may be good reasons why colored bitmap glyphs are useful instead of or as well as SVG glyphs, but I can't see anything in this announcement or elsewhere that explains them. -
Some of us have been using coloured Postscript Type3 fonts since last century, and vector fonts at that.
Stuffing coloured bitmaps into an OTF wrapper does nothing for typography – how are these glyphs supposed to be reproduced in print or on higher resolution devices? How is the colour to be colour managed?
Having said that, there’s no reason why this couldn’t be supported in addition to the existing SVG proposal: http://dev.w3.org/SVG/modules/fonts/SVG-OpenType.html -
Would you kindly show us the difference between your specs and "sbix" of Apple?
-
We don’t think SVG-in-OpenType and a color bitmap format in OpenType have much overlap. Moreover, supporting SVG in OpenType is orders of magnitude more work than supporting color bitmaps, particularly in contexts outside browsers. Color bitmaps on the other hand, are implemented centrally in FreeType. Indeed, if we run Firefox against the modified cairo, we get color bitmaps showing up just fine. These are just two different approaches to the same problem, and we don’t see any problem with pursuing both.
As for “working on it in secret”, there’s always a point in time that you release something, no matter how early you push it out someone will call that you did it in “secret” before releasing. If you check the spec, the actual specing part is a day’s work and clearly marked as a proposal for OpenType group to consider. Behdad has demoed the implementation to a number of interested parties, including Jonathan Kew in fact, as soon as we had it running. YMMV.
-
Text rendering in computers is very different from print. Even in computers, people have been using images to represent emoji since last century. Supporting color glyphs in actual fonts has accessibility and universality benefits (think copy/paste, screen readers, interoperability), as well as changing to different images simply by changing fonts. It’s hard to extend those benefits to print.
-
Last we checked there was no publicly available spec for Apple “sbix” table. We believe that conceptually they are similar though we think that based on what has been reverse engineered about their format that ours offers some advantages.



