On Wednesday, January 12, 2011, 4:16:26 PM, Bert wrote:
BB> 3) Section 7 Private date block: Why is the padding at the end a
BB> "should"? I could understand "must" (something you can test), or
BB> "may" (just ignore it). But if you are going to ignore the padding
BB> anyway, why should generators try hard to not write it? Ditto for the
BB> padding of the extended metadata block.
BB> It is also ironic that the specification accuses the OpenType spec of
BB> not being clear about the padding of the final table, and then itself
BB> allows that padding to vary. (Sure, WOFF is not _unclear_, but the
BB> effect is the same. Imagine that some future Meta-WOFF wants to
BB> encode WOFF: it will have the same problems as WOFF in ensuring
BB> roundtrip encoding...)
BB> Which means that a "must" seems the best choice. Whether it is "must
BB> be omitted" or "must be included" is less important, although doing
BB> the same for all blocks, whether the last or not, seems easiest.
We agree and have decided that "must be omitted" makes most sense. Thus, the end of the private data block (if present) coincides with the end of the file.
Please let us know if this change responds to your comment. (your other comments will be the subject of separate mails, for tracking).
Tracker, this relates to
ACTION-70
Replace last sentence of section 7: End of Private Data block must correspond with the end of the last file
Jonathan Kew
--
Chris Lilley Technical Director, Interaction Domain
W3C Graphics Activity Lead, Fonts Activity Lead
Co-Chair, W3C Hypertext CG
Member, CSS, WebFonts, SVG Working Groups