Re: A way forward

On 24 Jul 2009, at 23:12, karsten luecke wrote:

> Dear Mr Fink,
>
>> The same state of ignorance and lack of familiarity
>> exists about the new EOT, as well. It is a
>> very, very recent development. Dimly understood.
>
> the situation is not that bad. After all, Jonathan Kew has posted  
> the ZOT specification on this list and people have read it.  :)
>
>> I believe that if the larger web design community
>> understood that an interoperable solution for Web Fonts
>> could be in hand within 2-3 years, rather than 6-10
>> years, as is the case with the .ZOT proposal, [...]
>
> Whether the format of choice will be EOT Lite or .webfont or ZOT,  
> all of them should be equally simple and fast to implement -- and do  
> not make much of a difference on the font production side. A brief  
> overview (perhaps the links also answer some of Mr O'Callahan's  
> questions):
>
> ZOT:
> http://lists.w3.org/Archives/Public/www-font/2009JulSep/0018.html
> This is literally a compressed TTF/OTF font. OpenType fonts are  
> based on TrueType's sfnt-structure, i.e. organizing data into  
> separate tables: a table for glyphs, a table for font names and  
> other strings, a few tables for general font info, a few tables for  
> layout behavior, perhaps a table for kerning, etc. ZOT splits an  
> OpenType font up into its tables, compresses each table  
> individually, and saves these again in sfnt-like structure.

FYI, I have also written simple functions to encode sfnt to zot, and  
decode zot back to sfnt; we will be happy to make the code available  
freely if anyone is interested. I'm not familiar with all the various  
browser codebases (obviously), but I'd expect that all of them could  
add support for zot fonts in a matter of hours, if the decision were  
taken to do so.

> ..webfont:
> http://lists.w3.org/Archives/Public/www-font/2009JulSep/0548.html
> A .webfont is a zip containing an xml-file containing metadata and a  
> TTF/OTF font file, preceded by a few additional bytes.
> I think Tal or Erik have indicated that they have made tools for this.
>
> EOT:
> http://www.w3.org/Submission/EOT/
> EOT Lite:
> Is basically that, but has an empty "RootString" and font data  
> should neither be compressed nor XOR-encrypted. Ascender's  
> description is here:
> http://blog.fontembedding.com/post/2009/06/29/Revised-Web-Fonts-Proposal.aspx
> This means that an EOT Lite font is a TTF/OTF font whose data is  
> preceded by a few additional metadata.
> A tool is available now as Mr Davis announced on this list.
>
> (My personal opinion: My favorite is .webfont, it is the most  
> straightforward thing to produce and read, and it allows inclusion  
> of any past and future font format. EOT is odd as regards the data  
> structure, yet since what counts is the tiny 'obfuscation' effect  
> that header data has, it does the job. ZOT is tailored around TTF/ 
> OTF font's internal structure which is elegant, but it is too much  
> TTF/OTF-specific and does not account for future font formats.)
>
> The recent arguments against EOT -- especially since teeth have been  
> pulled -- are as hard to understand as why ZOT is brought up again  
> when there is the simpler .webfont.

It's not clear to me that .webfont is "simpler". You can decode zot  
back to usable sfnt data in 100 lines or so of plain C, with no  
dependencies except zlib. OK, extracting a font file from a zip  
archive is presumably slightly simpler, though you'd still need to  
deal with memory allocation, error handling, etc; the difference isn't  
really significant.

As for .webfont, what will browsers be expected (or required) to do  
with the xml metadata? If the answer is that they are allowed to  
ignore it, and simply use the font resource, then it might as well  
contain random gibberish (or nothing at all). And if they are supposed  
to do something specific with it, then it adds a significant burden.  
(And raises further questions to be clarified: how should a browser  
deal with a .webfont where the metadata includes an XML syntax error,  
an undefined entity, or some other glitch? Exactly what errors in  
info.xml should cause a .webfont to be rejected -- and will those  
standards be implemented consistently?)

It seems to me that zot is in some ways the simplest option on the  
table, short of trivial things like a 4-byte prefix in front of the  
sfnt header (which I suspect might be *too* trivial for people who  
like the idea of some kind of obfuscation). It gains simplicity  
precisely because it does *not* try to add anything to the opentype  
font, and therefore questions of how to handle such data (or its  
absence or inconsistency) just don't arise. It is strictly a  
repackaging of opentype data into a form that is more compact than raw  
opentype; that is suitable for selective decoding (e.g., to read  
metadata without decompressing all the glyph data); and incidentally  
provides the "garden fence" between web and desktop fonts that has  
been sought.

JK

Received on Friday, 24 July 2009 23:29:14 UTC