- From: Adam Langley <agl@google.com>
- Date: Thu, 20 May 2010 10:29:38 -0400
- 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