Re: .webfont Proposal

Tal Leming wrote:

> We'd love to know what you think.

Very interesting.

What's most interesting to me is that the proposal comes from font 
makers and is nevertheless written in language that programmers understand.

Other interesting aspects:

   - The extensibility: OpenType is not the only format supported. That's
     nice, even if we will probably put in the standard that, for the
     first version at least, OpenType is the only required format and
     everything else is optional.

   - The focus on links to the license and the source: very useful.
     Too many pages and other resources on the Web are not signed, so you
     don't know who to contact with questions, comments or requests for a
     license.

There is a minor issue:

   - It would be good to allow both URLs and patterns, e.g., URLs with
     wildcards or partial URLs, so that a set of related pages,
     including dynamic pages (whose URLs may be partially unpredictable)
     can be specified.

     Maybe even reserve space for other ways than URLs to identify
     documents in a future version: all documents digitally signed by a
     particular person, all documents with a particular digital
     fingerprint (MD5 sum), all documents in a certain format, all
     documents of a certain size, all documents in a certain language...
     (Not sure of the needs, except that it is not urgent, but I'd like
     to not exclude possibilities too early. Of course, these query-based
     identifiers might themselves be defined as new URL schemes...)

And one bigger issue:

   - It is not such a good idea to put binary data inside an XML
     document. XML can only contain valid Unicode characters, even inside
     CDATA. So the binary data will have to be converted to text in some
     way, e.g., to base64. That considerably increases the size (by 1/3,
     in the case of base64).

It's a bit frustrating: the XML-based format makes it *almost* possible 
to write a .webfont file with a simple text editor, except for that 
binary font data...

Maybe an alternative is to keep the XML, but leave out the font data, 
and then put the XML and the font data together in a zip file (or tar, 
jar, mime/multipart, etc.) That zip file then gets the extension 
.webfont. That makes it very similar to EOT or MAME, of course. Which is 
not surprising, as I still haven't heard any better idea than what the 
anonymous inventor of EOT had: OpenType + links back to the documents.


A different subject is the behavior of implementations. That is largely 
independent of the chosen format, and I'm not sure what I want yet.

A mismatched EOT is supposed to be ignored by typical document viewers, 
possibly with an unobtrusive message somewhere for users who want to 
know what resources where actually downloaded. A mismatched webfont, on 
the other hand, should apparently result in a warning message to the 
reader, but the font would be used anyway. As a reader, I think I'd 
prefer EOT's behavior. I don't think I'd want to be confronted with the 
errors of the author, unless I have a special interest. Thus, I'd 
probably prefer it if the viewer just fixed the error for me, i.e., 
ignores the incorrect webfont, and maybe offer an Info command in the 
View menu, where I can find an analysis of the document and its 
constituents...



Bert
-- 
   Bert Bos                                ( W 3 C ) http://www.w3.org/
   http://www.w3.org/people/bos                               W3C/ERCIM
   bert@w3.org                             2004 Rt des Lucioles / BP 93
   +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Thursday, 9 July 2009 13:40:11 UTC