Re: .webfont Proposal 2

On the topic of arguments that MIME would be a 
better choice than ZIP for a font file wrapper
format:

On Thu, 2009-07-16 at 16:31 +0200, Laurence Penney wrote:

> 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.

Some examples where zip format is used as a container
format:  KMZ, JAR files (java), and OpenOffice files.

Those all have some interesting aspects in common:
Each is for a problem domain where third party 
extensions to the format are either a low priority
or, by a number of factors, actively discouraged.
Each is for a problem domain where the variety of
tools expected to implement the format is "narrow" - 
is highly specialized.

I would submit that requirements for meta-data around
font files are not and need not be fixed anytime
soon.  It's excellent to have Tal and Erik getting
a list of current desirable meta-data elements from
certain vendors but unrealistic to think we can 
comfortably limit ourselves to that list in the future.
MIME+HTML+RDFa gives us an easy road towards 
upward and downward compatible extensions.

And I would submit that the variety of tools that 
might be expected to implement the new format is 
much larger, which we can again expect to cause
future demand for new extensions, including from
third parties.

I would add that innovation in font representations
(the "payload" portion of these files) is by no
means over, as evidenced by many ideas that have
come up in the course of this discussion.  We
need extensibility of "font payload types" which
Tal and Erik have given us, but without giving us a way 
to maintain the authority list of format names.
MIME, of course, comes with an orderly process for
maintaining that authority list.

Finally, I would point out that we call this
idea simply a "container format for attaching 
meta-data" instead of a "font container format 
for attaching meta-data" we should quickly recognize
that there is no good reason to artificially limit
the format to fonts.  This raises the question of
what authority will maintain the rules for mapping
"files" within the container to their types: again,
a problem for which MIME already has a solution.

-t

Received on Thursday, 16 July 2009 17:31:41 UTC