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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
