.webfont Proposal 2.1

This update addresses various comments to our initial .webfont  
proposal [1] and update [2].

In this revision we have:
- Removed the <allow> element.
- Removed the predetermined file name as suggested by Laurence Penney  
[3].
- Defined the User Agent behavior as suggested by John Daggett [4].
- Added references to corresponding OpenType name table fields as  
suggested by Sylvain Galineau [5].
- Made some additional structural changes to the XML data for the  
purpose of simplification.
- Added a new <licenseename> element.
- Added light obfuscation to the file.

In short, the revised format is a compressed file containing two files:

	info.xml
	<arbitrarily named font binary>

An info.xml file is attached. This contains comprehensive information  
about each element along with the expected User Agent behavior. A  
quick overview of the elements:

fontdata - This specifies the font file name, the font format and the  
font name.
creationdate - The date this particular font file was created.
vendor - Information about the vendor. Attributes for name and url.
designer - Information about the designer. Attributes for name, url,  
and role.
license - A license for the font. Attributes for url and id.
licenseename - A name for the licensee of the font.
description - A description of the font.
copyright - A copyright for the font.
trademark - A trademark for the font.
description - Text describing the font.
privatedata - Arbitrary, private information.

As stated above, these files would be compressed into a single file.  
We suggest .zip for this because of its widespread availability.  
Several font vendors and users raised concerns about the security of  
this. They feel that another bulkhead is necessary in light of the  
removal of the <allow> element. Obfuscation has been discussed on this  
list, so we went back to that idea. We propose that .webfont files  
begin with several extra bytes, "webfont", at the beginning of the  
file. User Agents can slice these off and interpret the remaining data  
as a standard zip file.

Regarding inclusion of font meta data in page info and developer tools:
John Daggett suggested a "page info" window that would display data  
about the page including information defined in the font's metadata  
[6]. We support that User Agents include font meta data in UI contexts  
where other page meta data can also be viewed. We understand that not  
all User Agents are capable of displaying page and resource meta data  
and we recognize that it may not be possible to make the display of  
this information a requirement. If that is the case, we would like to  
make it a request rather than a requirement.

Regarding same-origin restrictions and cross origin resource sharing:
FireFox 3.5 currently implements same origin restrictions for fonts.  
CORS [7] would enable servers application to be specifically  
instructed to allow cross origin resource sharing. Our understanding  
is that CORS is set to deny cross origin requests for fonts by  
default. We strongly support this approach and we think it should be a  
requirement for all User Agents and any font format.

Regarding the <licenseename> element:
In our previous proposals we suggested an unobtrusive alert system and  
a page info. Both proposals raised criticism. John Daggett explained  
that he didn't think alerts would work[8 9]. Håkon Wium Lie found  
<allow> too threatening [10]. However, further reduction of licensee  
info (name, url or otherwise) in the font is very difficult, as the  
OpenType specification allows serialised licensee information to be  
present in the name table at ID 11 [11]. This means .webfont, but also  
embedded TTF in EOT and EOT Lite may contain licensee information. Our  
<licenseename> element contains no data that User Agents can be  
expected to act upon. No User Agent action is required for this field.

Regarding the id attribute of the <license> element:
We had requests from several font vendors to add a space for adding an  
id to a font file. As mentioned above, the OpenType name table  
specification mentions the possible inclusion of such data in name  
table at ID 11. Font vendors are already doing this type of tagging in  
other formats, so they want to have it as a possibility in .webfont.

Once again, we'd love to know what you think.

Erik (and Tal)


[1] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0361.html
[2] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0440.html
[3] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0463.html
[4] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0471.html
[5] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0534.html
[6] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0406.html
[7] http://www.w3.org/TR/access-control/
[8] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0362.html
[9] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0365.html
[10] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0517.html
[11] http://www.microsoft.com/Typography/otspec/name.htm
[12] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0519.html