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 Friday, 28 March 2014 14:29:50 UTC