- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Wed, 2 Jun 2010 18:41:54 +0000
- To: Jonathan Kew <jonathan@jfkew.plus.com>
- CC: Håkon Wium Lie <howcome@opera.com>, Tal Leming <tal@typesupply.com>, Vladimir Levantovsky <Vladimir.Levantovsky@monotypeimaging.com>, Christopher Slye <cslye@adobe.com>, "www-font@w3.org" <www-font@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
> From: Jonathan Kew [mailto:jonathan@jfkew.plus.com] > No, <name> and <value> are paired by virtue of being children of the > same <item>. 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. This is definitely the bit I missed. It's certainly very flexible but a level of processing complexity I frankly wasn't expecting here. Achieving consistency across UAs and tools processing this data will require more work, spec prose, conformance criteria and possibly test cases than I had ever anticipated for file metadata. I strongly feel we're trying to anticipate too much because we in fact know so little. As I told Tal in a separate exchange, I am starting to wonder if your generic XML rendering proposal may not be the better option today for the entire block. Until such time font vendors agree on a common metadata format *they* are all comfortable with based on market practice.
Received on Wednesday, 2 June 2010 18:42:44 UTC