LGTM3

On 09/09/2022 07:02, Mike Taylor wrote:
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] <mailto:[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 emails

                    [email protected]



                            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 [email protected] <mailto:[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 <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c0e5a5a2-11b3-4cd3-bea9-55f3f6704357n%40chromium.org?utm_medium=email&utm_source=footer>.

--
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/4008b2d1-2e31-b5bf-9afd-b9818edcdb25%40igalia.com.

Reply via email to