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 <[email protected]> wrote: > Hey Yoav, > > On Wed, Sep 7, 2022 at 4:04 PM Yoav Weiss <[email protected]> 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.. > > 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 > > > 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/CAL5BFfUveu8GKfHTjnsWe0jCOaeK%3D%3Dxj6HKiUg0_UR-FYoBqnA%40mail.gmail.com.
