- From: Chris Lilley <chris@w3.org>
- Date: Wed, 10 Nov 2010 21:14:26 +0100
- To: David Singer <singer@apple.com>
- CC: WOFF Working Group <public-webfonts-wg@w3.org>
On Friday, November 5, 2010, 2:13:21 PM, David wrote: DS> The text: DS> If present, the metadata MUST be compressed; it is never stored in uncompressed form. DS> .... DS> The extended metadata MUST be well-formed XML encoded in UTF-8 or DS> UTF-16. The use of UTF-8 encoding is recommended. DS> The schema for the extended metadata XML is described below. If DS> the extended metadata does not match this schema, it is invalid. A DS> conforming user agent MUST ignore invalid metadata, as if the block were not present. DS> The point: DS> It's not defined what 'valid' means; a sentence is needed 'valid DS> metadata matches the schema and is compressed' or 'valid metadata DS> matches the schema' (which would allow UAs to process uncompressed but otherwise OK data) I agree. Since the word 'valid' could be understood either in a woff sense (conforms to all the MUSTs listed above)or in an xml sense (conforms to DTD/Schema), I think we need just a little more precision. I suggest: 'valid metadata is well formed, matches the schema and is compressed' DS> The text: DS> The metadata block MUST follow immediately after the last font DS> table. As font tables MUST be padded with null bytes to a 4-byte DS> boundary, the beginning of the metadata block will always be DS> 4-byte aligned. If the metadata block is followed by a private DS> data block (see below), the end of the metadata block MUST be DS> padded with null bytes to a 4-byte boundary. If the metadata block DS> is not followed by a private data block, it MUST either be padded DS> with null bytes to the next 4-byte boundary, or contain no DS> additional padding after the end of the block. DS> The point: DS> Earlier we learn that the padding is only allowed *between* DS> tables and must not follow the last one. I think the problem is the use of 'immediately' and could be avoided by 'immediately (at the next four-byte boundary)'. DS> This paragraph suggests DS> twice the contrary (that 'font tables must be padded', and at the DS> end saying if it's not followed by private data, it must be padded DS> -- but not if it's not followed by anything?). I'm sympathetic to not requiring padding after the last font table if there is no metadata or private. At that point you already have all the data, so requiring 0..3 bytes of padding seems pointless and requiring failure if it is not present, even more so. -- 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 Wednesday, 10 November 2010 20:14:32 UTC