Re: WOFF 2.0: Known Table Tags Proposal

On 15/4/14 16:18, Levantovsky, Vladimir wrote:
> Folks,
>
> I would like to bring up one question regarding the DSIG table. The
> primary concern that I have is the validity of the table after the font
> is subjected to WOFF2 transforms that break bitwise compatibility
> between the original font that goes in and the optimized binary that is
> restored after decompression . If the DSIG table is present in the
> original font - what we should do with it once the font data is modified
> so that its functionality is identical but from bit count /content point
> of view it is a different binary?
>

It is impossible to reconstruct a bitwise-identical copy of the original 
sfnt from the WOFF2 data, and therefore it will be impossible to do 
anything meaningful with the DSIG.

(Aside from the glyf table transform/optimization, there's also the 
issue that AFAICS, the WOFF2 spec does not allow the original order of 
the font tables to be reconstructed. So even if each table remains 
identical to the original, their order may be changed and therefore the 
MD5 hash of the entire font will be different.)

So I think we should either specify that DSIG tables are dropped (in 
which case we can omit it from the known tags), or include a prominent 
note in the WOFF2 spec to say that any DSIG in the original font will be 
invalidated during the WOFF2 encoding/decoding process, and therefore 
font consumers should ignore it. (And therefore producers are advised 
not to waste space by including it in the input!)

JK

Received on Tuesday, 15 April 2014 15:40:14 UTC