Re: Open issues in the WOFF 2 draft spec

I wanted to let everyone know that I've put the draft spec in CVS and also
updated it slightly in accordance with some of this discussion. I haven't
applied all of the discussed editorial changes, but hopefully it's a lot
closer to consensus.

The document now lives here:

http://dev.w3.org/webfonts/WOFF2/spec/

And you can see the cvsweb history etc here:

http://dev.w3.org/cvsweb/webfonts/WOFF2/spec/Overview.html

I didn't apply the Uint32 / ULONG change, because it's not obvious to me
which of these we should standardize on. I see that OFF uses ULONG, while
WOFF 1 uses UInt32. I don't think it matters all that much which we use as
long as we're totally consistent. Any preferences, or should we flip a coin.

The most recent version also does not contain any expansion of the known
tags table, something I am expecting we will still want to do.

Looking forward to discussing this more.

Raph




On Fri, Mar 28, 2014 at 7:21 AM, Levantovsky, Vladimir <
Vladimir.Levantovsky@monotype.com> wrote:

> 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
>
>