W3C home > Mailing lists > Public > public-webfonts-wg@w3.org > November 2010

Re: two minor comments on the meta-data section

From: Chris Lilley <chris@w3.org>
Date: Wed, 10 Nov 2010 21:14:26 +0100
Message-ID: <3110556837.20101110211426@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:14 UTC