Contact emailsdr...@chromium.org rshee...@google.com 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. 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. *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. 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. 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBvsKD8wyBzMHrG14TJ99bT3saACG7-aKNbR9bJN8yHy2g%40mail.gmail.com.
