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

On Tue, 2009-07-07 at 22:26 -0700, John Hudson wrote:

> JH

> PS I'm away for the next two days.

For when you return, then.


> 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'?


Yes.  Hey most of the story was true: I really did
whack my head pretty hard on the sidewalk.
The nice recycling scavenger guy did make sure
I would be ok and we did get to chatting.
His swollen face did look worse.  The only fiction
was that he and I didn't actually speak about 
the web font issue.  Maybe I got a mild concussion
or something.


I don't like EOT (with rootstrings enforced) at all.

I don't much like EOT-lite because as a technical
standard it doesn't really add value and breaks
interoperability with desktops.  But wait...

Someone on this list (Chris W. perhaps?) pointed
out that EOT-lite would instantly work with already
deployed versions of IE.  I suspect that EOT-lite
could appear in other browsers very quickly.

That's a pretty compelling degree of interoperability
that can be achieved quickly.

I still also say "and TTF/OTF".  That's because 
TTF/OTF is the preferred format on desktops and
already works with most browsers.   That's also a 
compelling degree of interoperability, already
achieved with all but one browser.

Now, some might be disappointed if they reason
that EOT-lite would quickly be supported everywhere
while it will be years before all users have a 
browser with TTF/OTF support.   They might 
reason that, therefore, EOT-lite will be the de facto
standard for web fonts - nobody will limit their
browser compatibility by using TTF/OTF on the web.
To that I would point out that no standard can
otherwise create any web font format that will be
useful quickly: the choice is EOT-lite or a long delay
before web fonts are useful at all.


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

You acknowledge that "stronger protections" aren't
forthcoming, not least because they are anathema to
Internet standards processes.

I think you are left with the conclusion that if there
are fonts you wish to be "protected" in that sense,
you simply can't permit their use on the web.


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

I think it's a little bit stupid, too, but
compatibility with already deployed versions of
IE makes it a compelling idea.

Sometimes an Internet standard has the job of 
spelling out some new technology.  "Here is what
a DNS server is supposed to do.  Over there is a 
reference implementation."

Other times an Internet standard has the job of
codifying interoperability requirements with already
deployed systems.  "Here is what many browsers
already do.   Here is how to be compatible with those."
This is such a case.


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

I think part of the problem you face with such
arguments is that the issues *are* fairly well 
understood.   The web doesn't have and won't ever
have the kind of "protection" model you seek
so there isn't a lot of point to discussing what
such a protection model would look like in detail.

We're left with the facts that some fonts are
permitted for use on the web and TTF/OTF and 
EOT-lite are the two formats that, today, together,
are sufficient to achieve interoperability with
all existing browsers.

I understand that that answer doesn't satisfy
your concerns.   No possible answer would, though.

A restricted-license custom type design, appearing
on the web, functions by conveying a copy of the font
to a user's computer.  It requires that whoever wrote
the programs the user uses had sufficient technical
information to interpret the data and render the font.
There is then just a choice:  are users free to control
their own computers or are they not?   If they were not,
then "protection" of the sort you call for can be 
present.  In fact, though, users are free to control
their own computers and so such protection is not forthcoming.

In the end I think you have to be satisfied that
some uses of a restricted license font are, in some
jurisdictions, illegal.   If you design a font for
acme.com but then find its unauthorized use in a 
brochure printed up by wile-e-coyote.com, you have a 
cause for action.   This is not so dissimilar from
a situation in which I, say, publish the source code for
a program under the GPL (Gnu General Public License)
and later discover it's unauthorized use in a 
restricted-license program by someone else:  we can't
and don't try to prevent that technologically but
we do wind up with a cause of action.


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


It is not the role of a web font standard to
solve the business model problems of any particular
group.   It is the role of a standard to define a 
font format which all conforming browsers can render.

By way of analogy, consider the TeX language for
typesetting.  The formal definition of the language
is agnostic as to what uses people make of it.
The language lacks "protection" in so far as if I
have a copy of your TeX document, I can certainly
format it and print it - even though to do so might
violate copyright law.

Browsers are rather like TeX processors.  They
implement standard formatting languages.  They can
be used for both lawful and unlawful acts.  We
standardize them and make them because they are 
useful tools.

-t

Received on Wednesday, 8 July 2009 17:10:42 UTC