Comment on WOFF file format 'origCheckSum' value

Hello WG,

I'd like to start the discussion on WOFF file format by presenting the following for your consideration:

Currently, the WOFF table directory contains 'origCheckSum' field [1] that, as I understand it, is simply a duplication of the 'checkSumAdjustment' value from the original SFNT file's 'head' table. While I understand the reason why this field was made part of the WOFF table directory it, in my opinion, does little to protect original font data (the original checksum and the font data integrity can be evaluated just by running checksum check after decompressing font tables), and it does nothing to protect the WOFF file data itself (it doesn't cover data entries that are part of the WOFF Header, Extended Metadata, Private Data and Table Directory itself).

I suggest that the scope of this field should be extended (and if we agree, the field itself may be moved to a different part of the file, e.g. Header). I believe it would be useful to make this field cover both the original font data and the WOFF data, so that when a value is calculated - the  WOFF data is taken into account and, upon running a checksum check, the value of 'origCheckSum' would be produced when the value encoded in the WOFF file is summed up with the rest of the WOFF data. This way, we would allow user agents to verify that both the WOFF data and the original SFNT data are intact.

Also, we should make it clear in the spec that any font data manipulations (such as subsetting) that may affect original checksum values (both on a 'per table' basis and overall) are done at the time of content authoring, prior to compressing the resulting font subset as a WOFF file. User agents should not make any attempt to correct the checksums if a mismatch is found, and should simply reject the font file if the checksum doesn't match.

Regards,
Vlad

[1] http://www.w3.org/Submission/2010/SUBM-WOFF-20100408/#TableDirectory