W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

Re: WOFF and extended metadata

From: Adam Langley <agl@google.com>
Date: Thu, 20 May 2010 10:29:38 -0400
Message-ID: <AANLkTilFBIAymeWY2lYDHRiDflSY-gqSD6lF3fgxELGj@mail.gmail.com>
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>
Cc: "robert@ocallahan.org" <robert@ocallahan.org>, 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>
On Thu, May 20, 2010 at 10:17 AM, Levantovsky, Vladimir
<Vladimir.Levantovsky@monotypeimaging.com> wrote:
> It would help greatly to clarify things if you tell us where you see a connection between XML metadata and font rendering pipeline. For example, JPEG file format includes EXIF metadata - most image viewers allow you to see it via properties / image info dialog but it has nothing to do with JPEG decoder that processes image data.
>
> Similar, font data encoded in WOFF and XML-formatted metadata are two separate and completely independent blocks of data. Unpacked font data goes into the font rendering pipeline while metadata remains to be a part of the WOFF file. If UA provided a dialog displaying font info encoded in metadata, how could it possibly affect font rendering pipeline?

The term UA here is a little loose. Browsers, for example, typically
don't show EXIF metadata for JPEGs (at least in my experience and I
can't find it clicking around in Firefox nor Chrome). Image
manipulation tools, being more focused, certainly do.

Likewise, I wouldn't expect to be able to view font metadata in a
browser, while I would in a font editing tool.

The value of validating XML metadata in a browser is likely to be
dwarfed by the costs in time and code complexity. For the Chrome code
base I can say that without the qualification.


AGL
Received on Thursday, 20 May 2010 14:30:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC