Intent to Ship: COLRv1 Color Gradient Vector Fonts

[Dominik Röttsches]

Contact emails

dr...@chromium.org

rshe...@google.com

Explainer

https://github.com/googlefonts/colr-gradients-spec/
https://github.com/googlefonts/colr-gradients-spec/blob/master/OFF_AMD2_WD.md#changes-to-off-5711---color-table

Specification

https://github.com/googlefonts/colr-gradients-spec/blob/master/OFF_AMD2_WD.md

Design docs

https://github.com/googlefonts/colr-gradients-spec/blob/master/OFF_AMD2_WD.md

Section "5.7.11.3 COLR version 1 rendering algorithm"

Summary

To bring highly compact, expressive color vector fonts to the web, we designed a next generation font format enabling powerful 2D graphics glyph definitions (gradients, transforms, compositing), supports variations ("variable fonts"), and reuses existing contour definitions of the open font format OFF. Previous color font formats either a) embed fixed size bitmap files into the font containers. Those do not scale well and have a large binary size, or they b) embed OpenType SVG which is a format external to existing OpenType and open font format concepts.

COLRv1 resolves issues (compatibility with variations, file size, impl. complexity) arising from embedding an external vector format, and provides highly space efficient, expressive primitives for developing appealing and scalable glyphs on the web. (Example for Noto Color Emoji: 1.8MB in TrueType glyph form, woff2 compressed, vs. 9MB woff2 compressed in CBDT/CBLC bitmap form.)

Blink component

Blink>Fonts

TAG review

The COLRv1 specification is developed outside of W3C, slated for inclusion in OpenType and ISO/MPEG Open Font Format. I started a previous thread on blink-api-owners-discuss asking whether TAG review for such a font format would be needed. This discussion concluded that a TAG review is not required, reference to thread on blink API owners list.

Font standardization in the context of COLRv1 happens in two forums:

Microsoft's publication of the OpenType standard they maintain, and the international standardization in ISO and through the US national standardization body INCITS contributing to ISO.

OpenType: The COLRv1 integration in OpenType is currently in Alpha review since April 2021. 
https://docs.microsoft.com/en-us/typography/opentype/otspec190alpha/ot190alpha
After the alpha review, a short beta review period is expected, after which OpenType 1.9 is expected to be published. The time frame for that is roughly 1-2 months. We do not expect major changes to the COLRv1 parts in this review period.

ISO/INCITS: At ISO, COLRv1 is in the ballot stage, which comes prior to voting. No objections were reviewed during the ballot / review stage. In fact, the only ballot comments came from ourselves with minor corrections and updates to the spec, which will be incorporated into the final version.

From the beginning (~Feb 2020), besides these two formal standardization forums, we have developed the COLRv1 specification completely in the open on our GitHub repository and invited everyone in the font community to participate. We did receive feedback from various stakeholders, which we addressed and incorporated.

TAG review status

Not applicable, see above.

Risks

Interoperability and Compatibility

Feature adoption by other browsers has an influence on whether this format picks up traction. The COLRv1 format is designed to be implementable based on commonly available drawing primitives found in any 2D graphics library such as cairo, Skia, Direct2D, CoreGraphics, etc.

The current spec and prototyping work includes publishing tools for font vendors to produce COLRv1 fonts based off of a set of SVG images, see https://github.com/googlefonts/nanoemoji which provides a path to generate fonts from SVG source images. We are prototyping a version of Noto Color Emoji, Google's own emoji font to migrate to this format to save space and improve rendering quality. Our current testing has achieved rendering parity between Noto Color emoji bitmap and COLRv1 emoji using a QA mode of nanoemoji that performs pixel comparisons.

We believe that COLRv1 provides a tight and interoperable specification. During the course of spec development we have developed two implementations of COLRv1, one that produces such fonts (in nanoemoji), as well as the rasterization stack implemented in Skia and FreeType. A third, open-source implementation exists with the BlackRenderer, which proves the implementability of COLRv1 based on 3 different graphics library backends.

OT-SVG may serve as a fallback color vector font format in supported browsers. See more details on feature detection in the activation section.

Signals

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/497#issuecomment-936264318) Not blessed as official Mozilla position yet, but Mozilla's resident font expert Jonathan Kew speaks out positively and in detail: "…it seems to me that COLRv1 is a far more natural and integrated fit with the overall OpenType system…" and suggest "worth prototyping" to be adopted as Mozilla's official position.

WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2021-March/031765.html)

From the WebKit team, we received this negative response stating there's no real need for COLRv1 as OT-SVG exists, to which I responded extensively in this post. Please refer to this thread for further details. Some API owners are already familiar with this discussion. My response sheds more light on some assertions and assumptions made by WebKit folks and provides a competitive analysis between OT-SVG and COLRv1 in terms of implementation complexity, file size and performance.
Microsoft's Peter Constable responded as well on behalf of Microsoft and Edge positively.

Edge: Positive

As mentioned in the WebKit section, Peter Constable commented highly in favor of COLRv1 on the WebKit-dev thread. In fact, Peter Constable contributed and collaborated extensively with us during the development of COLRv1.

Web developers: Positive 

In https://github.com/mozilla/standards-positions/issues/497#issuecomment-799527254 yisibl@, who speaks as a representative of https://www.iconfont.cn/ part of Alibaba, considers COLRv1 a highly suitable format for icon fonts and is preparing their site to be ready for COLRv1.

The developers' interest in a color vector font format can also be deduced from the 151 stars on the feature request for OpenType SVG in issue 306078. We take the liberty to interpret this interest partially as a general need for a color vector font for the web, but choose to deliver on this request with the newly developed COLRv1 format.

We have also had internal discussions with other partners inside and outside of Google showing interest in the format. More details available internally.

Activation

Feature detection of COLRv1 can currently only be done based on a) user agent string and user agent version (client side and server side) , or b) based on doing probe renderings to canvas checking pixel values (client side). Approach A is no change from the current approach that for example Google Fonts and other third-party font providers take to decide which font format support is available. The decision on the client|s support is made on the server at the time of sending the HTTP request for the font stylesheet to the server.

At this point, the font service can gather from UA type and major version, what font technology support is available.

Efficient feature detection was identified as a gap for shipping COLRv1. The initial plan was to ship the extended @supports <font-technology> syntax for the src: @font-face descriptor. A TAG review before shipping this suggested to consider alternative syntax. This in turn led to a longer standardization discussion in https://github.com/w3c/csswg-drafts/issues/6520 which is ongoing. Given the continued standards discussion, the plan is to deliver improved feature detection for COLRv1 and other font technologies in upcoming releases, but decouple this effort from shipping COLRv1. UA based detection is deemed sufficient for the initial release of COLRv1.

Debuggability

Decoding errors of COLRv1 fonts show up as decode failure messages in the console, which is equivalent to the level of debugging of font format support for other font technologies. External tooling exists for creating, analyzing and testing COLRv1 fonts, such as https://github.com/fonttools/fonttools/ and https://github.com/BlackFoundryCom/black-renderer

Is this feature fully tested by web-platform-tests?

No, as it is tested at lower levels. A basic rendering test could be added to WPT, but the CSS fonts spec does not mandate support for this specific font format so no strict assertions on format support can be made across browsers.

Regression tests are continuously run on bots at the Skia golden master level, see colrv1.cpp gm test, based on a test font released in the color-fonts repository, which covers the drawing primitives in the COLRv1 format.

Additional manual testing was and is performed using the QA mode of nanoemoji, which compares the rendering of source SVG through the resvg library against the COLRv1 output.

Additionally, since the beginning we're running fuzz tests on the FreeType COLRv1 parsing implementation as part of FreeType's participation in oss-fuzz.

Flag name

colr-v1-fonts

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1170733

Measurement

UMA metric VariableFontsRatio covers percentage of font format instantiations, by means of which we can track adoption of this format.

Sample links

https://github.com/googlefonts/color-fonts

Estimated milestones

• Initial release of COLRv1 in Chrome M90 for public testing behind flag, compare https://github.com/googlefonts/colr-gradients-spec/#chromium-skia-freetype-support
• ToT, currently M98, ready to ship, regression tested and rendering parity with Noto Emoji bitmap version achieved.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5638148514119680

Acknowledgements

I would like to thank Behdad Esfahbod, Roderick Sheeter, Cosimo Lupo, Peter Constable, Ben Wagner, Chris Lilley, Jonathan Kew, Laurent Penney, Just van Rossum and others for their tremendous contributions and collaboration essential to the development of COLRv1.

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

LGTM1

Thanks for the thorough and meticulous work pushing this through.

Agree that this was already reviewed in the proper standardization bodies.

 

Risks

Interoperability and Compatibility

Feature adoption by other browsers has an influence on whether this format picks up traction. The COLRv1 format is designed to be implementable based on commonly available drawing primitives found in any 2D graphics library such as cairo, Skia, Direct2D, CoreGraphics, etc.

The current spec and prototyping work includes publishing tools for font vendors to produce COLRv1 fonts based off of a set of SVG images, see https://github.com/googlefonts/nanoemoji which provides a path to generate fonts from SVG source images. We are prototyping a version of Noto Color Emoji, Google's own emoji font to migrate to this format to save space and improve rendering quality. Our current testing has achieved rendering parity between Noto Color emoji bitmap and COLRv1 emoji using a QA mode of nanoemoji that performs pixel comparisons.

We believe that COLRv1 provides a tight and interoperable specification. During the course of spec development we have developed two implementations of COLRv1, one that produces such fonts (in nanoemoji), as well as the rasterization stack implemented in Skia and FreeType. A third, open-source implementation exists with the BlackRenderer, which proves the implementability of COLRv1 based on 3 different graphics library backends.

OT-SVG may serve as a fallback color vector font format in supported browsers. See more details on feature detection in the activation section.

Signals

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/497#issuecomment-936264318) Not blessed as official Mozilla position yet, but Mozilla's resident font expert Jonathan Kew speaks out positively and in detail: "…it seems to me that COLRv1 is a far more natural and integrated fit with the overall OpenType system…" and suggest "worth prototyping" to be adopted as Mozilla's official position.

WebKit: Negative (https://lists.webkit.org/pipermail/webkit-dev/2021-March/031765.html)

From the WebKit team, we received this negative response stating there's no real need for COLRv1 as OT-SVG exists, to which I responded extensively in this post. Please refer to this thread for further details. Some API owners are already familiar with this discussion. My response sheds more light on some assertions and assumptions made by WebKit folks and provides a competitive analysis between OT-SVG and COLRv1 in terms of implementation complexity, file size and performance.
Microsoft's Peter Constable responded as well on behalf of Microsoft and Edge positively.

I highly appreciate your measured and factful response on that thread as well as Peter's. Thanks for maintaining a high level of discourse.

Edge: Positive

As mentioned in the WebKit section, Peter Constable commented highly in favor of COLRv1 on the WebKit-dev thread. In fact, Peter Constable contributed and collaborated extensively with us during the development of COLRv1.

Web developers: Positive 

In https://github.com/mozilla/standards-positions/issues/497#issuecomment-799527254 yisibl@, who speaks as a representative of https://www.iconfont.cn/ part of Alibaba, considers COLRv1 a highly suitable format for icon fonts and is preparing their site to be ready for COLRv1.

The developers' interest in a color vector font format can also be deduced from the 151 stars on the feature request for OpenType SVG in issue 306078. We take the liberty to interpret this interest partially as a general need for a color vector font for the web, but choose to deliver on this request with the newly developed COLRv1 format.

We have also had internal discussions with other partners inside and outside of Google showing interest in the format. More details available internally.

Activation

Feature detection of COLRv1 can currently only be done based on a) user agent string and user agent version (client side and server side) , or b) based on doing probe renderings to canvas checking pixel values (client side). Approach A is no change from the current approach that for example Google Fonts and other third-party font providers take to decide which font format support is available. The decision on the client|s support is made on the server at the time of sending the HTTP request for the font stylesheet to the server.

At this point, the font service can gather from UA type and major version, what font technology support is available.

That's unfortunate. This is not a blocker, but I'd urge you to explore more direct server-side content-negotiation mechanisms.

One option would be to state font format support on the `Accept` headers for CSS requests - which is a bit weird, but would be better than inferring support from the UA string.

Another could be to consider Client Hints for this purpose.

Efficient feature detection was identified as a gap for shipping COLRv1. The initial plan was to ship the extended @supports <font-technology> syntax for the src: @font-face descriptor. A TAG review before shipping this suggested to consider alternative syntax. This in turn led to a longer standardization discussion in https://github.com/w3c/csswg-drafts/issues/6520 which is ongoing.

Thanks for addressing the TAG's feedback on this!

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBvsKD8wyBzMHrG14TJ99bT3saACG7-aKNbR9bJN8yHy2g%40mail.gmail.com.

[Manuel Rego Casasnovas]

Hi Dominik,

On 19/10/2021 09:31, Yoav Weiss wrote:
> *WebKit:* Negative
> (https://lists.webkit.org/pipermail/webkit-dev/2021-March/031765.html <https://lists.webkit.org/pipermail/webkit-dev/2021-March/031765.html>)

>
> From the WebKit team, we received this negative response stating
> there's no real need for COLRv1 as OT-SVG exists, to which I
> responded extensively in this post

> <https://lists.webkit.org/pipermail/webkit-dev/2021-May/031839.html>. Please

> refer to this thread for further details. Some API owners are
> already familiar with this discussion. My response sheds more light
> on some assertions and assumptions made by WebKit folks and provides
> a competitive analysis between OT-SVG and COLRv1 in terms of
> implementation complexity, file size and performance.
> Microsoft's Peter Constable responded as well

> <https://lists.webkit.org/pipermail/webkit-dev/2021-April/031789.html>

> on behalf of Microsoft and Edge positively.
>
>
> I highly appreciate your measured and factful response on that thread as
> well as Peter's. Thanks for maintaining a high level of discourse.

Yeah really nice reply there.

Did we manage to get any further feedback from Apple after that email?
Even if it was not directly on the webkit-dev mailing list but in some
private conversations, working group discussions or whatever.

Cheers,
Rego

[Dominik Röttsches]

Hi Rego,

Thanks for the feedback. 

On Tue, Oct 19, 2021 at 9:01 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:

Did we manage to get any further feedback from Apple after that email?
Even if it was not directly on the webkit-dev mailing list but in some
private conversations, working group discussions or whatever.

I am afraid there's not much I can share here. We did have meetings with Apple before and after our request for a standards position and the discussion that ensued on webkit-dev, but there are no fundamentally new or different outcomes after those.

Dominik

[Manuel Rego Casasnovas]

LGTM2

Ok, thanks for the clarifications. It's sad we didn't manage to engage
WebKit.

Cheers,
Rego

[Peter Constable]

@Dominik: Thanks for the detailed write-up, and for driving the process to ship support for COLR v1 in chromium. Naturally, as collaborator on the COLR v1 spec, and the one getting it added to OpenType (for version 1.9, to be released soon), I  can say that Microsoft is in general supportive of this extension to the OpenType format, and am fully in support of seeing this supported in Chromium.

Color fonts have been around for almost a decade, but have not really taken off. I suspect a contributing factor for that is that there hasn't been one format that is widely supported in applications. 

I also suspect there hasn't been excitement around the bitmap formats ('sbix' or 'CBDT' tables) because bitmaps aren't scalable and lead to large font files. (That's especially the case when alternate bitmaps of different sizes are added to compensate for the lack of scalability.) The bitmap formats also don't integrate at all with variations, which is a downside against them.

Clearly a colour vector format is to be preferred. OT-SVG is already available as a vector format. But for reasons I mentioned in the webkit-dev list (cited above), I don't think we should expect it to be adopted widely in environments that don't already have XML and CSS parsers. OT-SVG and COLR v1 will require similar 2D graphics support, and both require ttf parsing, but OT-SVG also requires XML/CSS parsing, which is certainly more complex than parsing the structures added for COLR v1.

COLR v1 also has the significant advantage of being much better integrated into other aspects of the OpenType format, notably variations.

For all these reasons, I believe the enhanced COLR table has the best prospects among the various OpenType colour formats of being the one that eventually gains wide adoption and allows colour fonts to gain significant interest beyond platform-specific emoji fonts.

@Rego:

> Did we manage to get any further feedback from Apple after that email?

I haven't heard much further from Apple, but I don't expect them to give away too much. The only public comments I've seen have been in the context of webkit, which may or may not reflect the perspective of other product groups. Even with v1, the COLR table doesn't yet provide the level of graphic capability needed to duplicate the carefully, pixel-by-pixel crafted designs in their emoji font, so I assume they don't have an immediate motivation to utilize COLR v1 in their products (unlike Google, Microsoft and perhaps other vendors who can benefit from COLR v1 with their emoji designs). So, I'm guessing they're taking a wait-and-see approach, but that's just a guess.

[Daniel Libby]

+1, thanks for driving this Dominik. Edge is looking forward to COLRv1 shipping to provide a compact format that enables a wider set of features that icon and emoji fonts can take advantage of. 

[一丝]

> Chinese version of this email: https://www.yuque.com/docs/share/ba9f5d45-b1d3-49d6-9a69-d4cb5841de7f

Thanks to Dominik's hard work behind the scenes, COLRv1 has gone from an idea to a technology that everyone can use.

Since Adobe released PostScript in 1984, font technology has undergone a huge transformation. Looking back on the history, there have been many detours due to commercial competition. Today, we are at a crossroads again, and I believe COLRv1 will leave a strong mark on the history of fonts.

I am the head of development at www.iconfont.cn, iconfont fully endorses the COLRv1 font format and fully agrees with Chromium's views here.

Please allow me to briefly introduce:

iconfont is the vector (SVG) material management platform of Alibaba Group, we have millions of massive icons. With iconfont, designers and developers can easily collaborate. When designers draw icons, they only need to export SVG and upload it to iconfont to generate code and various fonts easily.

Generating colorful fonts with gradients has been the biggest request from our users. We have also considered the SVG in OT format, but there are several significant problems.

1. generating large font files
2. variable fonts are not supported
3. Not supported in MiniApp: https://www.w3.org/TR/mini-app-white-paper/

Test page(64 emojis): https://at.alicdn.com/t/iconfont/project/900373.html

In the end, we chose the COLRv0 format, which does not support gradients. As of 2021-10-21, here are some data of iconfont.cn.

• Total number of icons: 16800000+
• Total number of color icon collections: 4559
• Total number of projects: 2670000+
• Total number of color fonts (COLRv0) projects: 4535

There are already 4535 projects with COLRv0 enabled, but nowhere near the total number of projects 2670000+, I believe a big reason is that they are waiting for font icons with gradients. So, as soon as Chrome ships COLRv1, iconfont can implement it quickly so that all users can easily generate COLRv1 fonts.

At Alibaba, many apps are using font icons and I'm pushing to switch the emoji in Dingtalk App from png to vector color fonts, which will be a brand new experience.

Let's drink to that 🍻 and wait for the good news of the release.

Acknowledgements

Heartfelt thanks to Dominik Röttsches, Behdad Esfahbod, Roderick Sheeter, Cosimo Lupo and others for their help and support.

• English users can visit: https://www.iconfont.cn/?lang=en-us
• More iconfont color font introduction: https://www.yuque.com/yisi/iconfont/colr-font

一丝(Percy Ley)

[Alex Russell]

LGTM3.

Thanks everyone for providing compelling evidence that this is solving an important need well.

[Dominik Röttsches]

COLRv1 is now live in the Chrome 98 Beta. For those interested, we also wrote a blog post:

https://developer.chrome.com/blog/colrv1-fonts/

Dominik