- From: Chris Lilley <chris@w3.org>
- Date: Tue, 8 Feb 2011 15:58:15 +0100
- To: Bert Bos <bert@w3.org>
- CC: www-font@w3.org
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
Received on Tuesday, 8 February 2011 14:58:19 UTC