Re: [webkit-dev] Request for Position: COLR v1 Vector Color Fonts

[Dominik Röttsches via webkit-dev]

Hi Myles,

Thank you for responding to our request for a position statement. I
conclude we both want to bring adoption to a successful color vector format
to the web. That’s why I’d like to respond to your points in detail,
highlight benefits of COLRv1 and also point out where we disagree with
assumptions or arguments in your list.

In short, on the basis of data we’re presenting below, we are convinced
that COLRv1

   -

   is easy to integrate with fewer code and dependencies than SVG. (Given
   the current level of support for CSS, SVG, OT-SVG in WebKit, CoreText,
   CoreGraphics which all serve as foundations, I think you could have a
   working COLRv1 implementation in two weeks to a month.)
   -

   shifts complexity away from the client to a font production pipeline
   (assisted by publicly available tools we offer, nanoemoji
   )
   -

   ultimately provides significantly better performance at a much smaller
   font size, see measurements below.


COLRv1 seamlessly integrates with existing font concepts, does support
variations and does not reinvent contour/path definitions. It’s also easily
extensible should support for bitmaps or filtering be required.

With this in mind, in particular the relatively low complexity of
implementing the format and the extremely low usage of OT-SVG on the web
(see below), we invite you to reconsider your position.

Here’s data we collected based on our current work in progress in Chrome

.

*Performance*

In a comparison between cold cache SVG and COLRv1 glyph drawing (Benchmark
code ), drawing an
SVG glyph from the Noto Color Emoji set is 20-45% slower on average than
drawing the glyph from COLRv1. This performance difference is relevant for
initial page drawing and font size changes, i.e. in all situations where a
fresh glyph rasterization is requested. Page redraws or repainting a same
glyph would usually be covered by a form of texture caching.

Performance tracing shows that COLRv1 succeeds here due to SVG parsing
overhead, while the drawing execution is roughly in the same ballpark.
Using SVGZ would add to the parsing overhead. In addition, the comparison
performed favors OT-SVG as it does not cover additional steps required in
OT-SVG such as finding the matching SVG document for a glyph in the SVG
table, and finding the glyph in the XML tree.
*Font Size*

For the full emoji set of Noto Color Emoji, the smallest SFNT size for
COLRv1 (cff2 contours) is ~3.97MB, the smallest SVGZ size is ~8.91MB (after
picosvg SVG flattening / optimisation). After WOFF2 compression, the
smallest COLRv1 (glyf contours) is ~1.94 MB and the smallest SVG is ~5.66MB
(uncompressed SVG woff2-compressed).

So, in this example glyph set:

   -

   WOFF2 compressed: COLRv1 is roughly a third (34.3%) of the size of
   OT-SVG,
   -

   Non-WOFF2-compressed fonts: COLRv1 is less than half (44.5%) of the size
   of OT-SVG.

*Complexity / Security*

   -

   The total LoC of C, C++ code and headers for COLRv1 glyph rendering
   functionality in Skia and FreeType is ~1257 lines of code. Details in
   this analysis.
   

   For comparison, Skia’s SVG module has 6168 LoC - that’s almost 5 times as
   much, and the LoC count does not even include the XML parser dependency. A
   big portion of SVG code is taken up by custom XML attribute parsers for SVG
   on top of the XML library, for example SVG’s path definition.
   -

   The binary size impact of a COLRv1 implementation is minimal as shown by
   data from Chromium
   
.
   Chromium’s COLRv1 implementation in FreeType + Skia adds only 8-12kb binary
   size on a Chrome Android APK build or on a Windows release build.
   For comparison, the threshold where our Android release engineering’s
   bot warns about a significant binary size increase is 20kb. libxml2 on its
   own compiles to roughly 30kb in a release configuration for Android.


*Real world OT-SVG usage*

Data from the httparchive

set shows that out of 25.8 million desktop requests to resources that
contain additional font metadata in the requests_desktop table, only 786
requests, or 0.00305% of them are fonts that contain an SVG table. Among
those, the main ones are Adobe’s Ten Mincho and Source Code Pro, which are
not mainly color fonts but contour fonts that contain a set of SVG glyphs
as a feature. Without those, the usage of SVG fonts is even lower, 95
requests, or 0.00037%.



On Wed, Mar 31, 2021 at 2:00 AM Myles C. Maxfield 
wrote:

> Hi Dominik!
>
> [...]
>
> At a high level, here is a 

Re: [webkit-dev] Request for Position: COLR v1 Vector Color Fonts

[Peter Constable via webkit-dev]

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 

Re: [webkit-dev] Request for Position: COLR v1 Vector Color Fonts

[Myles C. Maxfield via webkit-dev]

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  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 
> 
> Proposed changes to ISO/IEC 14496-22 (Amendment 2)
> 
> Chromium Bug:
> 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 
> 
> 
> 
> 
> 
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev