Contact [email protected]

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
<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 componentBlink>Fonts
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFonts>

Search tagscolrv1 <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 reviewThe 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 statusNot 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
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 <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/ 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
<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 namechrome://flags/#variable-colrv1

Requires code in //chrome?False

Tracking bughttps://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 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)
<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

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBu58jto_-vificb2CbPLWeXY%3DM7ZmDO63wV6t-RgjWFrg%40mail.gmail.com.

Reply via email to