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

Re: the truth which dare not speak it's name

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 8 Jul 2009 08:53:45 -0500
Message-ID: <dd0fbad0907080653v160ca1c8j3e35b0fb3420c60d@mail.gmail.com>
To: John Hudson <tiro@tiro.com>
Cc: Thomas Lord <lord@emf.net>, www-font <www-font@w3.org>
On Wed, Jul 8, 2009 at 12:26 AM, John Hudson<tiro@tiro.com> wrote:
> Thomas Lord wrote:
>> Listen, you goofy boy, everyone you're telling me about
>> can begrudgingly agree to a Recommendation that requires
>> both TTF/OTF AND some variation on EOT-lite.
> They can? Yesterday, you were offering TTF/OTF and 'something else' that was
> an undefined, vapour format. Now that has morphed into 'some variation of
> EOT-lite'?

Well, that's just what a few others (me included) have been saying for
a while.  The "some variation of" part is because there are some
details surrounding exactly what EOT-Lite can mean that are still

> As I said yesterday, if one format is giving away the font, the other format
> would need to be something significantly stronger on protections. Frankly,
> it would need to be strong enough that the browser makers and W3C wouldn't
> want anything to do with it. It isn't EOT-lite.

As you say, though, such a thing can't exist.  It's really not worth
discussing it, then.  Moz has come out *explicitly* against anything
DRM-like (it may violate the law of the GPL, and certainly the spirit,
and may expose them to lawsuits), Hakon has made his position (and
presumably that of Opera) pretty clear, and I suspect that the Webkit
folks would be nearby.  Microsoft has shown in the past that they're
willing to implement DRM in their products, but they're a single

> Again, I think having two formats is stupid and looks like trying to built a
> solution around what different vested interests might possibly, grudgingly
> agree to.

Is this a particular problem?  If one single format can't make
everyone happy, then having two formats (both with interop) is almost
as good.  There's nothing wrong with multiple formats as long as
they're all supported (as has been mentioned before, images are
supported in multiple formats on the web).

> I tend to think that solutions should proceed from understanding
> of problems and goals, and I don't think the problems and goals for fonts on
> the web are understood. As far as I can tell, they haven't even been
> catalogued and described. When I started talking about clients for custom
> fonts and their goals as both font owners and web authors, people reacted
> like this was news and something they had never considered. It shouldn't be
> news and it should have been considered before anyone went blithely into
> supporting a format that is so clearly at odds with the goals of this user
> community.

Speaking purely for myself, the idea that the purchasers of digital
content somehow value the 'exclusivity' of their purchase seems...
strange.  Definitely weirder than the font *creator* being pissed at

In any case, their demands apparently coincide very closely with those
of the foundries, so no harm done.

> Different user communities for web fonts are going to have different goals,
> meaning different fonts, different licensing requirements, and different
> concerns about other people having access to those fonts. I don't think
> creating multiple font formats solves the problems that these differences
> present. It may be solve the differences of opinions and vested interest
> that exist among the browser makers, font vendors and others contributing to
> the standards process, but that shouldn't be confused with solving the
> problems of font use on the web.

Can you elaborate on what you mean here?  Why exactly are multiple
formats, that each offer something appealing to different groups, bad?
 And what possibility are you talking about that solves "the problems
of font use on the web"?  Or, can you explain just what this problem
*is* that isn't solvable with multiple font formats?

Received on Wednesday, 8 July 2009 13:54:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:32 UTC