RE: New work on fonts at W3C

Hi Rob, all,

 

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

 

On Fri, Jun 26, 2009 at 4:43 AM, Levantovsky, Vladimir <Vladimir.Levantovsky@monotypeimaging.com> wrote:

 Web authors would have different tools in their possession, and I don’t think that font vendors would insist on having it implemented one particular way vs. another.


That's good.

So authors would have to include rootstrings in their fonts for IE compatibility. But other browsers would ignore the rootstring and let the author control access with same-origin + CORS. That could be confusing for authors, and I'm not sure how font vendors would react to browsers deliberately ignoring rootstrings.

 

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.

 


It seems to me that authors targeting existing IE versions have to use a tool to generate EOT fonts with the right rootstrings, no matter what. That tool could automatically generate fonts conforming to Ascender's proposal (or other possible proposals) at the same time. So if you're stuck with rootstring hassles, then the extra work to generate additional font files is minimal; mostly just adding additional clauses to your @font-face rules.

So it seems to me that eliminating that extra work by supporting EOT in all browsers is not worth it, since we would probably lose the opportunity to converge on something simpler for the long run, like Ascender's proposal. (The MTX issue is orthogonal, given it could be added to Ascender's proposal if wanted.)

 

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.

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.

 

Regards,

Vladimir







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]