.webfont Proposal 2

We (Erik van Blokland and myself) have listened to the various  
comments to our initial .webfont proposal[1] and we've rethought some  
things, made adjustments and more. In particular, we were intrigued by  
Bert Bos' suggestion of a compressed directory rather than a single  
XML file[2]. John Daggett's concerns about the file size were also a  
good point[3]. The revised format is now a compressed file containing  
two files with the following names:

	info.xml
	fontdata

The info.xml file contains numerous bits of data describing the font  
data. We looked at various metadata formats and we drew a lot of  
inspiration from the Dublin Core Metadata Initiative[4]. We also spoke  
with some foundries to determine if they would need other fields and  
made adjustments as needed. A quick overview of the fields:

format - This defines the format of the data in the fontdata file.  
Required.
name - The name of the font. Required.
creationdate - The date this particular font file was created. Required.
vendorname - Name of the vendor of the font. Suggested.
vendorurl - URL for the vendor of the font. Suggested.
designcredits - A list of designers of the font. Optional.
license - A license for the font. Optional.
licenseurl - URL to licensing info for the font. Optional.
copyright - A copyright for the font. Optional.
trademark - A trademark for the font. Optional.
allow - A list of URLs allowed to use the font. Optional.
description - Text describing the font. Optional.
privatedata - Arbitrary, private information set by the vendor of the  
font. Font vendors could use this to include any data that they deem  
necessary. Optional.

Many of these fields include data that may already be in the font  
binary. We think it is advantageous to move these out of the binary  
for several reasons: it makes it easier for users and browsers to  
access the data, it makes it very clear what the details of  
the .webfont are since the font file is only one part of the .webfont  
and, since .webfont can support more than one font format, it may be  
necessary if a future format doesn't include this data. Font vendors  
will be able to maintain consistency between the data in the font  
binary and the data in the XML file, so there shouldn't be concerns  
about inconsistencies.

Further details about these elements are in the attached file.

If it would be useful for the browsers to have information about the  
font, we're open to adding data. For example, several font vendors  
thought that adding a list of Unicode ranges covered by the font might  
be useful.

The fontdata file would contain the actual font file. The name does  
not have an extension so that it can be format agnostic. The format of  
the font file is specified by the <format> element in the info.xml  
file. Initially the only supported format would be "opentype". (This  
covers both OTF-CFF and OTF-TTF.)

As stated above, these files would be compressed into a single file.  
We propose .zip as the compression format. If there is another  
compression format that would be easier for the browsers to implement,  
we are open to suggestions. An informal test showed an average 40%  
file size savings over the raw OpenType fonts.

Handling the <allow> element:
In our previous proposal we suggested an unobtrusive alert system that  
would be triggered if the domain being viewed did not match a domain  
in the <allow> element. John Daggett explained that he didn't think  
this would work[5 6]. Instead, he suggested a "page info" window that  
would display data about the page including information defined in the  
font's metadata[3] plus same-site origin restrictions. We are very  
interested in hearing from the browser developers about the  
feasibility of these two ideas.

We're hopeful that this is a good format for everyone. It gives users  
smaller file sizes. It gives the font vendors a simple format that  
allows them to include information about the font. It doesn't require  
entirely new technologies from the browser developers.

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

Tal (and Erik)


[1] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0361.html
[2] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0386.html
[3] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0406.html
[4] http://dublincore.org/documents/dcmi-terms/
[5] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0362.html
[6] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0365.html