Re: WebOTF Proposal

Thanks for the comments, Thomas. A few quick responses:

> Minor concern areas:
> - the details of the metadata content, and any redundancy with current
> or future info in the OpenType 'name' table

Yes, the details are certainly subject to further refinement.

There is some redundancy w.r.t. the 'name' table, which could be  
reduced, but some people seem to prefer making these fields more  
readily accessible without the need to rebuild the actual OpenType  
tables. It may be easier for a vendor to customize fields in the  
metadata block with a separate tool (e.g., to localize the description  
and license information when selling to different markets). The  
intention is that where there is redundancy, the metadata block in the  
WebOTF takes precedence over 'name' table entries.

(It is of course impossible to avoid the risk of future redundancy, as  
anything we define in the WebOTF metadata might someday get added to  
the OpenType 'name' table. So we need to be clear right away which one  
of these is canonical, where both exist.)

> - side effects of stripping the DSIG

This is an unavoidable effect of the repackaging, AFAICT. (Note that  
MTX compression would similarly invalidate any DSIG, I believe. So  
will any font subsetting step that web authors employ.)

If people want to sign WebOTF fonts, it would be straightforward to  
add a new table (wSIG?) for this purpose, but obviously tools would  
need a minor revision in order to support this, and it should be  
specified by someone with much more expertise in the area than I have.  
But it will still be a re-signing process (as it ought to be anyway,  
in order to cover the WebOTF metadata).

> - is one private data block enough? Should there be an arbitrary  
> number?

I don't see a use case for anyone except either the vendor or possibly  
the licensee putting anything in the private block, most likely (I  
guess) for tracking purposes. They are of course free to structure  
that block however they wish, including using a header and a  
collection of sub-blocks if that's useful to them. E.g., a vendor  
could deliver WebOTF fonts with their own private data block, and  
specify that licensees using the fonts on the web have to insert an  
additional per-site record into that block; they could provide a  
simple tool to do so, based on their knowledge of their private block  
format.

(I'm not saying I recommend this scenario, as it adds a significant  
"hassle factor" for users -- if I were the customer, I'd probably  
favor foundries that didn't make such a demand -- just stating the  
possibility. I hope a vendor would think long and hard about the cost/ 
benefit of trying something like this.)

> - could the private data block(s) be used for malicious purposes  
> (malware)?

I don't believe so, because browsers or other consumers won't even  
look at it. Nothing you put in there will affect anything except a  
custom vendor tool that wants to examine and interpret the data. Of  
course, such a tool would be wise to perform validation to protect  
itself against arbitrary data that could be in the block.

JK

Received on Thursday, 6 August 2009 20:52:43 UTC