LGTM2 On Thursday, September 8, 2022 at 9:42:54 AM UTC-4 [email protected] wrote:
> Hi Yoav, > > On Thursday, September 8, 2022 at 4:35:58 PM UTC+3 [email protected] > 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 [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/c0e5a5a2-11b3-4cd3-bea9-55f3f6704357n%40chromium.org.
