Combining ZOT with .webfont metadata

Tal Leming wrote:

 > > I think we could have a compromise worked out over the weekend if font
 > > vendors indicate that ZOT is acceptable.
 > Is .webfont not acceptable to you? If so, why?

First, let's compare the two proposals by asking some questions:

- Builds garden fence?

  Yes, both formats give font vendors the "garden fence" they have been
  asking for.

- Includes root string?

  ZOT: no
  .webfont: not any longer

- Adds new metadata?

  ZOT doens't add any new metadata, it mechanically compresses existing
  font data/metadata

  .webfont adds a 10 or so elements that encode metadata about the font

- Adds new level of indirection?

  ZOT: no, the file referenced by the src font descriptor is fetched,
  decompressed, and handed over to the system

  .webfont: yes, UAs must unzip the file referenced by the 'src' font
  descriptor, look for the info.xml file, parse it, search for the
  <fontdata> element, pick up the filename from the 'src' attribute,
  and hand that file over to the system.

- Adds requirements beyond decoding for UAs?

  ZOT: no

  .webfont: not any more, although UAs are encouraged to show some of
  the metadata

- Can be used with any font format?

  ZOT: no, it's a TT/OT-specific encoding
  .webfont: yes, it can e.g. be used by SVG fonts

>From this, it seems that ZOT is simpler, while .webfont allows font
vendors to express more information. Will this extra information be
useful in any way, or could it possibly be harmful? And, are there any
other ways to express the same information?

Let's look at the elements that are being proposed for .webfont:

  * <fontdata src="demofont-bold.otf" format="opentype" name="Demo Font-Bold"/>
  * <vendor name="Font Vendor" url=""/>
  * <designer name="Font Designer" url="" role="Lead"/>
  * <description>...</description>
  * <license url="vendor.url" id="1234">License text goes here.</license>
    <licenseename>A Font Licensee</licenseename>
  * <copyright>Copyright 2009 Font Vendor.</copyright>
  * <trademark>Demo Font is a trademark of Font Vendor.</trademark>
        <somefield>Some text.</somefield>

A star indicates that the data also exists inside the TT/OT file. So,
most of this information can already be coded into the TT/OT file.
Redundancy is frowned upon in specifications: what do we do if there
is a mismatch? Who is right? .webfont doesn't say anything about this,
but since it doesn't demand any particular behavior from the UA, one
can argue that it shouldn't matter to browsers.

Some of the redundancy is shared with CSS; the @font-face declarations
contain information about the format and the name of the font (to be
used in 'font' and 'font-family'). What if there is a mismatch between
the format declared in @font-face and inside the info.xml? The
.webfont specification should specify who is right.

Three of the elements do not have equivalents in TT/OT: creationdate,
licenseename, and privatedata. The .webfont proposal say that the
creation date should act as a version identifier for the font. I think
it's a poor version identifier. For example, if the time zone is off,
is it still the same version? And, are fonts really created within one
minute? Doesn't it take years and years of efforts?

The licenseename element is probably the most important part of the
proposal. I understand the motivation for having it there.

The privatedata element seems unnecessary, but hardly harmful.

Some of the elements in the info.xml sample file contain HTML markup.
Is this generally allowed? All elements? Including <link> and
<script>, with their obvious security concerns? The proposal doesn't

In sum, it seems that:

 - most of the metadata in .webfont can encoded within TT/OT
 - one should be able to find room for the /new/ metadata inside TT/OT
 - the extra level of indirection also adds overhead, redundancy, and
   security concerns

So, I suggest that one (a) separates the semantics from the syntax in
.webfont, and (b) come up with a proposal on how the semantics can be
encoded within TT/OT. The resulting files can easily be encoded in
ZOT. As such, this combines the best of both proposals.

One remaining argument for keeping the info.xml and its indirection is
that it yields a solution independent of font formats; it can be used
with any new format that may come along, or even an existing one like
SVG. I don't think this is a strong argument. Popular new font formats
don't show up too often. For new formats, the proposed metadata can be
inserted from the beginning. For SVG, one can use namespaces to inject
the metadata straight into the SVG file.


              Håkon Wium Lie                          CTO °þe®ª        

Received on Sunday, 26 July 2009 00:51:29 UTC