W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

Re: WOFF and extended metadata

From: Jonathan Kew <jonathan@jfkew.plus.com>
Date: Thu, 20 May 2010 08:30:58 +0100
Cc: Christopher Slye <cslye@adobe.com>, public-webfonts-wg@w3.org, www-font@w3.org
Message-Id: <646F025A-A0A8-43F4-96A8-F26421E32EB6@jfkew.plus.com>
To: John Hudson <tiro@tiro.com>
On 20 May 2010, at 07:06, John Hudson wrote:

> Christopher wrote:
> 
>> That's it. I wasn't proposing a "schema". My assumption, based on the question having been asked, was that XML validation (i.e. confirming the code in the block is valid XML) was already taking place. I think what you're saying is that that's not the case.
> 
> So perhaps we're in a situation of saying *if* an UA performs XML validation of the WOFF file and finds that either or both the metadata or private data is invalid, then...

First, there shouldn't be any mention of the Private Data block here; by definition, it cannot be validated, it is an arbitrary block of bytes. The ONLY thing that can (and should) be checked is that the offset/length indicate a valid range within the file.

As for the Extended Metadata....

> I agree with Christopher that the preferable result in that case would be that the whole WOFF file is considered invalid and should not be used. If a font fails to display, that's then a signal that there is something wrong with the WOFF file, which can then be fixed, rather than a file with invalid data being persistently served.

But then browsers that don't even read the metadata block will accept and display the font, while those that DO attempt to read it will be required to reject the font. I don't think that's a helpful outcome; it will discourage browser vendors from touching the metadata at all, because doing so introduces the risk that they'll provide a worse user experience than competitors that ignore it.

We've seen a somewhat similar issue with regard to checksums. Firefox used to reject downloaded fonts if the 'head' table checksum was incorrect. This led to user complaints because fonts that worked fine in other applications failed to render in Firefox. As far as the user is concerned, this just makes the "strict" browser look bad. In the end, we decided to ignore the checksum error.

Just as incorrect checksums do not actually affect the ability to render the font, neither should invalid XML in the metadata. Of course the spec should require the data to be valid, but from the UA's point of view, the fact is that people do make mistakes, and UAs have to try and give the "best possible" result to the end user despite the vagaries of what's served by websites.

JK
Received on Thursday, 20 May 2010 07:31:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC