RE: Webfont compression

Tuesday, July 21, 2009 John Daggett <jdaggett@mozilla.com>:

>Using a form of EOT hamstrings the interoperable use of web fonts in a
>number of ways.  Since no shipping version of IE supports Postscript CFF
>fonts, font vendors with only these fonts in their libraries would be at
>a competitive disadvantage.  Nor does any shipping version of IE support
>simple @font-face rule font descriptors such as font-weight or
>font-style, so using bold and italic faces in IE is awkward.

>I do agree that a simple format that can be implemented quickly is
>ideal.  Better for all browsers, including IE, to make changes so that
>@font-face rules are as consistently interoperable as possible.

John,

I find this extremely unpersuasive. I think it's fair to say it concocts negatives while ignoring the main positive of the new EOT.
Let's take 'em one at a time:

>Since no shipping version of IE supports Postscript CFF
>fonts, font vendors with only these fonts in their libraries would be at
>a competitive disadvantage.

This assumes that there are vendors "with only PS CFF fonts" who wouldn't happily create a TTF version with the click of a mouse in Fontlab if there was a market for it, free or paid. So what competitive disadvantage are you referring to? Which font vendors have expressed this concern to you? And how is it Mozilla's function to stand up for this poor, unfortunate subset of the font industry? Next...

>Nor does any shipping version of IE support
>simple @font-face rule font descriptors such as font-weight or
>font-style, so using bold and italic faces in IE is awkward.

So what? How does that play into the decision? Look, frankly, MSFT should have paid attention to @font-face and cleaned up the syntax to conform with the spec in IE7. We both agree on that score. Still, the implementation mainly works. If it didn't, the guys from Typekit, Kernest, Typotheque, and FontDesk belong in an asylum. And, ironically, it's because of FF's support for @font-face, in other words, your own actions, that EOT is going to be used more and more now than ever before. (Just an interesting observation. Symbiosis.) Next...

>I do agree that a simple format that can be implemented quickly is
>ideal.

The New EOT format is basically simple and it will bring web fonts to more users faster than any other approach. This being what I meant by the main positive of the New EOT.

Now, it has occurred to me that if FireFox were to support the new EOT, you might feel IE was getting a free ride at FF's expense, so to speak. It certainly would stick in MY craw. And this is very legitimate, too - standards are meant to insure a level playing field for all players. And Microsoft's been negligent, no argument. 

That said, I think web fonts are important enough and, I think, enough of a one-off, unique issue, for all the parties involved to look for trade-offs, to keep an open mind, and find a way to provide the public what it deserves.
Given the current chaos required to get a decent cross-browser result, (And IE is NOT the only culprit here. Is everybody bug-free? Is every implementation EXACTLY the same?) surely there's a compromise that can be reached. Surely there can be some creative give and take? I certainly hope so.

Cheers,

rich


-----Original Message-----
From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of John Daggett
Sent: Tuesday, July 21, 2009 3:59 PM
To: www-font
Subject: Re: Webfont compression

> However, having said this - I believe that the major benefit of web
> font initiative would be to come up with a solution that can address
> the largest number of web users in a shortest time possible; a
> solution that would give web authors tools they need today. For this
> reasons - I think that a subset of EOT (either EOT with MTX but
> without root strings, or EOT-lite) would be most pragmatic way to make
> web fonts a web reality today, addressing the large base of IE users.

Any of the solutions that have been proposed (webfont, EOT-Lite, ZOT)
are relatively easy to implement, assuming no DRMish features are
involved.  The MTX compression method would take more time to implement
and verify, since it is a non-standard compression scheme based on new
code (from a non-IE browser perspective).

Using a form of EOT hamstrings the interoperable use of web fonts in a
number of ways.  Since no shipping version of IE supports Postscript CFF
fonts, font vendors with only these fonts in their libraries would be at
a competitive disadvantage.  Nor does any shipping version of IE support
simple @font-face rule font descriptors such as font-weight or
font-style, so using bold and italic faces in IE is awkward.

I do agree that a simple format that can be implemented quickly is
ideal.  Better for all browsers, including IE, to make changes so that
@font-face rules are as consistently interoperable as possible. 

John Daggett
Mozilla Japan

Received on Thursday, 23 July 2009 03:34:25 UTC