COLRv1 Color Gradient Vector Fonts

[drott]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: COLR v1 Fonts
• Specification or proposal URL: https://github.com/googlefonts/colr-gradients-spec/ - to be merged into OpenType
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @jfkthame

Other information

@jfkthame previously contributed to the specification and reviewed the proposal. It'd be great to have a short summary of their feedback on this issue for public visibility.

[yisibl]

The current COLRv0 is very mature, and I strongly support the COLRv1 specification, which is very suitable for color font icons.

[drott]

@jfkthame and others, friendly ping on this request. For reference, see also Microsoft's position statement by Peter Constable on webkit-dev (positive for Edge and other MS teams) as well as additional data we posted on webkit-dev containing comparisons between OT-SVG and COLRv1 for font file size, implementation complexity and binary overhead as well as rendering performance .

[annevk]

Apple's feedback is also worth highlighting here: https://lists.webkit.org/pipermail/webkit-dev/2021-March/031765.html.

[jfkthame]

Apple's feedback is also worth highlighting here: https://lists.webkit.org/pipermail/webkit-dev/2021-March/031765.html.

Yes, it's worth specifically noting that. And perhaps should also explicitly mention that the messages linked by Dominik above are responses to that Apple feedback.

[jfkthame]

My personal point of view at the moment:

While an argument can certainly be made that we already have OT-SVG, which provides rich color font capabilities, and therefore there is little need the new COLRv1 format, I don't think that is a good long-term point of view here.

At the time we (along with Adobe and others) designed and implemented OT-SVG, there didn't appear to be much appetite for substantial enhancements to the rendering capabilities in the core OT spec. So OT-SVG essentially bypassed that, by taking an entirely separate graphics system and wrapping it inside each glyph. This allowed us to leverage the graphic expressiveness of SVG "by reference" without a major extension of the OpenType spec itself, just a "hook" to call out to SVG.

However, OT-SVG has always been something of an oddity -- an independent graphics format and imaging model "plugged in" to individual glyphs, with no relation to the rest of the OpenType standard. The only reason it seemed reasonable to implement such a thing, I think, is that we already had an SVG renderer in the browser, and so could "simply" hook this into the glyph-painting code. But as a general approach to adding color to the OpenType font format, it would be much harder to justify, pulling in an entire XML parser and SVG document model rather than "just" adding color capabilities to the existing glyphs.

(I also suspect that while there are now multiple implementations of OT-SVG rendering, there are almost certainly some interop issues arising from differences between exactly what they support.)

More recently (dating from the Variations work, perhaps) there seems to be wider interest in extending the features of what could be regarded as the "native" OpenType spec, as opposed to hooking up a separate graphics system inside each glyph. While there's a great deal of overlap between what OT-SVG and COLRv1 offer designers in terms of graphical richness, it seems to me that COLRv1 is a far more natural and integrated fit with the overall OpenType system. It uses the same glyph outline descriptions, instead of a separate language for paths and shapes. This means that existing aspects of OpenType glyphs such as hinting and variations will interoperate seamlessly with COLRv1.

Supporting COLRv1 will involve parsing some new binary table formats, which as always will come with a risk of bugs and exploits. I anticipate we'd want to add support for the new tables to the OTS sanitizer library as a protection against malicious (or corrupt) font resources, so that the actual rendering code only handles spec-conformant data. (The rendering code should also aim to be safe, of course; but OTS can add a layer of defence-in-depth.)

I suspect that in the longer term, COLRv1 may (should?) eclipse OT-SVG as the preferred format for "rich" color fonts. Given the low level of OT-SVG usage on the web, we may want to consider dropping support for it altogether once COLRv1 is widely supported, and conversion tools are available. So long-term, we wouldn't be maintaining support for two color font technologies with largely-equivalent capabilities; we'd be replacing the rather Heath Robinson-ish (or Rube Goldberg-ish, for those across the Atlantic) OT-SVG technology mashup with the more integrated COLRv1 approach.

In summary, then, I think we should consider this as "worth prototyping".

Also pinging @tantek for any additional standards-related thoughts here.

[drott]

Thank you very much, Jonathan, for publishing your very positive view on COLRv1 and the detailed reasoning and background. We're extremely happy to read this!

(The rendering code should also aim to be safe, of course; but OTS can add a layer of defence-in-depth.)

Yes! As an additional data point: With security in mind from the beginning, we're actively running fuzzing on the current COLRv1 FreeType parsing code as part of https://github.com/google/oss-fuzz.

[drott]

For people following along on this issue, this commit means COLRv1 is now part of Mozilla's official position dashboard here:
https://mozilla.github.io/standards-positions/#font-colrv1
Also, @jfkthame filed a tracking bug for exploring support for COLRv1.

Thank you, @annevk and @jfkthame!