The type community needs to have these discussions and these conferences are of course apt venues, but for the ATypI meeting I'm sad to see that the conversation coincides with the two-track part of the conference. Thus attending the meeting means missing nine (!) other presentations (full disclosure: mine is one of the nine). Is that the best or only time-slot option?

TypeCon offered a couple of options and this one seemed best. ATypI only offered the one slot.

This may be a dumb question (my specialty), but are any other platforms besides Windows 8.1 discussing supporting color fonts?

Mac OS X (starting with Lion) and iOS support OpenType fonts with embedded color bitmaps. These are embedded in a private table named "sbix".

About a month before we demo'd our color support, Google announced an alternate embedded bitmap format on the OpenType list. I don't recall if the proposal mentioned Android or Chrome OS.

Cheers, Si

Si who's doing the talk? I ain't going I don't have a sponsor. Alice Rawsthorn is a legend.. her Yves St. Laurent book is ace but mostly about the financing of fashion.

Vinny, it's not a talk, it's a meeting. Sorry to hear you won't be there. I'll check to see if we have a spare sponsor pass.

send me an email then Si.

send me an email then Si.

Another platform with nascent support for color fonts (in the form of SVG-in-OpenType) is Gecko, although the feature is not yet enabled by default in Firefox desktop and mobile browsers — it's considered experimental and has some known bugs. There's a small example (complete with bugs!) here.

As part of the Gecko platform, this support should become available in due course throughout Gecko-based applications and on Firefox OS devices.

there will likely be a call in number for this meeting too.

Video feed? Skype?

Sure we can set something up. Contact me off-list.

Cheers, Si

For those here in Portland, the meeting will take place in the Council meeting room on the 3rd floor of the Hilton hotel.

The meeting was interesting, if thoroughly inconclusive. There are no fewer than four color font formats right now (Apple, Microsoft, Google, Adobe), although one of them (Apple's) has not yet been submitted for consideration as a standard.

As I understand, none of them have been formally submitted for consideration as a standard. The ISO MPEG-OFF body is drafting a request for proposals, and formal submissions will be in response to that.

I believe you are correct; I should have said, three of them are published specs with the announced intention of submitting them for standardization, while Apple has not decided one way or the other to publish/submit, or not.

So who's going to make a pros/cons table for each approach?

hhp

At the moment, and unless things change drastically, I'd say there's a pretty good chance that we could end up with multiple solutions, each with its particular benefits and coverage areas.* On the whole, most attention seems to be on the two vector formats: Microsoft's glyf/COLR/CPAL model and the SVG-in-OT model from the W3C community group championed by Adobe and Mozilla. As Adam pointed out, though, Google's bitmap model is worth considering because, like the MS vector model, it is a small and nifty addition to existing sfnt structures.

If anyone is going to compile a table of pros and cons for each model, I'd recommend distinguishing pros/cons for different parties. Obviously the SVG model has more pros for companies that have already invested in SVG support, and have most of the infrastructure they would need in place. Obviously the glyf/COLR/CPAL model has specific pros for rendering environments that still make use of hinting.

And if things do change drastically? I think the biggest question is whether MS will expand their model to handle gradients and animation. If they do, then their approach will be in direct competition with the SVG model, and there would be less reason for the ISO MPEG committee to contemplate standardising both.
_____

* At the meeting, I posited a use case in which a font developer might end up including both COLR/CPAL data and SVG data in the same font, for different ranges of characters.

No problem. Tracking glyphs that change color or unicode as a function of time or size will also have to be stored in the font name. ;)

>So who's going to make a pros/cons table for each approach?

Adam Twardoch actually wrote one up a month or so ago. You could ask him to forward, or possibly post here.

Si

INTRODUCTION

As a follow-up to the TypeCon “color fonts” meeting that took place in Portland on August 24th, 2013, I’m posting this analysis which I have written and circulated to a group of developers and type designers in June. The following is a revised version of my analysis as of August 30th. I’m incorporating some of the updated information which was made available after I wrote the initial version. Note that this overview is my personal take on the topic. I claim no completeness or correctness of the information presented below.

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/Archives/Public/public-svgopentype/2012Jun/thread.html
[2] http://lists.w3.org/Archives/Public/public-svgopentype/2012Aug/thread.html

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 29th.

Co-existence: The GOO proposal states: “It is recommended that such fonts include no ‘glyf’ table, and as such be bitmap-only fonts. In the presence of color and non-color strikes in the same font, it is currently unspecified which bitmap a conformant client will choose for rendering.”. While this does not directly invalidate co-existence, it raises a valid question (for co-existence in general, and for precedence in particular). However, in Microsoft’s and Apple’s traditional implementations of the TrueType rasterizer (before ClearType), the bdat/bloc and EBDT/EBLC tables worked so that if a bitmap strike was available for a given PPM, it was used, otherwise the outline glyph was rendered from the “glyf” table (even for the same glyph but different PPM). I definitely think that all consuming platforms which support the GOO approach should adopt the aforementioned principle. This is especially crucial when it comes to co-existence between the GOO proposal and the MIC proposal. If the GOO approach behaves as I described, then chances are that one font could include the CBDT, CBLC, COLR, CPAL and glyf tables, and the consuming platform could easily choose whether to use the GOO approach first, and then (for different PPM sizes or glyphs which are not supported by the GOO tables) use the MIC approach (or just the plain “glyf” table).

External modification: While some people have generally voiced their desire to be able to manipulate colors that are embedded inside of a font file externally, I think in case of PNG-based glyphs, this should be, if at all, a post-processing step (after the glyph images have been retrieved from the scaler).

Fallback/degradation: the GOO spec includes provisions as to how the color bitmap data should be transformed into grayscale bitmap data.

Unclear: The OpenType spec also includes the “EBSC” table [GOO8] which defines which per-PPM strikes should be used for which PPM ranges when they need to be scaled. Without “EBSC”, it is assumed that the “EBDT”/“EBLC” strikes are only rendered for the specified PPM. The GOO proposal makes no mention of how scaling should be implemented, or whether a scaler should rely on the presence of the EBSC table. I *strongly* think that, should the GOO proposal aim at wider adoption, it should strictly follow the principle laid out in the OpenType spec: if no EBSC table is present, strikes should be rendered only at given PPMs. For scaling, it should refer to the EBSC table. It’s also unclear to me what FreeType 2.5 is doing at this point, and whether support for EBSC is planned.

[GOO1] http://google-opensource.blogspot.de/2013/05/open-standard-color-font-fun-for.html
[GOO2] https://color-emoji.googlecode.com/git/specification/v1.html
[GOO3] http://www.microsoft.com/typography/otspec/ebdt.htm
[GOO4] http://www.microsoft.com/typography/otspec/eblc.htm
[GOO5] https://code.google.com/p/color-emoji/
[GOO6] https://code.google.com/p/color-emoji/source/browse/
[GOO7] http://git.savannah.gnu.org/cgit/freetype/freetype2.git/
[GOO8] https://www.microsoft.com/typography/otspec/ebsc.htm

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 a Latin-script color font 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!).

Co-existence: The fact that the “sbix” implementation in Apple OSes seems to require that the “glyf” glyphs are blank raises a big co-existence concern.

In particular, it seems that this approach could not co-exist with the MIC approach, which is a pity. I see that as a weakness of the APP approach.

As for the co-existence of the APP and GOO approaches, it seems somewhat unclear to me. The APP approach requires both “sbix” and “glyf” to be present, while currently, the GOO approach discourages the presence of “glyf”. I see it as a weakness of both approaches (more strongly of the GOO approach). Also, there is the question of data duplication. Theoretically, I imagine that a smart mechanism (akin to TTC) could allow for some data sharing, wherein both the “sbix” table and the “CBLC” table referred to the same PNG chunks. But I’m not sure if offsets that go beyond defined table boundaries are permitted in the OT spec (I don’t think they are).

External modification: While some people have generally voiced their desire to be able to manipulate colors that are embedded inside of a font file externally, I think in case of PNG-based glyphs, this should be, if at all, a post-processing step (after the glyph images have been retrieved from the scaler).

Fallback/degradation: the APP implementation does not have any clear provisions for fallback/degradation. A renderer could fall back to grayscale or monochrome (dithered) versions of the “sbix” PNG glyphs, but it would be desirable if it could also fall back to “proper” “glyf” outline glyphs. However, the fact that the APP implementation relies on *empty* “glyf” glyphs invalidates that.

Unclear: It’s not currently clear how the PPM+DPI “master strikes” should be chosen and scaled, but my assumption is that the APP approach explicitly assumes that the “sbix” glyphs are scalable, without the need for an additional “EBSC” table. This may be disputable. Also, it’s not entirely clear to me how a renderer should make use of the PPM and DPI information, though by itself it seems rather straightforward.

[APP1] http://typophile.com/node/96671#comment-524375
[APP2] http://kanji-database.sourceforge.net/fonts/opentype.html
[APP3] https://gist.github.com/jjgod/5478229

MIC: Microsoft “COLR”/“CPAL” tables

The newest member in the family of solutions, announced by Microsoft’s Michelle Perham and Si Daniels on June 26th [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.

Co-existence: If the GOO approach clarifies its behavior when the “glyf” table is present, then the MIC approach could co-exist easily with the GOO approach. Actually, these two approaches could cleverly echo the former co-existence of “glyf” with “bdat/bloc” (or “EBDT”/“EBLC”/“EBSC”). A consuming platform could go straight for the monochrome “glyf” glyphs, or could prioritize the MIC approach with a fallback to “glyf”, or could prioritize the GOO approach with a fallback to “glyf”, or could prioritize the GOO approach, then fall back to the MIC approach, and then finally fall back to “glyf”. I don’t see any principal conflict there.

External modification: As Michelle wrote on the OpenType list, “Fonts can have multiple palettes, but right now the colors are defined by the font developer and the user is not able to make changes to the palettes. That’s definitely something we’d like to consider in the future and might be something that applications could expose.” At TypeCon, Greg Hitchcock clarified the envisioned roles of the palettes: first palette is used by default for “dark on light” color situations while second palette is intended for use in “light on dark” situations. Additional palettes should be selectable by the user.

Fallback/degradation: This approach seems to be degrading nicely, and fallback implications have been discussed above.

[MIC1] http://typophile.com/node/104174
[MIC2] http://channel9.msdn.com/Events/Build/2013/3-191

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 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.

This approach really is an entirely different animal than all of the above. I can easily imagine that the APP, GOO and MIC approaches are all some kind of “color fonts 1.0”, while the SVG proposal is “color fonts 2.0”. There’s is an ongoing debate on the public mailing list of the W3C community, so I won’t get into a detailed discussion here (also because I don’t quite understand some of the complexities involved).

I definitely think, though, that this approach can co-exist with all the previous ones.

One potential co-existence benefit could be if the “SVG ” table co-exists with the MIC “CPAL” table. The SVG glyphs could potentially make references to the color palettes specified within “CPAL”, and if — in future — some means to externally manipulate the “CPAL” palettes were implemented in consuming platforms, both the MIC approach and the SVG approach could benefit from that development.

In the light of the MIC proposal, Sairus Patel mentioned to me that he might consider proposing some extensions to the Microsoft “CPAL” table, and then would consider dropping the color palette format proposed in the SVG spec — so that ultimately both the MIC and the SVG formats could use the “CPAL” table.

[SVG1] http://dev.w3.org/SVG/modules/fonts/SVG-OpenType.html
[SVG2] http://www.w3.org/community/svgopentype/
[SVG3] http://lists.w3.org/Archives/Public/public-svgopentype/
[SVG4] http://robert.ocallahan.org/2013/02/svg-in-opentype-new-approach-to-svg.html
[SVG5] https://github.com/edf825/SVG-OpenType-Utils

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.

Support by FontLab apps

As a tiny bit of self-promotion, I shall add that 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.

Best regards,
Adam Twardoch

Thank you, Adam.

hhp

A small [edit: not so small after all :) ] postscriptum:

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.

Best,
Adam