RE: WOFF and extended metadata

> From: Liam R E Quin [mailto:liam@w3.org]
> Sent: Wednesday, June 02, 2010 7:26 PM

>> Check. So we get to apply language matching/fallback rules on both 
>> sides of the name-value pair in order to produce the pair that best 
>> matches the current user's preferences.

> Web browsers already have code to do this as part of content
> negotiation, and/or in XML for xml:lang processing e.g. in
> XSLT and XPath; just make sure the spec allows that same code
> to be reused.
> 
> In the worst case a user agent could show all matching pairs and still
> be more useful than if the metadata were only in Urdu (say).

Yes, I am aware of what browsers already do here; I mentioned it to Tal in side 
thread. That doesn't make it desirable or reasonable, however. I very much doubt 
that your average font shop can or will take advantage of the ability to optimize 
name/value pair combinations as they'd have to test the mismatched name/value sets 
against a number of possible user language preferences to make sure the results 
always make sense. That doesn't sound like making their lives any easier.

In practice I would thus expect most font vendors to either match n names with n values, 
Or define n localized names for a single value e.g. for a global brand name. 

But I, as implementor, would still have to test the odd mismatched combinations almost 
no one will ever use to make sure I conform and can produce the proper result *if* things 
are unusual. And we as a WG will also have to build the testcases to verify this. (Any 
volunteers ?)

All of this also assumes that 1) the language matching rules we use for WOFF metadata are 
the same as those used by HTTP for Accept-Language or maybe xml:lang processing, and 2) that 
their current implementations are also correct and interoperable. I honestly  don't know if 
that's true, and I don't know if vendors will care to fix bugs for the sake of making font 
metadata display correctly either.

I conclude that the worst case you bring up is actually the sanest and likeliest option for an 
implementor i.e. show everything, possibly grouped by language tag. As this is the *optional 
extension area* of a file *metadata* block, I am in fact uncomfortable doing anything more than that 
until such time a font vendor comes up with an actual metadata block they want to store in their 
products that 1) needs localized metadata extensions 2) requires the ability to language-match names 
and values independently to produce name-value pairs and 3) uses so many languages and/or data that 
showing all the data to the user is an issue.

Received on Thursday, 3 June 2010 17:06:25 UTC