Re: Open issues in the WOFF 2 draft spec

I'm with John on this. The inclusion or exclusion of a tag in the known
tags table means (or should) mean nothing other than that we figure there's
a nontrivial probability we think we'll see this tag in a web font (or, for
that matter, the other use cases such as epub), so we can compress it
better. Because people might be confused seeing a list of tags, we should
probably add explicit language to the effect that the WOFF 2 file format is
agnostic as to which sfnt tags are present, and that the sole purpose of
the known tags table is to improve compression efficiency in the highly
probable case.

Regarding font tool specific tags, my sense is that there may be value in
documenting best practices for web fonts, which would certainly recommend
stripping these tags, but that it probably doesn't belong in a normative
spec. Such a best practices document would also (for example) give the
rationale for stripping the hdmx table. (This latter is something of a
complex subject, as this table was actually one of the significant sources
of compression gain for MTX, but my initial research and consensus point to
stripping it being even better than compressing it highly.) We talked about
starting such a "best practices" effort in Portland, but as far as I know
there hasn't been any concrete action on it.

I'm hearing what people are saying about alternatives to UIntBase128, but
I'm not yet convinced that any of the other proposals are much better.
Having a short/long flag feels just as complicated to me, and would not be
quite as compact. Having longs and the header inside the compression
envelope would probably not be quite as compact as the current proposal,
and would also make life more difficult for the use cases discussed
upstream where you would want to access information about the font without
opening a Brotli stream.

I totally agree that the (small but nonzero) complexity of UIntBase128
requires justification, but I'm personally of the opinion that the file
size savings and the convenience of being able to see inside the table
structure and resource requirements without decompressing is that
justification. Many binary formats provide something similar, for the same
reasons (I believe it's actually identical to the BER compressed integer
representation, and the format used in Protocol Buffers, DWARF, and DEX is
the same except for endianness, and big endian is more consistent with the
rest of the OFF spec).

So, personally, I think it's great we're considering alternatives, I'm
still most in favor of the format as it stands. Of course, that includes
Zoltan's most recent changes, which I'm very happy we're all in agreement
with.

Raph


On Thu, Mar 27, 2014 at 4:30 PM, John Hudson <tiro@tiro.com> wrote:

> On 27/03/14 3:07 PM, Behdad Esfahbod wrote:
>
>  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?
>>
>
> I certainly wouldn't like to take such a stance. WOFF should compress and
> wrap anything put in an sfnt; WOFF2 optimises the compression for some
> kinds of known data, but in general terms any table is WOFFable. Which is
> to say, I don't recommend putting jpegs of kittens in your web fonts, but
> it's out of scope for this working group to prevent you from doing so. It
> might also be unwise to load up a web font with layout tables for
> technologies that are not supported in most of the platforms to which the
> font is served, but again that's a decision for the WOFF creator, not for
> this working group.
>
> [I realise that this everything-in-an-sfnt-is-valid stance contradicts my
> earlier suggestion to declare custom tool source tables as invalid for
> WOFF. I reserve the right to be contradictory.]
>
> JH
>