Re: Open issues in the WOFF 2 draft spec

Thanks for all this, Raph; looks great. A few comments below:

>     Zoltan agreed with Jonathan Kew's suggestion to move the compressed
> stream size out of the table directory and into the WOFF 2 header.
> While I was at it, I also moved the transform bit from bit 5 to bit 7
> and made bits 5 and 6 reserved for future use, now set to 0. This way,
> if there is an agreement to extend the list of known tables, it will be
> very easy to do in a backward compatible way."
Right - this is exactly what I had in mind.

>     The next open issue was expanding the known tags table. I thought I
> heard consensus for including including all three current color font
> proposals.
Yes.
>     What other tags make sense to include?
I just noticed the current list omits the OpenType justification data table:
     JSTF

Add the layout tables for SIL's Graphite engine:
Silf
     Sill
     Gloc
     Glat
     Feat

And given that we now have 7 bits rather than 5 to play with, I'd 
recommend also including AAT's various tables. At present, only Apple 
systems make use of these, but there has been some interest in 
supporting AAT fonts more widely (Behdad has talked of adding support in 
HarfBuzz). So:
     acnt
     avar
bdat
     bhed
     bloc
blsn
     cvar
     fdsc
     feat
     gvar
     just
     lcar
     mort
     morx
     opbd
     prop
     trak
     Zapf
(I think this list is pretty complete, but it would be good to check 
with Apple's font people whether this is current, or whether any of 
these may be obsolete.)

>     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. As
> Vlad pointed out, for use cases that would benefit from lower cost
> processing than WOFF 2 encoding or decoding at the expense of file size,
> WOFF 1 still suffices well.
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.

>     The next question was whether to move the table directory inside the
> compression envelope. I'm going to argue against it, but again am very
> open to discussion.
I prefer it outside, so that certain higher-level aspects of the font 
can be examined before decompressing the Brotli stream.

>     Finally, I want to address a question that came up that I don't
> think are tied to potentially incompatible changes. Vlad asked for a
> justification of the UIntBase128 encoding for lengths. Removing this and
> using 32-bit ULONGS would roughly double the table directory size,
> bringing it from 53 to 98 bytes for the font I measured. If necessary,
> we could run experiments over a larger corpus, but I expect extremely
> little variation. incidentally, removing the "known tags" optimization
> would add 57 bytes (under the conservative assumption that we could get
> rid of the flags byte altogether now).
How about revisiting the idea of two versions of the table directory, a 
"short" one where all the lengths are USHORT, and a "long" one where 
they're ULONG? Small fonts such as those containing just a few glyphs 
would be able to use the short format, which should give an overall size 
very close to that you get by using UIntBase128, but without the 
complexity of that variable-length type; and in large fonts that need 
the "long" format for their 'glyf' table (for example), the directory is 
relatively insignificant compared to the table payload.

IMO, that might give virtually the same benefit, without the need to 
introduce a more complex data type at this level.

JK

Received on Thursday, 27 March 2014 19:27:21 UTC