Re: [webkit-dev] New EWS Non-Unified builder

[Myles C. Maxfield via webkit-dev]

This seems to be a discussion around “when is doing things lazily valuable.” If 
the work will always have to be done eventually, then doing it lazily is worse 
than doing it up front. But of the work has a significant chance of never being 
needed to be done, then doing it lazily is better.

I think one could make a case that, on an infinite timescale, fixing a file’s 
includes will always have to be done, because it will always, eventually, one 
day, cause breakage.

> On Apr 30, 2021, at 8:44 AM, Darin Adler via webkit-dev 
>  wrote:
> 
> OK. I acknowledge my view on this is different from the others commenting 
> here, perhaps because of different ideas about what is hard and requires 
> expertise. I won’t stand in the way of changes you want to make. You know my 
> view now.
> 
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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