- From: Jonathan Kew <jfkthame@googlemail.com>
- Date: Thu, 20 May 2010 15:31:18 +0100
- To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>
- Cc: Adam Langley <agl@google.com>, "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 20 May 2010, at 15:17, Levantovsky, Vladimir wrote: > On Thursday, May 20, 2010 8:26 AM Adam Langley wrote: >> >> If it helps settle the question then I can state that Chrome, for one, >> will never try to drag an XML parser into the font rendering pipeline >> just to validate metadata; irrespective of the spec. >> >> Nor will we accept patches to do so. >> > > 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? It shouldn't. There is no connection. But I think Adam's point is that *IF* there were a requirement to entirely reject WOFF files where the metadata is invalid (or not well-formed, or whatever specific level of "validity" is required....) as has been suggested by some, then a connection would have to be made, because the UA would have to check (validate, whatever) the metadata in order to decide whether to use the font. Just as image viewers can reasonably be expected to display a JPEG even if the EXIF data is junk - provided the file is structurally sound so that the actual image data can be interpreted - so also UAs should proceed to render fonts even if the metadata is junk, provided the file is structurally sound. If the user asks to see "font information", and the metadata turns out to be unparseable junk, it seems reasonable for the UA to present some kind of error message - but still, exactly how this is handled should be left to the implementer's discretion, I think, not legislated in the WOFF spec. JK
Received on Thursday, 20 May 2010 14:31:59 UTC