RE: WOFF and extended metadata

On Thursday, May 20, 2010 10:31 AM Jonathan Kew wrote:
> 
> 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.
> 

I believe we've already agreed that validation of metadata (whatever that means) is not required, and will only be done when user wants to see the metadata info.

> 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.
> 

Agree, this makes perfect sense. I was surprised to see the connection made between XML metadata and font rendering pipeline in Adam's email, and wanted to make sure that we all in agreement there is no connection between them.

> 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.
> 

I agree that if there is nothing to show, or if metadata is junk, UA should present some kind of error message. How this is done is definitely up to a UA. The critical point that I am trying to make is that in order for user to *be* able to *see* font information UA *must be* able to *show* it. I understand that some UA may not have such a capacity (e.g. printer with no UI), but I believe it is important for the WOFF spec to clearly say what the metadata is for, and what browsers should (must?) do to enable users to see this information, if they so desire.

Now, on technical side of things - I understand the desire to not waste CPU cycles and only parse the data when user actually wants to see it, but I was always under impression that most browsers are already capable of parsing XML and the choice of XML as extended metadata format would not add any complexity to WOFF implementation. 

If this is not the case, I would like to explore the possibility of providing alternative ways of encoding metadata - e.g. as simple HTML in <fontInfoDialog/> element (or whole metadata as pure HTML/CSS content). In this case, for a browser to satisfy user desire to see the metadata it would have to do what it already does best - show the HTML content provided by a font vendor in a separate pop-up window.

Just an idea, fwiw.

Regards,
Vlad

Received on Friday, 21 May 2010 09:32:19 UTC