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 17:56:23 UTC