RE: Metadata in WOFF fonts

Erik,

Thank you very much for reviewing the WOFF spec and providing your comments. I would like to respond to some of your observations but I am presenting my personal opinion which may not in any way be considered as a position of the Fonts WG.

It is important to note that WOFF files would reside on a web server along with HTML, CSS and other resources needed to display a content of a website. When an end-user visits the website, his or her user agent software (browser) will get all necessary resources, including the WOFF file(s). As you rightly pointed out, the WOFF file is intended to be a packaging method for fonts (or, in other words, it’s a container for shipping font data over IP) and was never expected to be considered as yet another font format. I believe that the primary purposes of including the metadata in WOFF file is to identify the payload of the WOFF container without requiring a browser to access and parse the font data, and to provide end-users with useful information that would help them identify typefaces used on the web and guide them to a vendor or a distributor where the typeface can be licensed, if desired. Again, it’s important to notice that the information provided by metadata should be easily accessible by a browser without ever looking inside the compressed font data block (similar to a shipping box where proper set of labels may provide information about addressee, sender, weight, replacement cost and handling instructions for the payload without the need to look inside the box).

Once the WOFF file is received by a user agent and its content integrity is verified, the packaged font will be decompressed and restored to its original sfnt-based format. This is the actual font that will be used either directly by user agent or through platform API to render the content of web page. In your example, when printing to PDF a web page that uses downloaded fonts – a software client that creates a PDF will no longer deal with WOFF files – at this point the original fonts have already been unpacked and used for rendering. Font embedding in PDF in this case would be done similarly to what happens in other cases, e.g. when Word documents or PPT slides are converted to PDF.

 As far as the content of metadata is concerned, I agree with you that some of the metadata items may duplicate the information already available from the original font (but again, a browser has no easy way to access it), but there may be many other cases when different information need to be presented. For example, an original font created by an independent type designer may have its own company name and URL listed as vendor information in the ‘name’ table of OT font. However, if that designer has signed a distribution agreement with a web font service or a different font foundry, then it would be beneficial for both the foundry and the original designer to have that foundry or distributor info presented as a vendor information in the WOFF metadata to direct all the licensing inquiries to the right place.

I also agree with you that some of the info present in the WOFF metadata (e.g. credits) may be useful to express in the original OT font, however modifying the original font format is completely out of scope of the W3C WebFonts WG. I agree that the proposal can be made to OT folks to extend the ‘name’ table to accommodate new data or to include another table, but I am actually not sure another table would be necessary. I am also not sure if private data should be anybody’s concern – as the WOFF spec says this block of data is intended to be private, user agents will not need to access it (consider it a bar code that only sender can read) and I don’t see why would OT fonts would even need it – in my opinion it may introduce a whole new set of security issues besides DSIG and font checksums.

Thank you and best regards,
Vlad


From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of Eric Muller
Sent: Tuesday, August 03, 2010 8:53 PM
To: www-font@w3.org
Subject: Metadata in WOFF fonts

I have reviewed the Working Draft 27 July 2010 of WOFF.

I have some concerns about the pieces of metadata which are meaningful for OT fonts in general and not only for WOFF fonts (for example, the licensee or the roles of the contributors). I am absolutely not judging whether those pieces are useful, but I would like to suggest that if they are, then they should be expressible in plain OT fonts, and they don't belong to WOFF.

Viewed another way, these pieces of metadata transforms WOFF from a *packaging method* into a full fledged *font format*. I don't think anybody is going to benefit from yet another font format. There are certainly immediate practical problems: if I print to PDF a web page that uses a WOFF font and embed the font, what I am supposed to do with the metadata? Drop it? But then, what was the point of including it in the first place?

The claim that WOFF does not force anybody to include or use the extra data does not invalidate my concerns.

If it is deemed that the extra data is worth it, then it ought to be a fairly trivial matter to convince the OT folks for the need of a new table to hold Metadata block. The format of that OT table could be exactly that proposed for WOFF.

The same applies to the private data block. There is ought to be as simple as adding to the OT spec something like: "the PRVT table is a block of arbitrary data, allowing font creators to include ...." (i.e. lift the text of section 7).

I understand that adding tables to OT would be a bit more work than just including them in WOFF (e.g. we would need to decide what to do with the font checksum and DSIG), but again, I don't see that as particularly difficult to address.

Thanks,
Eric.