<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Hi Dominik!</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Thanks for the request.</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">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.</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">At a high level, <span class="">here is a list of things we like about the proposal:</span></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><ol class="MailOutline"><li class="">Chrome aims to ship support for advanced vector-based color fonts</li></ol></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Inversely, here is a list of things we don’t like about the proposal:</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><ol class="MailOutline"><li class="">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 <span class="">general-purpose 2D graphics.</span></li><li class=""><font color="#000000" class="">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? a<span class="">ll?) of Adobe creation apps. Many OT-SVG fonts already exist.</span></font></li><li class=""><font color="#000000" class="">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.</font></li><li class=""><font color="#000000" class="">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.</font></li><li class=""><font color="#000000" class="">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 <i class="">increase</i> we saw after implementing OT-SVG. This proposal would require its own novel parsing / overflow detecting / interpretation code.)</font></li><li class=""><font color="#000000" class="">Supporting both OT-SVG and this new proposal roughly doubles the surface area for security attacks for vector-based color fonts.</font></li><li class="">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.</li><li class=""><font color="#000000" class="">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.</font></li><li class=""><font color="#000000" class="">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.</font></li></ol></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Given these two lists, Apple’s WebKit team and Core Text team are negative on this proposal.</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Thanks,</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Myles</div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=""></div><div class="" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">* 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, <span class="">at least now.</span></div><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 23, 2021, at 4:23 AM, Dominik Röttsches <<a href="mailto:drott@chromium.org" class="">drott@chromium.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi, <br class=""><br class="">This is a request for WebKit's position on COLR v1 vector color fonts.<div class=""><br class="">Spec:<br class=""><br class=""><a href="https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md" class="">https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md</a></div><div class=""><i class="">Proposed changes to ISO/IEC 14496-22 (Amendment 2)</i></div><div class=""><br class=""></div><div class="">Chromium Bug:</div><div class=""><a href="https://crbug.com/1170733" class="">https://crbug.com/1170733</a></div><div class=""><br class="">Summary:<br class=""><br class="">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. </div><div class=""><br class=""></div><div class="">Thank you in advance for your position statement on this topic,</div><div class=""><br class=""></div><div class="">Dominik </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>