W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

RE: Use What Is There -

From: Richard Fink <rfink@readableweb.com>
Date: Sat, 25 Jul 2009 23:14:59 -0400
To: 'Håkon Wium Lie' <howcome@opera.com>, "'Tal Leming'" <tal@typesupply.com>
Cc: "'www-font'" <www-font@w3.org>
Message-ID: <000301ca0d9f$438dd450$caa97cf0$@com>
Saturday, July 25, 2009 Håkon Wium Lee <howcome@opera.com>:

Stop trying to move the conversation past the new EOT. (Sorry Tal, but we haven't finished old business yet. And to the extent I can, I will do everything within my power to move back to talking about first things first.)

Your friend Bert Bos has a message for you, Håkon. Just as valid today as it was nine years ago:
(Taken from Bert's paper, Design Guide http://www.w3.org/People/Bos/DesignGuide/use-what-is-there.html)

Use What Is There

Looking back to the first 10 years of the Web, it certainly looks as if there has been a revolution. The Web now runs on HTML, HTTP and URLs, none of which existed before the '90s. But it isn't just because of the quality of these new formats and protocols that the Web took off. In fact, the original HTTP was a worse protocol than, e.g., Gopher or FTP in its capabilities, and HTML back then also wasn't quite what it is now: no embedded images, no tables, no colors...

So in the early days many people had their home pages on FTP servers rather than HTTP servers. And that fact shows nicely what made the Web possible at all: it didn't try to replace things that already worked, it only added new →modules, that fit in the existing infrastructure. HTML can be served by FTP or Gopher servers; browsers can display plain text or FTP directory listings; URLs allow for all kinds of protocols, etc.

And nowadays (the year 2000), it may look like everything is XML and HTTP, but that impression is only because the "old" stuff is so well integrated that you forget about it: there is no replacement for e-mail or Usenet, for JPEG or MPEG, and many other essential parts of the Web.

Of course, technologies may get replaced by better solutions over time. GIF is slowly being replaced by PNG, SMIL replaces several other formats, ditto for SVG. The Web is in constant evolution. There is no "day 0" at which everything starts from scratch. At any time there are old and young technologies working together.

It has to be like that. Technologies improve at different speeds. Trying to release even three or four new specifications in sync is already stretching our capacities. And throwing away software that works, although imperfectly, and teaching everybody something new would be a huge waste of resources."

With this is mind, please answer for me Håkon, why do you persist in ignoring working code and an installed base of hundreds of millions of users? Why is it you prefer, for no good reason, to move the discussion on to something that will produce interoperability 6-10 years hence as opposed to one that will produce it in 2-3?

I await your answer.

Cheers,

Richard Fink

-----Original Message-----
From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of Håkon Wium Lie
Sent: Saturday, July 25, 2009 8:51 PM
To: Tal Leming
Cc: www-font
Subject: 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"/>
    <creationdate>2009-07-13T09:23:30+01:00</creationdate>
  * <vendor name="Font Vendor" url="http://fontvendor.com"/>
  * <designer name="Font Designer" url="http://fontdesigner.com" 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>
    <privatedata>
        <somefield>Some text.</somefield>
    </privatedata>

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

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.

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Sunday, 26 July 2009 03:15:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:03 GMT