Re: WebOTF Proposal

Tal, Erik, Jonathan,

This is a very useful development.

After a quick digestion, I suggest four modifications:

1. Add a Version field to indicate in which version of the .webotf  
format the font is encoded.
2. Add an 'id' attribute or element in the <license> element. Of  
course this can be encoded in the private data, but openly identifying  
the contract under which the font is published seems desirable for  
commercially licensed fonts - just as the Ordnance Survey requires  
licensees to note their license number on each map publication.
3. Allow compLength to be *any* number higher than origLength for  
uncompressed tables (e.g. 0xffffffff) to allow slightly faster  
dynamic .webotf generation.
4. Replace the Private Data block with an optional <private> element  
in the metadata, which might contain regular text or base-64 encoded  
blobs (zipped, it won't take up any more space than the existing  
proposal).


The abandonment (compared with .webfont) of format neutrality needs, I  
think, some discussion. Let me kick off.

PRO
A good argument for abandonment is that .webotf is, quite simply, a  
way of packaging OpenType fonts for the web. That's why it  
(deliberately?) does not declare the format of its contents. It will  
be much easier to declare that a UA supports .webotf if the "flavours"  
of .webotf are kept to the minimum, i.e. OpenType/TrueType. If  
implementation of some .webotf flavours were optional, then it would  
be more difficult for foundries to license and for webmasters to  
deploy web fonts. Restricting .webotf to OpenType/TrueType makes it a  
simple bolt-on to an OS's existing font system.

CONTRA
It seems a shame to disallow font formats other than OpenType,  
stifling innovation at a point when innovation may be usefully snuck  
in. For example, would it be possible to allow for Fontlab's PhotoFont  
in a slightly modified format? Multiple files would, at least, need to  
be handled. How easily could this be accomplished? Note that the  
method of using table names to refer to blobs is not far removed from  
using filenames to point to blobs. A fairly simple change to the  
format could facilitate arbitrary filenames:
* Have a new 'strings' part of the file, consisting of concatenated  
null-terminated UTF-8 strings.
* For OpenType fonts, store the 4-character table names in this  
'strings' data block; in the Table directory, instead of the table  
names, store UInt32 byte offsets into the 'strings' data.
* For fonts consisting of multiple files, again use the Table  
directory to point to data blocks, one per file, and use the 'tag' to  
point to a byte offset in the 'strings' data where the filename may be  
found (e.g. uppercase/A.png, uppercase/B.png, lowercase/a.png).

- L

On 6 Aug 2009, at 20:10, Tal Leming wrote:

> We, (Jonathan Kew, Erik van Blokland and myself) have combined our  
> ZOT and .webfont proposals into a new WebOTF proposal. The full  
> specification is attached.
>
> In short:
> - The ZOT compression scheme is retained.
> - The XML data from the .webfont proposal, in a reduced and  
> refactored form, is stored within the WebOTF file.
>
> We are still endorsing the same-origin restrictions and CORS  
> concepts that have been discussed. We are still hopeful that  
> browsers will find ways to display the meta data stored in the font.
>
> We'd love to know what you think.
>
> Tal
>
> <WebOTF format draft.txt>

Received on Friday, 7 August 2009 16:07:43 UTC