Re: Open issues in the WOFF 2 draft spec

On 14/4/14 19:25, Levantovsky, Vladimir wrote:
> Hi Jonathan,
>
> Thank you for your detailed reply.
>
> You wrote: " So a developer could easily put together a WOFF2-serving
> feature that just applies the Brotli compression, as provided by a
> standard library module, but does not do glyf table transformation."
>
> This kind of optionality is exactly what I don’t like in the spec
> (any spec). If the group of experts who created the technology and
> standardized it decided that a particular feature has a value and
> needs to be supported - providing an option to circumvent it only
> diminishes the value of the spec. In our case, the WG (as evidenced
> by the WOFF 2.0 Evaluation Report) has clearly gone through an
> extensive exercise of making sure that the technical components that
> go into the WOFF 2.0 spec have significant value; making it easy to
> sidestep the spec and skip the part that brings significant
> advantages will reduce its value.

We've agreed that the transformation has value; but isn't it true that 
there may be multiple use-cases for the technology, and the trade-offs 
between implementation cost and value added may vary in different 
environments?

This is true for many aspects of fonts, and the specs we all work with 
reflect this. E.g. we have multiple outline formats, as well as optional 
bitmaps; we now have multiple technologies for colored fonts; within 
many of the font tables, there are multiple formats available (e.g. cmap 
subtables, OpenType coverage tables, long or short metrics formats, 
etc., etc.)

I don't see that allowing glyf transformation to be optional is in any 
way detrimental to WOFF2. There's no damage to interoperability, as long 
as the spec is clear that WOFF2 *consumers* must support both the 
transformed and non-transformed formats (and the cost of supporting 
both, compared to supporting ONLY transformed, is negligible). All we'd 
be doing is allowing *producers* to choose whether to optimize for 
minimal file size or for reduced code-complexity and computation on the 
generation side, and I think that's a legitimate choice to offer.

>
> In my opinion, an optional feature in general will be detrimental to
> the value of any standardized technology. Optional features that must
> be supported nevertheless (as would be the case with glyf transform)
> may raise the concerns of implementers who have to do the work for
> seemingly little benefit, while features that are optionally
> supported by implementations hurt interoperability and make it
> non-option for developers. So, unless it is truly needed and
> supported by real uses cases - I'd avoid making stuff optional in the
> spec as much as possible.
>
> From the pragmatic point of view (thanks to Google folks once again
> for making it possible) - both Brotli codec and WOFF 2.0 glyph
> transformation code are easily accessible as they are parts of the
> open source project. The complexity of glyph transform is minimal
> compared to entropy codec part - I don’t see a reason to let it be
> skipped at the expense of losing compression gains since the code is
> readily available for anyone and can be used without concerns of any
> IP restrictions.

Both the Brotli codec and the glyf transformation code are easily 
accessible in the form of C++ source code, but this does not necessarily 
equate to being equally accessible within all web development 
environments. My assumption - which may of course be wrong, but it's my 
current guess - is that the Brotli codec will become much more widely 
available than the transform code, which will remain a pretty 
specialized piece of code that gets built into a few WOFF2-generating 
tools but not necessarily part of every development language's libraries.

>
> Let's discuss this at the telcon this week and make a final decision
> then.
>

Unfortunately, I won't be able to make this week's telcon (again), 
sorry. But if all the rest of the group is happy to make a decision, 
that's fine. I've tried to explain my thinking, but if nobody else feels 
this way, I'll drop the issue.

JK

Received on Monday, 14 April 2014 18:53:23 UTC