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

Re: New work on fonts at W3C

From: Robert O'Callahan <robert@ocallahan.org>
Date: Mon, 29 Jun 2009 10:39:34 +1200
Message-ID: <11e306600906281539t4290517cldd92cfe505d410f8@mail.gmail.com>
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>
Cc: Aryeh Gregor <Simetrical+w3c@gmail.com>, Brad Kemper <brad.kemper@gmail.com>, Jonathan Kew <jonathan@jfkew.plus.com>, www-style@w3.org
On Mon, Jun 29, 2009 at 10:08 AM, Levantovsky, Vladimir <
Vladimir.Levantovsky@monotypeimaging.com> wrote:

> It doesn’t have to be this way. For example, we can agree to only
> standardize support for EOT version 1.0, which has no root strings defined –
> I am pretty sure this would not affect IE backward compatibility (we need to
> confirm this with the IE team). At the same time, we may agree to control
> the access to a linked font on a server side using Referrer value (maybe not
> perfect but workable solution). So, browsers would have no root strings to
> care about, we wouldn’t have to rely on support for same-origin and CORS
> (that is not yet universally implemented) and any possible hiccups with
> Referrer value wouldn’t break anything – if Referrer value is stripped, the
> server would likely not serve a linked font, which would cause UA to render
> a content using a substitute resident font.
>

Referer checking is pretty hard to deploy. I don't think it's viable as a
mass-market solution. We're trying to make Web fonts easier to deploy than
EOT, not harder.

Actually, from a very pragmatic point of view, the support for
> “root-string-less” EOT (version 1.0 only) in all browsers could be both the
> immediate and ‘long-run’ solution you are talking about. It would satisfy
> users who use outdated or newer versions of IE and, at the same time, would
> immediately give web authors full control  using any fonts they like.
>

EOT has gratuitous complexity, like pointless checksumming against
rootstring manipulation. Plus there is the possibility of rootstrings being
present and the fact that some browsers will process them and others won't,
which will always be hurting interop. We can do better.

And, if a browser encounters a website using EOT version 2.1 or later,
> knowing total EOTsize and FontDataSize from EOT header would allow to simply
> skip the certain number of bytes in the end of the EOT header considering
> them just as undefined data.
>

That's still unnecessary complexity.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
Received on Sunday, 28 June 2009 22:40:18 GMT

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