Re: Combining ZOT with .webfont metadata?

Hello Mr Lie and Mr Kew,

(this was first written as a reply to Mr Kew, but now I folded in some points that address Mr Lie's questions:)

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

Most of the .webfont metadata is for information, as described in the proposal, and indeed repeats some information from the name table.
These metadata, font description as well as licensing information, are located in an external xml/text file. This can be accessed and easily read in any text editor, should someone have a peek inside of a .webfont.
If font and licensing information were placed in one of the font tables, as suggested for ZOT, then it would require UAs which are able to read and expose this table's information for a user to see them at all. Effectively, licensing information would be hidden away as is the case with name table entries.
Please decide which line of argument you want to follow: An earlier argument went like, inform rather than enforce. And now you suggest a solution that locks information away. In so far I admit that you follow a clever strategy: First strip down EOT Lite's and .webfont's metadata to being merely informative, thus harmless and superfluous. Then kick it out entirely via ZOT. (Your "what if data in CSS, XML and font differ?" is pointless since XML's data is nothing but informative. Yet I see that it serves to suggest that it is redundant and possible source of contradictions, which helps to argue for kicking these almost human-readable data out.)
No.

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

ZOT is a pretty nice engineering idea, no question. Yesterday I made a little TTF-to-ZOT converter for testing during breakfast. This leaves me with reservations.

EOT Lite and .webfont wrap the complete font. So the UA would (1) unwrap/decompress and (b) continue with a "normal" OTF/TTF.[1] Mr Lie's "new level of indirection" argument is a brilliant joke since:
ZOT (1) tears apart, (2) decompresses each part individually, (3) glues together, (4) use. This is more obvious as you turn from TTF/OTF to TTC. The latter is not even addressed by ZOT yet.

The ZOT proposal does not answer two questions:
-- How will you address TTC fonts?
-- How about non-sfnt fonts?

That ZOT only works with sfnt-structure fonts (TTF/OTF) is a serious issue, even though you try to play it down. It means that via the ZOT format, Mozilla does what free software proponents argue against: Restricting usage via technology. You tell, via this format, foundries which kind of fonts can make web fonts. If new font formats show up, these cannot be converted into a web font, and as Tal already wrote, we would need to discuss another web font format and its support and implementation.

So in sum, I am amused that Mozilla and Opera suggests to
(a)
hide licensing information away in a sfnt-font table which is not easily readable (e.g. with a simple tool like a text editor), whose information are invisible except via UA's UI that does not exist and cannot be guaranteed to exist, and
(b)
suggest a web font format that technically implements restrictions on which format can become a web font.
I would have been less surprised if this suggestion had been made by Microsoft.  :)

Best wishes,
Karsten


[1] Tal or Erik, could you clarify if a UA *must* step through info.xml and its <fontdata> to pick the src/format and then get this file from the package if present?

Received on Sunday, 26 July 2009 12:41:09 UTC