W3C home > Mailing lists > Public > public-webfonts-wg@w3.org > May 2010

RE: WOFF and extended metadata

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Mon, 24 May 2010 18:53:48 +0000
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>, "robert@ocallahan.org" <robert@ocallahan.org>
CC: Jonathan Kew <jfkthame@googlemail.com>, 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>
Message-ID: <045A765940533D4CA4933A4A7E32597E21490528@TK5EX14MBXC120.redmond.corp.microsoft.com>
> From: public-webfonts-wg-request@w3.org [mailto:public-webfonts-wg-
> request@w3.org] On Behalf Of Levantovsky, Vladimir
> Sent: Monday, May 24, 2010 6:00 AM


> Persuasion is exactly what I am doing here. 

Well, persuasion is what I am looking for. I keep asking what such a validation
requirement is for and am not getting any concrete answers.

> To summarize the current status of the discussion:
> - I believe we have already reached a consensus that browsers are *not*
> required to validate the metadata in a WOFF file in order to render a
> font packaged in it.
> - WOFF file and the unpacked font should *not* be rejected because of
> the invalid XML metadata.
> - Metadata content will only be displayed to a user if the user wants
> to see it and is asking for it (e.g. by selecting "View font info",
> "Page info" or a similar option provided by a browser).

Good.

> - Browsers already have the ability to present XML data to a user, and
> displaying WOFF metadata upon user's request would not introduce any
> additional implementation complexity.

I don't think the spec cannot require UI. I can't imagine forcing phone browsers 
to provide a font info UI. Like Hakon, I don't think we should make arbitrary 
exceptions for these UAs but not others. If we're OK with only showing this info
when the user wants to see it, then we're OK with letting browser vendors decide
how and when to implement this based on user feedback. I'm pretty sure web authors
will want this and desktop browsers will be happy to oblige.

If the font will work regardless of the presence of XML metadata, its validity or
the browser's ability to make sense of the actual metadata format stored by the
font maker then all we can say is that browsers should provide a means to access it.

As for rendering it, a browser can always display raw XML but that's not very friendly.
The alternative is for us to specify a schema; that is not an undertaking I am comfortable
with either. Let's just say UAs may not be willing to wait for this format to settle in 
order to add support for WOFF. 

My personal preference would be to forgo XML here and use a flat property bag/name-value
pair format no more complex than JSON. We'd define a basic set of common property names
 e.g. font name, authors, copyright, version, vendor URL etc. and let font makers add whatever 
else they wish. It will be far easier to create, edit and extend; and browser vendors will be 
able to provide a generic UI control to show all the properties. 

It could be that I missed the reason to use XML e.g. maybe we want to nest things hierarchically.
Since Firefox is the first implementation out there, I'm curious to hear about what they have done
in this respect, or what their plans are ?




Received on Monday, 24 May 2010 18:54:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 24 May 2010 18:54:36 GMT