- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Tue, 25 May 2010 18:47:33 +0000
- To: Jonathan Kew <jfkthame@googlemail.com>, Tal Leming <tal@typesupply.com>
- CC: Vladimir Levantovsky <Vladimir.Levantovsky@MonotypeImaging.com>, "robert@ocallahan.org O'Callahan" <robert@ocallahan.org>, Adam Langley <agl@google.com>, John Daggett <jdaggett@mozilla.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:jfkthame@googlemail.com] > Actually, I'd suggest that unless there are significant technical > problems with using XML as currently specified (modulo any > clarifications etc that we decide are needed), we probably shouldn't be > reopening this issue. As the Charter > <http://www.w3.org/2009/08/WebFonts/charter.html> says, "...the group > would be chartered to only make the minimal changes needed for > interoperability and standardisation." Replacing the XML metadata with > JSON or some other format is hardly such a "minimal change", unless the > existing XML option is fundamentally flawed in some way. Unless implementations of the metadata block format already exist, or large numbers of fonts have been distributed that use the format currently specified, there would seem to be limited interop risk to reopening this. This is probably our last chance. Note that I'm not so concerned about the actual serialization - say, JSON vs. XML - as I am about the simplicity of the actual schema. The simpler the structure, the more likely it is that browser vendors will be able to display *all the metadata in the font* going forward, vs. only the subset of it defined in the spec (until such time an industry standard emerges, if ever). If a font vendor in Japan or Poland extends the current schema significantly for the purposes of their own market requirements - including legal and regulatory - that extra data might well not show up in our info dialog if we don't know the shape of the extra XML. (And we most likely won't). But if it were a flat list of properties - possibly tagged with a language code - then we can always show everything that's there. So imagine we started with: <property name="FontName" value="Comic Sans++" /> <property name="FontVendor" value="Funny Fonts, SARL" /> <property name="LicenseURL" lang="en" value="http://funnyfonts.com..." /> <property name="LicenseURL" lang="fr" value="http://funnyfonts.com..." /> ...(lots more stuff)... ...then Monotype buys Funny Fonts and adds this to the above: <property name="Trademark" lang="en">A trademark of Monotype Imaging Inc.</property> <property name="MonotypeRef" value="AA-113" /> <property name="FontRevision" value="1.1" /> <property name="FontUpdate" value="http://www.monotype.com/webfonts/update/AA-113" /> ...(more MonoType-only metadata follows)... Then I can write one piece of code that will show *all* the data in both cases when the user asks for it. The format is thus extensible: if the font vendor adds more, the browser will show more when asked. Everywhere in the world, a browser will be able to show all the properties listed. But if the system is such that Monotype will append or insert their own arbitrary XML tree then I might not even try to parse it. I just don't know how to render it. I may offer an option to do a raw view-source to see the rest. Or I may not. Thus, if font vendors very much want the UA to show all the metadata in a font, then I am not sure a schema such as the current one is extensible for this purpose.
Received on Tuesday, 25 May 2010 18:48:08 UTC