RE: A way forward

>This is what I mean about legacy behavior limiting the flexibility of a new standard, with EOT-Lite font >vendors can't enforce same-origin restrictions which they seem to be asking for.

I must say, now that FF supports linking to raw font files, it's amazing how you have become an advocate for every font-vendor's wish! But your conclusion doesn't follow from the facts. What the new EOT does is what it does and as long as there is a line to cross between the web font file and the desktop, that seems to have broad support. Whatever the new EOT does, it does. Whatever the new standard does, it does. There is no limitation on "flexibility" - whatever that means - that holds over from one to the other.
As Mozilla has published, there were other considerations involved in enforcing same-origin restrictions. I've never seen the wishes of font-vendors listed as a consideration at all. Can you cite something?
Keep throwing... maybe something will stick.

Regards,

rich

-----Original Message-----
From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of John Daggett
Sent: Friday, July 24, 2009 4:25 PM
To: www-font
Subject: Re: A way forward


Okay, simple example.  One of the things font vendors have asked for
is some form of same-origin restriction to prevent cross-site linking.
So I imagine that EULA's will be written in such a way as to make this
a requirement for usage (e.g. "font may only be used where same-origin
usage is assured").

If the goal of EOT-Lite is to allow a single file to work both in new
versions of non-IE browsers and in old versions of IE, then there's no
way to satisfy this requirement.  If all new versions of non-IE
browsers implement EOT-Lite and same-origin checking then the EOT-Lite
file can't be cross-site linked in non-IE browsers but can be
cross-site linked in IE:

  CSS on bigfamouscompany.com:
  
  @font-face {
    font-family: Pretty Font;
    src: url(fonts/prettyfont.eot); /* EOT-Lite version with null root string */
  }
  
  CSS on mytinylittlesite.com:
  
  @font-face {
    font-family: Pretty Font;
    src: url(http://bigfamouscompany.com/fonts/prettyfont.eot);
  }
  
With a new, distinct format this requirement can be satisfied with a
root string EOT file for older versions of IE and a new format font
for non-IE browsers:

  CSS on bigfamouscompany.com:
  
  @font-face {
    font-family: Pretty Font;
    src: url(fonts/prettyfont.eot); /* EOT version with bigfamouscompany.com root string */
  }
  
  @font-face {
    font-family: Pretty Font;
    src: url(fonts/prettyfont.webfont) format("webfont"); /* IE doesn't understand hints so it throws this rule out */
  }
  
This satisfies the EULA requirement for both new versions of non-IE
browsers and legacy versions of IE.  It won't Akamai-ize well in the
IE case due to the root string but them's the breaks.  When IE
adds support for .webfont this problem will go away.

This is what I mean about legacy behavior limiting the flexibility of
a new standard, with EOT-Lite font vendors can't enforce same-origin
restrictions which they seem to be asking for.

John Daggett
Mozilla Japan

Received on Friday, 24 July 2009 20:49:55 UTC