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? 

On Monday, September 5, 2022 at 4:36:01 PM UTC+2 Dominik Röttsches wrote:

> 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/336a6b71-303d-4077-a29d-253ac368e20bn%40chromium.org.

Reply via email to