RE: New work on fonts at W3C

Adding www-font@w3.org <mailto:www-font@w3.org>  to the cc: list to transfer the discussion where it belongs …

 

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
Sent: Sunday, June 28, 2009 7:17 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:53 AM, Levantovsky, Vladimir <Vladimir.Levantovsky@monotypeimaging.com> wrote:

   

 From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan

 
 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)


No. sIFR embeds code in the .swf so the hostname of the document is checked on the client.

  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.


Undefined byte padding in the header is itself gratuitious complexity, albeit minimal.

And IE would still process that data, and other browsers won't, which would sow confusion and bugs.

 

If we can agree and decide to standardize on EOT version 1.0, there will be *no* root strings. New tools would emerge to create webfonts, and all browsers would have to deal with the same set of data. Right now, other version (2.1 and 2.2) exist only in the original submission. If the future W3C Recommendation doesn’t mention anything – that would be as if root strings had never happened.

As far as extra padding is concerned – you’ll know exactly where the defined data ends and the difference between this byte count and the (EOTSize – FontDataSize) gives you an offset to the beginning of the FontData – I wouldn’t call a simple subtraction a complexity.

 

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]