W3C home > Mailing lists > Public > www-style@w3.org > June 2009

Re: New work on fonts at W3C

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Wed, 24 Jun 2009 17:40:53 -0400
Message-ID: <7c2a12e20906241440q474a54bauf4a4a9f1b5f7ade5@mail.gmail.com>
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>
Cc: Brad Kemper <brad.kemper@gmail.com>, Jonathan Kew <jonathan@jfkew.plus.com>, www-style@w3.org
On Wed, Jun 24, 2009 at 10:42 AM, Levantovsky,
Vladimir<Vladimir.Levantovsky@monotypeimaging.com> wrote:
> I think we constantly get side-tracked by EOT (and WEFT), although the proposal we have on the table has evolved considerably since then. The options that we are considering are same-origin restriction and a font wrapper that implements simple-obfuscation and targeted font compression (as outlined by http://lists.w3.org/Archives/Public/www-style/2008Nov/0412.html).

Chris Wilson has said that he disagrees with two of the three points
in that post:

On Tue, Jun 23, 2009 at 12:33 PM, Chris
Wilson<Chris.Wilson@microsoft.com> wrote:
> 1. I don't think CORS is a good application here, as it seems much more destructive to workflow than generating EOT files.
> ...
> 3. (linking to "standard" TTF/OTF files)  As previously indicated, I don't see any way to make this palatable (without requiring additional bits in the TTF/OTF that say this usage is allowed, that would not be set in most commercial fonts - e.g. "does not work with any current fonts, freeware fonts would have to be updated.")

Do you even agree with point 3 of the post you link to, that browsers
should support raw TTF/OTF in addition to the obfuscated format?


Anyway.  Let's assume, for a moment, that our main goal is to get one
format that's universally supported by browsers.  There are three
possible routes:

1) Get all vendors to agree on a new format, which is not usable by
any existing browser.

2) Get Microsoft to agree to ship some subset of OTF/TTF (i.e., such
that whatever IE supports the others will support, although perhaps
not conversely).

3) Get the other major browser vendors to agree to ship some subset of
EOT (i.e., such that whatever the other browsers support IE will
support, although perhaps not conversely).

Discussion seems to primarily be focusing on (1) and (2).  However,
these have problems.  (1) requires everyone to agree, which so far has
proven hard.  It also loses all compatibility with old browsers, so
there would be a large window when authors would have to support at
least two font formats.  (2) seems like it's not going to happen,
since if a font file will work with existing non-IE browsers, it will
work on desktops too, and Microsoft appears to be against that.

(3), on the other hand, has two major advantages.  The killer
advantage is that you'll instantly get support from all versions of IE
dating back to IE4 (?), i.e., a majority of the web from day one.
This is vastly more valuable than compatibility with Fx3.5, Safari 3
(4?), etc., for two reasons: IE has a much bigger market share, and it
has a much slower rate of uptake for new versions.  Users of Firefox <
3 are pretty much negligible, and Firefox 3 is barely a year old.  On
the other hand, everyone still has to cater to IE6, and that's almost
eight years old.

The second advantage is that it seems a lot more practical to get all
the non-IE browsers to implement a subset of EOT than to get everyone
to agree on a totally new format, or to get Microsoft to ship some
variant of raw TTF/OTF.  All the objections to EOT look like they're
easily surmountable by just not supporting the features you don't
like.

Specifically, if a browser vendor doesn't like RootStrings, they can
just refuse to process any EOT file with a non-null RootString.  If
they don't like XOR obfuscation, they can refuse to process any EOT
file with XOR obfuscation.  If they don't like MTX compression --
maybe because there's been no official release of the patents yet but
only promises, or because they don't want to bother supporting yet
another compression algorithm -- then they can refuse to process fonts
using MTX compression.

The result would be that there would be some font format that would
work in all browsers.  That format might be, for instance, EOT with no
RootString and no XOR obfuscation, or something like that.  It
wouldn't really matter which browsers chose to implement which
features; authors would just be able to use the intersection of all of
them, so you'd have a single font format regardless.  Of course, if
you really want RootStrings and they don't end up supported, you'll be
unhappy, but I don't think anything will make everyone happy here.

Are there any objections to or comments on this?  Especially from
Firefox/Safari/Chrome/Opera people?  I don't think I've seen anyone
suggesting support for a non-objectionable subset of EOT before, but
it seems to have clear advantages in terms of getting things to
actually work, soon.
Received on Wednesday, 24 June 2009 21:41:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:19 GMT