Re: WOFF 2.0: Known Table Tags Proposal

On Tue, Apr 15, 2014 at 8:39 AM, Jonathan Kew <jfkthame@gmail.com> wrote:

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


Great catch and analysis Vlad and Jonathan!

I've updated the Known Table Tags Proposal, removing DSIG and updating the
following tag assignments accordingly:
https://docs.google.com/a/google.com/spreadsheets/d/111MT0l7LOVqotAnMXD4PMOm36jTPSznUigJPfxUYY_0/edit#gid=0

>
>
> JK
>
>
>