RE: Open issues in the WOFF 2 draft spec

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.

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.

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

Thank you,
Vlad


-----Original Message-----
From: Jonathan Kew [mailto:jfkthame@gmail.com] 
Sent: Monday, April 14, 2014 1:56 PM
To: Levantovsky, Vladimir; Raph Levien; public-webfonts-wg@w3.org
Subject: Re: Open issues in the WOFF 2 draft spec

On 9/4/14 22:10, Levantovsky, Vladimir wrote:
> Hi Jonathan, all,
>
> As we discussed during today's WG call, I would like to have all open 
> issues resolved to prepare the spec for the First Public Working Draft 
> release. The one below is one remaining issue that we need a consensus 
> on - I believe Raph and I are in agreement that it would be useful and 
> practical to have glyph transformation defined as mandatory (and I 
> explained why I feel that way in my earlier email to the list). Are 
> there any remaining objections to making it mandatory?
> If yes, please respond on the list with your comments or concerns, 
> otherwise we will consider it a consensus approval.

Hi Vlad,

My preference would still be to make the glyf-table transformation optional, as originally proposed in the draft spec, but I don't want to make a big issue out of it if I'm alone in this view.

I don't see any significant burden for implementers (on the decoding
side) in making it optional; it shouldn't be more than a few lines of code to check whether the table is transformed or not, and if not, treat 'glyf' and 'loca' just like other non-transformed tables.

On the font generation side, I anticipate that anyone creating a library of WOFF2-packaged fonts will normally want to use the glyf transformation, to minimize the size of the compressed fonts. But I still think there may be a use case for skipping the transformation when fonts - or perhaps subsets of just a few glyphs - are being created on the fly. Partly because this could significantly reduce the computation load on a server, and partly - perhaps mainly - because it could reduce the amount and complexity of the code needed to dynamically create WOFF2 fonts.

I envisage that before very long, the Brotli compressor is likely to be packaged as a reusable library on many systems, so that it would be readily available to scripting languages such as Perl or Python or Ruby that might be used to build dynamic sites or online tools. I doubt the
WOFF2 glyf-transformation code is likely to be nearly so widely available, given its more specialized nature.

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. But if the transformation is a required part of the spec, anyone wanting to serve
WOFF2 fonts will have to get access to (or rewrite) that code as well, and as mentioned, I don't expect it will become such a standard part of many development environments.

ISTM, therefore, that making the transformation compulsory may hinder the adoption of WOFF2 as a complete replacement for WOFF in all situations, because it will be significantly less convenient to build a simple WOFF2-generator in an arbitrary programming environment.

I'd be interested to hear from a few more people in the WG on this issue; if I'm truly in a minority of one here, I don't want to hold things up, but it's not clear to me how many people have actually considered the question at this point.

JK

>
> -----Original Message----- From: Levantovsky, Vladimir
> [mailto:Vladimir.Levantovsky@monotype.com] Sent: Friday, March 28,
> 2014 10:22 AM To: Jonathan Kew; Raph Levien;
> public-webfonts-wg@w3.org Subject: RE: Open issues in the WOFF 2
> draft spec
>
> Hi Jonathan,
>
> Yes, Brotli will definitely reduce this byte count difference but I
> believe we already have the numerical estimates on how much gain we
> get from the preprocessing step overall, and it's nothing to sneeze
> at. So, even an extra 1% or more of savings on a reasonable / usable
> font subset of let's say 10K in size will give us more bang for the
> buck than table directory savings, so both of the techniques would be
> reasonable and useful to apply.
>
> Putting this byte count aside - I honestly don’t see the reason or a
> use cases for not doing the preprocessing - the decoder complexity is
> relatively minor, and definitely doable even on low-powered mobile
> devices - those same devices where bandwidth costs are typically much
> higher than broadband so the minor losses in performance will be
> offset by bandwidth savings and faster download times.
>
> Thank you, Vlad
>
>
> -----Original Message----- From: Jonathan Kew
> [mailto:jfkthame@gmail.com] Sent: Thursday, March 27, 2014 5:34 PM
> To: Levantovsky, Vladimir; Raph Levien; public-webfonts-wg@w3.org
> Subject: Re: Open issues in the WOFF 2 draft spec
>
> Hi Vlad,
>
> On 27/3/14 20:34, Levantovsky, Vladimir wrote:
>>
>>>> The next issue was making the transform mandatory for the glyf
>>>> and loca tables. I'm fine with this. I agree with the principle
>>>> of making as few things optional as possible, unless there
>>>> really is some compelling reason, and don't think
>>>> non-transformed glyf rises to this level.
>>> Here, I'm inclined to prefer retaining the optional nature of
>>> the
>> transform.
>>> I think the added cost/complexity for implementations is pretty
>> negligible,
>>> and it makes it more realistic to imagine that WOFF2 may -
>> eventually, over
>>> time - serve as a complete replacement for WOFF1, rather than
>>> the two co-existing forever as two distinct formats.
>>
>> I agree that the cost of retaining 'no transform' option is
>> negligible (or even non-existent) as both the encoder and decoder
>> implementations will have to support both branches of execution -
>> but I believe that the benefit of having a 'no transform' option is
>> also negligible. Like I said in my earlier email to Raph, if we do
>> care about squeezing as much redundancy out of font data as
>> possible, and to achieve that we are contemplating an option of
>> introducing either a specific data type or a specific table
>> directory sub-format to save 40+ bytes - the savings would be more
>> substantial if we apply 'glyf' transform to a font subset of only 6
>> glyphs - we would eliminated 48 bytes of bbox info and at least
>> another 12 bytes of loca table.
> FWIW, a good deal of that difference might end up being eliminated by
> the Brotli compression step, so that the final difference between the
> transformed-compressed and the nontransformed-compressed may be much
> less.
>
> JK
>

Received on Monday, 14 April 2014 18:26:07 UTC