Intent to Ship: Variable COLRv1

[Dominik Röttsches]

Contact emails

dr...@chromium.org

Explainer

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

Specification

https://docs.microsoft.com/en-us/typography/opentype/otspec191alpha/colr

Summary

COLRv1 color vector fonts have been previously released in Chrome 98 https://developer.chrome.com/blog/colrv1-fonts/ but this release supported only static functionality of the COLRv1 table. (Previous I2S).

The COLRv1 specification defined integration with OpenType Variations from the beginning. This allows modifying the color elements of a font, parameters of gradients and transforms by means of changing font variable axis parameters. This I2S here is for bringing implementation support and adding variations to COLRv1 in Blink (see demo video, or demo links below)

Blink component

Blink>Fonts

Search tags

colrv1, variations, variable fonts, color, emoji, gradients

TAG review

The COLRv1 specification is developed outside of W3C, slated for inclusion in OpenType and ISO/MPEG Open Font Format. Before the previous I2S, I started a 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 (thread).

TAG review status

Not applicable

Risks

Interoperability and Compatibility

I see an interoperability risk mainly by not shipping variable COLRv1 support. Here's why:

Firefox is already in the process of shipping COLRv1 support (#1740530), and their initial release will immediately include COLRv1 variations support.

In the past few weeks, I've worked closely with Jonathan Kew from the Mozilla side to ensure interoperability of the resulting variable COLRv1 glyph renderings. To that end, I developed an extensive variable COLRv1 test font, for which we have compared results. https://github.com/googlefonts/color-fonts/blob/main/fonts/test_glyphs-glyf_colr_1_variable.ttf Additional interoperability efforts are underways: I would like to get to a point where we can have at least pixel comparisons of text stack rendering results for COLRv1. This is below the level of testing that WPT covers and likely needs separate infrastructure. For now, rendering results based on the test font have been manually compared.

Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1740530) The standards position was already "worth implementing" and no a fast-paced effort to deliver COLRv1 including variations support to users is driven by Jonathan Kew. The high quality implementation can already be tested in FF Nightly.

WebKit: Neutral (https://groups.google.com/a/chromium.org/g/blink-dev/c/kDfj3rcA6sc/m/77Ary8NVBwAJ) See discussion in previous COLRv1 intent-to-ship. Since then, I would estimate their stance towards COLRv1 has changed from negative to "observing".

Web developers: Positive Google Fonts, Underware.nl and other type foundry partners are anticipating this feature.

Other signals:

Activation

Similar to the initial release of COLRv1, the issue of feature detection remains. See separate I2S for tech() in src: line of @font-face. This, plus @supports(font-tech()) are intended to solve that.

Security

In addition to the initial COLRv1 release, which already had fuzzing for the FreeType parts, a fuzzer that fuzzes the Skia level code has been introduced and a few smaller issues that this fuzzer found have been addressed.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No. 

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

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

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

No

It is covered extensively by Skia gold regression tests, the variable COLRv1 test font has been developed and been used for ensuring consistent rendering results between FF's and our implementation.

Flag name

chrome://flags/#variable-colrv1

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1311241

Sample links

(Remember to activate chrome://flags/#variable-colrv1)

• Video of variable COLRv1 test font rendering
  
• https://roettsch.es/var_colrv1.html based on variable COLRv1 test font
• Underware's Plakato Moire Demo: https://www.underware.nl/blog/2022/07/plakato-moire/

Estimated milestones

107

Anticipated spec changes

One spec issue (#367) is being discussed for handling an edge case in radial gradients and radii becoming negative under variations. Jonathan Kew and I have already found consensus on the implementation approach and I consider this issue mostly needing updated spec wording, but otherwise resolved.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6326528091095040

[Yoav Weiss]

Hey Dominik!

So once this ships, if developers would want to ship something that works on both latest Chrome and older Chrome versions, do they have a way to do that? Would they do that using `tech(colrv1 variations)` or somesuch? 

[Dominik Röttsches]

Hey Yoav,

On Wed, Sep 7, 2022 at 4:04 PM Yoav Weiss <yoav...@chromium.org> wrote:

Hey Dominik!

So once this ships, if developers would want to ship something that works on both latest Chrome and older Chrome versions, do they have a way to do that? Would they do that using `tech(colrv1 variations)` or somesuch? 

Unfortunately not, for two reasons: 1) tech(colrv1 variations) is not uniquely describing "variations in the COLRv1 table". It could also mean previously existing glyph shape variations (which can be combined with COLRv1), which worked before (without COLRv1 variable support).  

2) tech() is not shipped yet, and won't be shipped to older browsers, so this means of distinction wouldn't work in the older browsers.

What we can do to mitigate that: ship variable COLRv1 and @font-face src: tech() support in the same release. Then font blobs loaded under of tech(color-COLRv1) would imply variable COLRv1 support. FF aims to ship this feature as well in sync with variable COLRv1 support. So detecting it that way would always mean variable COLRv1.

Since the uptake of COLRv1 fonts is slow at this point (which I expect to change with web font providers and additional UAs supporting COLRv1), this may be a sufficient approach for now, but I'll let you gauge that.

Dominik

[Yoav Weiss]

OK, so sounds like there's urgency here, or at least we need to coordinate shipping.

LGTM1 to ship in the same release as `tech()`.

On Thu, Sep 8, 2022 at 3:21 PM Dominik Röttsches <dr...@chromium.org> wrote:

Hey Yoav,

On Wed, Sep 7, 2022 at 4:04 PM Yoav Weiss <yoav...@chromium.org> wrote:

Hey Dominik!

So once this ships, if developers would want to ship something that works on both latest Chrome and older Chrome versions, do they have a way to do that? Would they do that using `tech(colrv1 variations)` or somesuch? 

Unfortunately not, for two reasons: 1) tech(colrv1 variations) is not uniquely describing "variations in the COLRv1 table". It could also mean previously existing glyph shape variations (which can be combined with COLRv1), which worked before (without COLRv1 variable support).  

Does that mean that if we'd want to ship a future enhancement to colrv1, we'd need to give it its own tech() signifier? e.g. "colrv1-foobar"?

 

2) tech() is not shipped yet, and won't be shipped to older browsers, so this means of distinction wouldn't work in the older browsers.

Obviously..

[Dominik Röttsches]

Hi Yoav,

On Thursday, September 8, 2022 at 4:35:58 PM UTC+3 yoav...@chromium.org wrote:

OK, so sounds like there's urgency here, or at least we need to coordinate shipping.

LGTM1 to ship in the same release as `tech()`.

Thanks! 

 

Does that mean that if we'd want to ship a future enhancement to colrv1, we'd need to give it its own tech() signifier? e.g. "colrv1-foobar"?

Yes, either that or call an update to the format COLRv2 for example. We have some requests for functionality as additoins to COLRv1, such as mesh gradients,  blur filters (for shadows) and such, but none of that is spec'ed as of today.

[Mike Taylor]

LGTM2

[Manuel Rego Casasnovas]

LGTM3

On 09/09/2022 07:02, Mike Taylor wrote:
> LGTM2
>
> On Thursday, September 8, 2022 at 9:42:54 AM UTC-4 dr...@google.com wrote:
>
> Hi Yoav,
>
> On Thursday, September 8, 2022 at 4:35:58 PM UTC+3

> yoav...@chromium.org <mailto:yoav...@chromium.org> wrote:
>
> OK, so sounds like there's urgency here, or at least we need to
> coordinate shipping.
>
> LGTM1 to ship in the same release as `tech()`.
>
>
> Thanks!
>
> Does that mean that if we'd want to ship a future enhancement to
> colrv1, we'd need to give it its own tech() signifier? e.g.
> "colrv1-foobar"?
>
>
> Yes, either that or call an update to the format COLRv2 for example.
> We have some requests for functionality as additoins to COLRv1, such
> as mesh gradients,  blur filters (for shadows) and such, but none of
> that is spec'ed as of today.
>
> Dominik
>
>
>
> On Monday, September 5, 2022 at 4:36:01 PM UTC+2 Dominik
> Röttsches wrote:
>
>
> Contact emails
>
> dr...@chromium.org
>
>
>
> Explainer
>

> https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md#changes-to-off-5711---color-table <https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md#changes-to-off-5711---color-table>
>
>
> Specification
>
> https://docs.microsoft.com/en-us/typography/opentype/otspec191alpha/colr <https://docs.microsoft.com/en-us/typography/opentype/otspec191alpha/colr>

>
>
> Summary
>
> COLRv1 color vector fonts have been previously
> released in Chrome 98
> https://developer.chrome.com/blog/colrv1-fonts/
> <https://developer.chrome.com/blog/colrv1-fonts/>
> but this release supported only static functionality
> of the COLRv1 table. (Previous I2S

> <https://groups.google.com/a/chromium.org/g/blink-dev/c/kDfj3rcA6sc/m/77Ary8NVBwAJ>).

>
>
> The COLRv1 specification defined integration with
> OpenType Variations

> <https://medium.com/variable-fonts/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369#:~:text=An%20OpenType%20variable%20font%20is,font%20instances%20can%20be%20interpolated.> from the beginning. This allows modifying the color elements of a font, parameters of gradients and transforms by means of changing font variable axis parameters. This I2S here is for bringing implementation support and adding variations to COLRv1 in Blink (see demo video <https://www.youtube.com/watch?v=H-ulJ04cODE>, or demo links below)
>
>
> Blink component
>
> Blink>Fonts
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFonts>
>
>
> Search tags
>
> colrv1
> <https://chromestatus.com/features#tags:colrv1>,
> variations
> <https://chromestatus.com/features#tags:variations>,
> variable fonts
> <https://chromestatus.com/features#tags:variable%20fonts>, color <https://chromestatus.com/features#tags:color>, emoji <https://chromestatus.com/features#tags:emoji>, gradients <https://chromestatus.com/features#tags:gradients>

>
>
> TAG review
>
> The COLRv1 specification is developed outside of
> W3C, slated for inclusion in OpenType and ISO/MPEG
> Open Font Format. Before the previous I2S

> <https://groups.google.com/a/chromium.org/g/blink-dev/c/kDfj3rcA6sc/m/77Ary8NVBwAJ>, I started a 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 (thread <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/k7eMJh0kRDk/m/WKXoDhmHAAAJ>).

>
>
> TAG review status
>
> Not applicable
>
>
> Risks
>
>
>
> Interoperability and Compatibility
>
> I see an interoperability risk mainly by not
> shipping variable COLRv1 support. Here's why:
>
>
> Firefox is already in the process of shipping COLRv1
> support (#1740530)

> <https://bugzilla.mozilla.org/show_bug.cgi?id=1740530>, and their initial release will immediately include COLRv1 variations support.

>
>
> In the past few weeks, I've worked closely with
> Jonathan Kew from the Mozilla side to ensure
> interoperability of the resulting variable COLRv1
> glyph renderings. To that end, I developed an
> extensive variable COLRv1 test font, for which we
> have compared results.

> https://github.com/googlefonts/color-fonts/blob/main/fonts/test_glyphs-glyf_colr_1_variable.ttf <https://github.com/googlefonts/color-fonts/blob/main/fonts/test_glyphs-glyf_colr_1_variable.ttf> Additional interoperability efforts are underways: I would like to get to a point where we can have at least pixel comparisons of text stack rendering results for COLRv1. This is below the level of testing that WPT covers and likely needs separate infrastructure. For now, rendering results based on the test font have been manually compared.
>
>
> /Gecko/: In development
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1740530 <https://bugzilla.mozilla.org/show_bug.cgi?id=1740530>) The standards position was already "worth implementing" and no a fast-paced effort to deliver COLRv1 including variations support to users is driven by Jonathan Kew. The high quality implementation can already be tested in FF Nightly.
>
> /WebKit/: Neutral
> (https://groups.google.com/a/chromium.org/g/blink-dev/c/kDfj3rcA6sc/m/77Ary8NVBwAJ <https://groups.google.com/a/chromium.org/g/blink-dev/c/kDfj3rcA6sc/m/77Ary8NVBwAJ>) See discussion in previous COLRv1 intent-to-ship. Since then, I would estimate their stance towards COLRv1 has changed from negative to "observing".
>
> /Web developers/: Positive Google Fonts,

> Underware.nl and other type foundry partners are
> anticipating this feature.
>

> /Other signals/:

>
>
> Activation
>
> Similar to the initial release of COLRv1, the issue
> of feature detection remains. See separate I2S for
> tech() in src: line of @font-face. This, plus
> @supports(font-tech()) are intended to solve that.
>
>
>
> Security
>
> In addition to the initial COLRv1 release, which
> already had fuzzing for the FreeType parts, a fuzzer
> that fuzzes the Skia level code has been introduced

> <https://bugs.chromium.org/p/skia/issues/detail?id=13675> and a few smaller issues that this fuzzer found have been addressed.

>
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of
> existing APIs, such that it has potentially high
> risk for Android WebView-based applications?
>
> No.
>
>
>
> 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/
> <https://github.com/fonttools/fonttools/> and
> https://github.com/BlackFoundryCom/black-renderer
> <https://github.com/BlackFoundryCom/black-renderer>
>
>
> Will this feature be supported on all six
> Blink platforms (Windows, Mac, Linux, Chrome
> OS, Android, and Android WebView)?
>
> Yes
>
>
> Is this feature fully tested by
> web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

>
> No
>
> It is covered extensively by Skia gold regression
> tests, the variable COLRv1 test font has been
> developed and been used for ensuring consistent
> rendering results between FF's and our implementation.
>
>
> Flag name
>
> chrome://flags/#variable-colrv1
>
>
> Requires code in //chrome?
>
> False
>
>
> Tracking bug
>

> https://crbug.com/1311241 <https://crbug.com/1311241>

>
>
> Sample links
>
> (Remember to activate chrome://flags/#variable-colrv1)
>

> * Video of variable COLRv1 test font rendering
> <https://www.youtube.com/watch?v=H-ulJ04cODE>
> * https://roettsch.es/var_colrv1.html

> <https://roettsch.es/var_colrv1.html> based on
> variable COLRv1 test font

> * Underware's Plakato Moire Demo:
> https://www.underware.nl/blog/2022/07/plakato-moire/ <https://www.underware.nl/blog/2022/07/plakato-moire/>

>
>
> Estimated milestones
>
> 107
>
>
>
> Anticipated spec changes
>
> One spec issue (#367)

> <https://github.com/googlefonts/colr-gradients-spec/issues/367> is being discussed for handling an edge case in radial gradients and radii becoming negative under variations. Jonathan Kew and I have already found consensus on the implementation approach and I consider this issue mostly needing updated spec wording, but otherwise resolved.

>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/6326528091095040

> <https://chromestatus.com/feature/6326528091095040>
>
> --
> 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
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c0e5a5a2-11b3-4cd3-bea9-55f3f6704357n%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c0e5a5a2-11b3-4cd3-bea9-55f3f6704357n%40chromium.org?utm_medium=email&utm_source=footer>.