Re: .webfont Proposal

On Jul 9, 2009, at 9:39 AM, Bert Bos wrote:

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

We had this in the early drafts. I took it out because I wasn't sure  
if the wildcards are standardized or not. I'd be more than happy to  
add this.

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

Do you have any suggestions for how this could be done?

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

I see. base64 or something like that would be fine with me.

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

Yes. We went with XML for this very reason. We want it to be as easily  
editable as possible.

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

This is an interesting idea. I suppose that this would still qualify  
as easy to make and edit.

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

We're trying to find some middle ground on this. We don't know how or  
where the browsers would show this. We're really thinking in abstract  
ideas at this point.

Tal

Received on Thursday, 9 July 2009 15:51:23 UTC