Re: Open issues in the WOFF 2 draft spec

On Thu, Mar 27, 2014 at 12:26 PM, Jonathan Kew <jfkthame@gmail.com> wrote:

> I just noticed the current list omits the OpenType justification data
> table:
>     JSTF
>

I assume BASE is included already.


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

I understand so far it has been out of the scope of this working group.
 But does the WG like to take a stance over what "smart-font" technologies
are supported by WOFF2 (OpenType, Graphite2, AAT)?  Or explicitly stay
agnostic?

behdad


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