Hi Dominik! Thanks for the request. We (Apple’s WebKit team and Core Text team) have feedback about some technical details of the spec, but I’ll omit that here, since this is not the right place for it. We’ll open issues on the GitHub repository you linked to with these detailed items of feedback. At a high level, here is a list of things we like about the proposal: Chrome aims to ship support for advanced vector-based color fonts Inversely, here is a list of things we don’t like about the proposal: It re-invents the wheel. This new format is as expressive and powerful as any general-purpose 2D graphics serialization format. There are many, many existing serialization formats for general-purpose 2D graphics. It doesn’t exist yet (outside of a development configuration of Chrome). OT-SVG, which is just as expressive*, exists and has shipping implementations in DirectWrite, Core Text, Firefox, and many (most? all?) of Adobe creation apps. Many OT-SVG fonts already exist. Because this proposal doesn’t exist yet outside of Chrome, there is no ecosystem in existing authoring tools. Conversely, many design authoring tools already export SVG. Supporting both OT-SVG and this new proposal is twice (-ish) the maintenance burden, for a format that isn’t any more expressive* than the format we support already. Supporting both OT-SVG and this new proposal increases our binary size. We expect the additional binary size increase to be roughly equivalent to the binary size increase we observed after implementing OT-SVG. (OT-SVG does involve an XML parser, but WebKit already links with an XML parser, so we expect the size of this new proposal to be roughly equal to the size increase we saw after implementing OT-SVG. This proposal would require its own novel parsing / overflow detecting / interpretation code.) Supporting both OT-SVG and this new proposal roughly doubles the surface area for security attacks for vector-based color fonts. Even considering an engine that only supports this proposal and not SVG, we haven’t seen any evidence that avoiding XML will reduce security bugs compared to a novel binary format. Historically, in WebKit, we’ve observed that opaque binary formats (like image formats) have plenty of their own security bugs. The spec has over 2,500 lines, and the images/ directory of the spec has 77 figures, and there is only a single implementation of this proposal. It’s complicated enough that we’re not confident that it can be implemented interoperably. We’re worried the behavior of the drawing operations may be specific to Skia, and difficult/impossible to implement on Core Graphics. For example, at first glance, we are not sure that the radial gradients in this proposal can be implemented on Core Graphics. As far as we’re aware, this proposal has not undergone a rigorous standardization process from many independent stakeholders. Embedding raster image data inside color font tables is common today, but this new proposal has no affordances for allowing it, despite its vector facilities being as expressive as any general-purpose 2d graphics serialization format. Therefore, it doesn’t actually improve upon the color font table fragmentation situation, which is widely regarded as one of the biggest drawbacks to color fonts today. Given these two lists, Apple’s WebKit team and Core Text team are negative on this proposal. Thanks, Myles * Except for font variations, which A) can be added to OT-SVG easily, and B) probably aren't a particularly compelling feature in conjunction with color font technology, at least now.
On Mar 23, 2021, at 4:23 AM, Dominik Röttsches <drott@chromium.org> wrote:
Hi,
This is a request for WebKit's position on COLR v1 vector color fonts.
Spec:
https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md <https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md> Proposed changes to ISO/IEC 14496-22 (Amendment 2)
Chromium Bug: https://crbug.com/1170733 <https://crbug.com/1170733>
Summary:
COLR v1 fonts are a new vector color font format that provides gradients, transforms and compositions for font glyph drawing enabling an expressive, very compact glyph definition format for OFF/OpenType fonts. This format provides size and rendering fidelity (scaling) advantages over bitmap fonts such as SBIX, CBDT/CBLC fonts for glyph designs that lend themselves well to being encoded as vector art.
Thank you in advance for your position statement on this topic,
Dominik