Sorry for a slow response on this topic. I have some thoughts in reply to Myles' comments. Before jumping in, let me mention that Microsoft in general is supportive of the COLR v1 proposal, and has contributed to its development; and Microsoft's web-platform team is aligned with Chromium on COLR v1 support. Now for specific remarks. I'm looking at this from the perspective of what makes sense for the OpenType spec and colour fonts generally, though along the way I'll take into consideration what may or may not make sense for WebKit.

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's fair to ask whether there is some existing, binary serialization format. And, I find it particularly interesting since, in past interactions (five or so years ago), I was given to understand that Apple engineers would have been interested if Microsoft had pursued a COLR enhancement or _some_ vector format for color glyphs _other than_ SVG. For an enhancement in OT, I'd rule out something based on XML (or JSON, etc.) rather than a binary format since these are inherently less efficient size-wise. There are, of course, things like .swf, .emf, .eps, and of course .pdf, though I don't know of any that would clearly a better choice: If they're not too product-specific (such as .emf), they're also too generic, supporting far more than is needed. We'd face the same issue you'll recall we had with OT-SVG of figuring out what parts to explicitly exclude. (It's the same issue why, in the OT spec, PDF is excluded as a supported format for the sbix table.) Moreover, none of those formats can take advantage of tables OT already has for representation of vector geometries: the 'glyf', CFF or CFF2 tables. (This is an issue, as well, for OT-SVG.)

It doesn't exist yet (outside of a development configuration of Chrome).

"Doesn't exist elsewhere" could have been used to argue against any number of other things. It could have been used as an argument against adding variations to OT back in 2016. I don't think it's a useful argument of itself. Rather, one needs to ask whether or not there are technical merits that might make a case for supporting it elsewhere.

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.

That's true; but one can't say that OT-SVG is ubiquitous by any stretch. As we know, it's not supported in Chromium. But there are also many other contexts in which the OT spec is supported as a font format, yet in which OT-SVG is not; and there's fair reasons to think there are contexts in which OT-SVG would not likely be supported if there were another binary-format alternative. OT / OFF is supported in lots of consumer electronic or other classes of device beyond computers and phones. There will be many small-device contexts in which there may be interest in colour fonts but in which there will concerns such as size that will make OT-SVG less than ideal.

Many OT-SVG fonts already exist.

Yes, there are existing OT-SVG fonts. But OT-SVG fonts aren't _that many_ in number, and aren't exactly taking off. I suspect that font developers have shied away because there hasn't yet been one clear winner for colour font format.

Because this proposal doesn't exist yet outside of Chrome, there is no ecosystem in existing authoring tools.

Again, this is the "doesn't exist elsewhere" argument I commented on above.

Conversely, many design authoring tools already export SVG.

True; and I expect that SVG will remain an important format in COLR v1 font development workflows because it is a common format supported in most/all graphics-authoring tools. In that regard, it's a much better choice as input to a font compiler than font-compilation tools having to support a variety of formats supported in various graphics-authoring apps-.eps, .ai, .dwg, etc.. But support for SVG as an input format doesn't imply that font compilation tools wouldn't support compilation from SVG to COLR v1: I suspect the consideration for the likes of FontLab and Glyphs will be about how many of their customers want to generate COLR v1 fonts, and not about whether they could otherwise have generated OT-SVG fonts. I can't predict that FontLab, etc. _will_ support compilation to COLR v1. My point is only that I don't see this as a strong argument against enhancing OT with COLR v1 and supporting it in apps or on the Web. Of course, for browser / application developers, availability of font tools to generate COLR v1 is not irrelevant since it's an indirect predictor of the prevalence of COLR v1 fonts. For app developers, current or anticipated prevalence of COLR v1 fonts will certainly be an important consideration. If you're saying that you _do not_ anticipate much use of COLR v1 in fonts, then I can't really argue against that since there isn't enough data yet one way or another.

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.

That's a fair argument... for a browser developer whose product already has XML and CSS parsers built in. But as mentioned above, there are many other contexts for OT fonts that do not have independent reason to support SVG/XML/CSS parsers. For those contexts, your reasoning above strongly suggests that the runtime binary size increase for supporting COLR v1 would be _much smaller_ than for supporting OT-SVG. This isn't making the case that, therefore, WebKit should support COLR v1 at this time; but I think it does make the case that, in the long term, COLR v1 may have an advantage over OT-SVG for at least some app or device contexts in which colour font support might be considered.

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.

True, it will require new parsing. That will be true of any new enhancement to OT. Of course, that comes with new surface area for security attack. This is a cost to be considered for many potential features that might be considered for software products. As is always the case, the fact that there are such costs isn't of itself a deal-breaker, but one considers this with other costs of development to evaluate against anticipated benefits.

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.

I don't think it's actually all that complicated. There was potential to misunderstand: I, myself, misunderstood important aspects of the proposed design on reading an earlier, much shorter proposal doc. And I made a point to put lots of details into the spec with a view to providing clarity that would lead to interoperability. The possibility that implementations will not be interoperable is a hypothesis that would be empirically tested each time someone attempts to implement. But I'm not sure it's valid to make a sweeping generalization that it's too complicated to lead to interoperability. That feels to me like a premise being crafted to support an a priori conclusion. If you can point to specific aspects of the spec that are not sufficiently clear, then that would be helpful --- and the spec can be improved. Frankly, I think variations was **much** more complex than this. * The amount of content added to the spec for variations was **well over double** that added for COLR v1, and that was for mostly extending existing concepts with a few new concepts versus mostly-new concepts for COLR v1. * Variations introduced eight entirely new top-level tables, versus zero new tables for COLR v1. * The binary formats added for variations included several complexities: * run-length-encoded data; * table members that semantically comprise multiple sub-fields that need to be parsed and processed separately; * many places in which inter-table references and validations are involved; and * several new concepts that interact in complex ways (see how many people can explain why HOI works). In contrast, the new formats for COLR v1 are much simpler to parse with only a few inter-table references ('glyf' or CPAL entries) or validations (maxp.numGlyphs). Yet very quickly many different implementations for variable fonts arose with a high degree of interoperability.

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.

The radial gradients are very similar to those defined in PDF and those in HTML Canvas 2D, the only differences being with extend modes.

As far as we're aware, this proposal has not undergone a rigorous standardization process from many independent stakeholders.

It is in the midst of that very process. There is an alpha for OT 1.9 published for broad review (OpenType 1.9 Alpha Review - Typography | Microsoft Docs<https://docs.microsoft.com/en-us/typography/opentype/otspec190alpha/ot190alpha>); a working draft for the corresponding ISO standard has been available for review for several months; and there have been a number of technical comments submitted from reviewers that have been addressed in the spec.

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.

I'm a little puzzled as to why a lack of support for raster data embedded within COLR v1's vector formats is seen is a big gap. Raster data with a vector image might be useful as a pattern fill that can be repeated as the geometries are scaled, but otherwise a raster image doesn't scale, which is a key aspect of vector graphics. Addition of patterns is something that could potentially be added in the future. Also, noting that, in some cases, someone might want to a raster image alone as a colour glyph for a character, giving the designer control over every pixel, nothing in the spec prevents a hybrid approach in which colour glyphs for some characters are implemented as vector data using COLR v1 while the colour glyphs for some other characters are implemented as raster data using sbix. If raster image data were assumed to be the best of all possibilities for colour glyphs that would put an end to the colour font fragmentation problem, then I think that's clearly not a valid assumption since colour raster formats have been available to font developers since colour fonts first became a thing almost a decade ago.

Given these two lists, Apple's WebKit team and Core Text team are negative on this proposal.

As one vendor considering support in an app, I can certainly understand a perspective of saying, This has costs but doesn't provide immediate benefits for what I use in my products. When considering support in a platform or an app that needs to support user content, I can certainly understand a perspective of saying, I will wait to see how much demand there will be. But there are several aspects in the reasoning given by Myles that I don't find compelling. Cheers! Peter