Re: .webfont Proposal 2

Tal Leming wrote (15 Jul 2009 13:26:45 -0400):

> The revised format is now a compressed file containing
> two files with the following names:
>
> 	info.xml
> 	fontdata

Thomas Lord wrote (16 July 2009 03:28:19 GMT):

> The extensibility of MIME points out a weakness of
> your file archive proposal:  you are using file names
> "by convention" to assert the type and meaning of the
> components.  The file "info.xml" is supposed to contain
> XML conforming to a specific schema and "fontdata" a
> font.   If later someone wants to generalize your
> idea and extend it for, say, JPG files instead of font
> files they will have to choose some distinct name other
> than "fontdata" yet there is no orderly process in place
> for the allocation of such names.

I was going to make a similar critique. However, I think one file  
named 'by convention' is not a bad idea at all. This is the technique  
used in Google Earth's KMZ format. A KMZ file is a zip file, being a  
wrapper for a 'doc.kml' file (the KML format being XML), which itself  
points to various data files also wrapped in the KMZ.

These data files are located in a directory structure inside the zip  
file. So, a reference to 'images/icon1.png' would locate that image  
file in the images folder within the zip file.

For .webfont purposes, I would prefer to see only 'info.xml' named 'by  
convention'. Font data would be referenced thus:

<fontdata>EdInterlock.otf</fontdata>

This denotes a file, EdInterlock.otf, located at the same root level  
as info.xml

<fontdata>fontdata/times.ttf</fontdata>

This denotes a file, times.ttf, located in a fontdata folder.

This method is more cleanly extensible than a 'by convention' approach  
to data. Consider extensions such as:

* if there were future webfont mechanisms that required multiple files  
per font, e.g. Type 1, Photofont, a bunch of SFP bitmap strikes;
* if it were decided to wrap a whole type family in one .webfont;
* if a single .webfont contained various subsetted versions of the font;
* if a .webfont pointed to a glyph-serving URL (might be nice for  
the .webfont to contain a font with only commonly used glyphs, yet  
including full OT tables, then offer other glyphs on demand).

For the immediate usages of .webfonts, one would probably want to  
block all but local file specifications, i.e. files contained within  
the zip file. (By contrast KMZ allows files to be anywhere, referenced  
by http://... which kinda defeats the purposes of a wrapper!)

I hope it goes without saying that I think Tal & Erik's .webfont  
proposal is extremely interesting.

- L

Received on Thursday, 16 July 2009 14:42:06 UTC