RE: WOFF and extended metadata

>Some foundries might choose to include what they consider very important information there. 
>For example, they might include customer information that will help them recognize legal web fonts.

>The overarching questions is this: If a foundry chooses to include extended metadata in a WOFF file, shouldn't that be considered an inextricable component of the WOFF? Yes, the creator of the WOFF is not required 
>to put it there, and the UA is not required to do anything with it, but still, should the UA be permitted to accept the font data without its accompanying metadata?

The question is what do you expect the UA to validate ? And what does it mean ?

Just checking for XML well-formedness would not buy you anything. Yay, it parses as XML ! I can just put <foo>bar</foo> in there and it'll work.

If you want to make sure it's valid according to some schema, that may be technically possible but a huge pain in practice. Those things evolve and get versioned, font vendors in different countries may want different schemas....Long story short: this is a huge rathole no UA vendor will want to touch (assuming the tool vendors want to). But even assuming for a moment that we can easily do this - maybe the metadata format never revs because it's blind collection of name-value pair, for instance - then what does it mean that the metadata is a valid document ? How can the browser possibly verify that the actual *data* in the metadata block has any kind of validity or relevance with respect to the font data it came with ? How does the UA determine the metadata block's content is *invalid enough* for the whole font to be ignored ? 

So what the UA *can* validate easily and efficiently cannot possibly be that useful to you because it's structural in nature. The UA can't tell what data is important or assert its correctness. All it can really say is that there is a license, that a machine can parse it and that it obeys very simple constraints e.g. "there is a vendor name". 

Same exact thing for the tool vendor. They'll prompt the user with a form, create the right XML but have no way to verify whether the input makes sense in any kind of useful way. 

Thus the question for you is: what do you expect the concrete benefits of adding such UA validation constraints to be for you as a font vendor ? And why do they justify giving the user the wrong font ?

The only benefit I can think of right now is that tool vendors are less likely to produce bad XML if browsers reject the font. And if I have UI to display this info to the user, I'm more likely than not to have something clean to render. 

But:
- I'd have to pay the price of decompressing and parsing this every single time. It isn't 'pay to play' i.e. all users would pay for this in CPU cycles whether or not they care to access this info.
- The browser that skips this validation will appear to 'work' from the perspective of an author using a bad tool. The author's reaction is not going to be that clearly, the browser that does what he wants is non-conformant! Not the best incentive for browser makers to comply.
- Font vendors, authors and end-users would suffer the occasional mistakes and bugs of tool makers for some time to come e.g. the tool works great as long as the user does not insert a certain character in the license form UI that should be escaped in XML
- And of course all UAs would have to do this to reap the full benefits, whatever they may be. Yet I very much doubt phone browsers will bother providing a UI to display this info and spend their precious CPU cycles and battery power parsing it.

Received on Thursday, 20 May 2010 02:12:06 UTC