RE: New work on fonts at W3C

 

 

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
Sent: Sunday, June 28, 2009 6:40 PM
To: Levantovsky, Vladimir
Cc: Aryeh Gregor; Brad Kemper; Jonathan Kew; www-style@w3.org
Subject: Re: New work on fonts at W3C

 

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.

But isn’t it similar to what other solutions like sIFR and Flash are doing? (http://wiki.novemberborn.net/sifr/Protecting+Commercial+Fonts)

 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.

If we stick with EOT version 1.0 – there are no root strings to worry about. Consider them (and everything else related to root strings) as undefined byte padding.

Cheers,

Vladimir

 

 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]