*LGTM1* Thanks for the thorough and meticulous work pushing this through.
On Mon, Oct 18, 2021 at 5:41 PM Dominik Röttsches <[email protected]> wrote: > Contact [email protected] > [email protected] > > Explainerhttps://github.com/googlefonts/colr-gradients-spec/ > > https://github.com/googlefonts/colr-gradients-spec/blob/master/OFF_AMD2_WD.md#changes-to-off-5711---color-table > > Specification > https://github.com/googlefonts/colr-gradients-spec/blob/master/OFF_AMD2_WD.md > > Design docs > > https://github.com/googlefonts/colr-gradients-spec/blob/master/OFF_AMD2_WD.md > <https://github.com/googlefonts/colr-gradients-spec/blob/master/OFF_AMD2_WD.md#changes-to-off-5711---color-table> > Section "5.7.11.3 COLR version 1 rendering algorithm" > > Summary > > To bring highly compact, expressive color vector fonts to the web, we > designed a next generation font format enabling powerful 2D graphics glyph > definitions (gradients, transforms, compositing), supports variations > ("variable fonts"), and reuses existing contour definitions of the open > font format OFF. Previous color font formats either a) embed fixed size > bitmap files into the font containers. Those do not scale well and have a > large binary size, or they b) embed OpenType SVG which is a format external > to existing OpenType and open font format concepts. > > > COLRv1 resolves issues (compatibility with variations, file size, impl. > complexity) arising from embedding an external vector format, and provides > highly space efficient, expressive primitives for developing appealing and > scalable glyphs on the web. (Example for Noto Color Emoji: 1.8MB in > TrueType glyph form, woff2 compressed, vs. 9MB woff2 compressed in > CBDT/CBLC bitmap form.) > > Blink componentBlink>Fonts > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFonts> > > TAG reviewThe COLRv1 specification is developed outside of W3C, slated > for inclusion in OpenType and ISO/MPEG Open Font Format. I started a > previous 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, reference to thread on blink API owners list > <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/k7eMJh0kRDk/m/WKXoDhmHAAAJ> > . > > Font standardization in the context of COLRv1 happens in two forums: > > Microsoft's publication of the OpenType standard they maintain, and the > international standardization in ISO and through the US national > standardization body INCITS contributing to ISO. > > *OpenType:* The COLRv1 integration in OpenType is currently in Alpha > review since April 2021. > > https://docs.microsoft.com/en-us/typography/opentype/otspec190alpha/ot190alpha > After the alpha review, a short beta review period is expected, after > which OpenType 1.9 is expected to be published. The time frame for that is > roughly 1-2 months. We do not expect major changes to the COLRv1 parts in > this review period. > > *ISO/INCITS:* At ISO, COLRv1 is in the ballot stage, which comes prior to > voting. No objections were reviewed during the ballot / review stage. In > fact, the only ballot comments came from ourselves with minor corrections > and updates to the spec, which will be incorporated into the final version. > > From the beginning (~Feb 2020), besides these two formal standardization > forums, we have developed the COLRv1 specification completely in the open on > our GitHub repository > <https://github.com/googlefonts/colr-gradients-spec/> and invited > everyone in the font community to participate. We did receive feedback from > various stakeholders, which we addressed and incorporated. > > TAG review statusNot applicable, see above. > Agree that this was already reviewed in the proper standardization bodies. > > > Risks > > Interoperability and Compatibility > > Feature adoption by other browsers has an influence on whether this format > picks up traction. The COLRv1 format is designed to be implementable based > on commonly available drawing primitives found in any 2D graphics library > such as cairo, Skia, Direct2D, CoreGraphics, etc. > > The current spec and prototyping work includes publishing tools for font > vendors to produce COLRv1 fonts based off of a set of SVG images, see > https://github.com/googlefonts/nanoemoji which provides a path to > generate fonts from SVG source images. We are prototyping a version of Noto > Color Emoji, Google's own emoji font to migrate to this format to save > space and improve rendering quality. Our current testing has achieved > rendering parity between Noto Color emoji bitmap and COLRv1 emoji using a > QA mode of nanoemoji that performs pixel comparisons. > > > We believe that COLRv1 provides a tight and interoperable specification. > During the course of spec development we have developed two implementations > of COLRv1, one that produces such fonts (in nanoemoji), as well as the > rasterization stack implemented in Skia and FreeType. A third, open-source > implementation exists with the BlackRenderer > <https://github.com/BlackFoundryCom/black-renderer>, which proves the > implementability of COLRv1 based on 3 different graphics library backends > <https://github.com/BlackFoundryCom/black-renderer/tree/master/Lib/blackrenderer/backends> > . > > > OT-SVG may serve as a fallback color vector font format in supported > browsers. See more details on feature detection in the activation section. > > *Signals* > > *Gecko:* Positive ( > https://github.com/mozilla/standards-positions/issues/497#issuecomment-936264318) > Not blessed as official Mozilla position yet, but Mozilla's resident font > expert Jonathan Kew speaks out positively and in detail: "…it seems to me > that COLRv1 is a far more natural and integrated fit with the overall > OpenType system…" and suggest "worth prototyping" to be adopted as > Mozilla's official position. > > *WebKit:* Negative ( > https://lists.webkit.org/pipermail/webkit-dev/2021-March/031765.html) > > From the WebKit team, we received this negative response stating there's > no real need for COLRv1 as OT-SVG exists, to which I responded > extensively in this post > <https://lists.webkit.org/pipermail/webkit-dev/2021-May/031839.html>. > Please refer to this thread for further details. Some API owners are > already familiar with this discussion. My response sheds more light on some > assertions and assumptions made by WebKit folks and provides a competitive > analysis between OT-SVG and COLRv1 in terms of implementation complexity, > file size and performance. > Microsoft's Peter Constable responded as well > <https://lists.webkit.org/pipermail/webkit-dev/2021-April/031789.html> on > behalf of Microsoft and Edge positively. > I highly appreciate your measured and factful response on that thread as well as Peter's. Thanks for maintaining a high level of discourse. > *Edge:* Positive > As mentioned in the WebKit section, Peter Constable commented > <https://lists.webkit.org/pipermail/webkit-dev/2021-April/031789.html> highly > in favor of COLRv1 on the WebKit-dev thread. In fact, Peter Constable > contributed and collaborated extensively with us during the development of > COLRv1. > > *Web developers:* Positive > > In > https://github.com/mozilla/standards-positions/issues/497#issuecomment-799527254 > yisibl@, who speaks as a representative of https://www.iconfont.cn/ part > of Alibaba, considers COLRv1 a highly suitable format for icon fonts and is > preparing their site to be ready for COLRv1. > > The developers' interest in a color vector font format can also be deduced > from the 151 stars on the feature request for OpenType SVG in issue 306078 > <https://bugs.chromium.org/p/chromium/issues/detail?id=306078>. We take > the liberty to interpret this interest partially as a general need for a > color vector font for the web, but choose to deliver on this request with > the newly developed COLRv1 format. > > We have also had internal discussions with other partners inside and > outside of Google showing interest in the format. More details available > internally. > > Activation > > Feature detection of COLRv1 can currently only be done based on a) user > agent string and user agent version (client side and server side) , or b) > based on doing probe renderings to canvas checking pixel values (client > side). Approach A is no change from the current approach that for example > Google Fonts and other third-party font providers take to decide which font > format support is available. The decision on the client|s support is made > on the server at the time of sending the HTTP request for the font > stylesheet to the server. > > > At this point, the font service can gather from UA type and major version, > what font technology support is available. > That's unfortunate. This is not a blocker, but I'd urge you to explore more direct server-side content-negotiation mechanisms. One option would be to state font format support on the `Accept` headers for CSS requests - which is a bit weird, but would be better than inferring support from the UA string. Another could be to consider Client Hints for this purpose. Efficient feature detection was identified as a gap for shipping COLRv1. > The initial plan was to ship the extended @supports <font-technology> > syntax for the src: @font-face descriptor. A TAG review before shipping > this suggested to consider alternative syntax. This in turn led to a > longer standardization discussion in > https://github.com/w3c/csswg-drafts/issues/6520 which is ongoing. > Thanks for addressing the TAG's feedback on this! > Given the continued standards discussion, the plan is to deliver improved > feature detection for COLRv1 and other font technologies in upcoming > releases, but decouple this effort from shipping COLRv1. UA based detection > is deemed sufficient for the initial release of COLRv1. > > > 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 > > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ?No, as it is tested at lower levels. A basic rendering test could be > added to WPT, but the CSS fonts spec does not mandate support for this > specific font format so no strict assertions on format support can be made > across browsers. > > Regression tests are continuously run on bots at the Skia golden master > level, see colrv1.cpp gm test > <https://source.chromium.org/chromium/chromium/src/+/main:third_party/skia/gm/colrv1.cpp>, > based on a test font released in the color-fonts repository > <https://github.com/googlefonts/color-fonts/blob/main/fonts/more_samples-glyf_colr_1.ttf>, > which covers the drawing primitives in the COLRv1 format. > > Additional manual testing was and is performed using the QA mode of > nanoemoji, which compares the rendering of source SVG through the resvg > library against the COLRv1 output. > > Additionally, since the beginning we're running fuzz tests on the FreeType > COLRv1 parsing implementation as part of FreeType's participation in > oss-fuzz > <https://github.com/freetype/freetype2-testing/blob/master/fuzzing/src/visitors/facevisitor-colrv1.cpp> > . > > Flag namecolr-v1-fonts > <https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/about_flags.cc;l=2826?q=colr-v1-fonts> > > Requires code in //chrome?False > > Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1170733 > > *Measurement* > UMA metric VariableFontsRatio covers percentage of font format > instantiations, by means of which we can track adoption of this format. > > Sample links > https://github.com/googlefonts/color-fonts > > Estimated milestones > > > - Initial release of COLRv1 in Chrome M90 for public testing behind > flag, compare > > https://github.com/googlefonts/colr-gradients-spec/#chromium-skia-freetype-support > - ToT, currently M98, ready to ship, regression tested and rendering > parity with Noto Emoji bitmap version achieved. > > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5638148514119680 > > *Acknowledgements* > I would like to thank Behdad Esfahbod, Roderick Sheeter, Cosimo Lupo, > Peter Constable, Ben Wagner, Chris Lilley, Jonathan Kew, Laurent Penney, > Just van Rossum and others for their tremendous contributions and > collaboration essential to the development of COLRv1. > > This intent message was generated by Chrome Platform Status > <https://www.chromestatus.com/>. > > -- > 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/CAN6muBvsKD8wyBzMHrG14TJ99bT3saACG7-aKNbR9bJN8yHy2g%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBvsKD8wyBzMHrG14TJ99bT3saACG7-aKNbR9bJN8yHy2g%40mail.gmail.com?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/CAL5BFfXFcbd_Fb6bBgAoWkq7uU%2BS5ySCNA%3DHssDY5VNkEJ0syw%40mail.gmail.com.
