RE: Web font test cases: file linking vs. data URI embedding, CSS font stack subsets

Monday, October 12, 2009 Adam Twardoch <list.adam@twardoch.com>:

>I have created a few test cases for various techniques used to link or
>embed web fonts in HTML pages:

 >1. linked as one external file (EOT and TTF)
 >2. linked as external subsets (EOT and TTF)
 >3. embedded as one internal data URI (TTF)
 >4. embedded as internal data URI subsets (EOT and TTF)

>The test cases are available at:
>http://www.twardoch.com/webfonts/

Thanks very much for this valuable work, Adam. I'll be linking to it from Readable Web.
Unfortunately, even with IE's known issues taken out of the mix, this first batch of @font-face implementations cannot be labeled, "interoperable and mostly trouble-free".

In my tests, the problem of Page 1, is solved using the following syntax:

@font-face{
font-family: 'CharisSILBlackA';
src: url('CharisSILBlackA-sub.eot');
}
@font-face {
  font-family: 'CharisSILBlackA';
/*Next includes workaround for IE*/
  src: url('//:') format('IE-BLOCKER'), local('CharisSILBlackA'), url('CharisSILBlackA-sub.ttf') format('opentype');
/* Alternative workaround for IE - Paul Irish
src: local('CharisSILBlackA'), local('CharisSILBlackA'), url('CharisSILBlackA-sub.ttf') format('opentype');
*/
}

Two reasons why this smooths out the implementations:

1) As I very, very uncharitably noted in post: http://readableweb.com/opera-admits-font-face-bugs-in-opera-10/
 and post: http://readableweb.com/mo-bulletproofer-font-face-css-syntax/
and as your tests seem to confirm, Opera's implementation behaves buggily in a number of ways. One is that Opera seems to have trouble when the call to the EOT file is listed within a single @font-face declaration. When the EOT is called from its own declaration however, Opera skips over it and that glitch is avoided.

2) The unintended consequence of the first workaround, however, is that IE then has a problem with the second declaration. As was noted on this list by John Daggett on Sept 10:

>IE always tries to pull a font with a URL of *anything* that's between the url left-paren and the last right paren on the line:

  >@font-face {
    >font-family: HavingFunWithIE;
    >src: url(gentium.ttf) my-lord("you have smelly underwear");
  >}
  
>Look in your server logs and you'll find this

>"GET /gentium.ttf)%20my-lord(%22you%20have%20smelly%20underwear%22 HTTP/1.1" 404

Now, there are currently two workarounds for this. My preference is to, first, feed IE a "null" URI and thus avoid the call and resulting 404, and list the rest for Firefox, Safari, Chrome (with web fonts enabled), and even Opera to parse correctly which they seem to do unerringly. The other, developed by Paul Irish, is to likewise fool IE, but to do it using two local descriptors. I have marked this alternate approach within CSS comments. Going that route works fine, too.
(I wrote about and compared the two workarounds on this list Sept. 14)
Also see: http://paulirish.com/2009/bulletproof-font-face-implementation-syntax/
For that and some updated info.

I have one other difference in implementation to report: IE will begin the download of the EOT's immediately upon encountering the @font-face declaration. The other browsers wait. It seems, but I am not yet sure - they wait until encountering an HTML element that is styled with the font. In other words, it isn't downloaded until the browser has confirmed the need for it.
I've asked for confirmation and particulars about this in Firefox from John Daggett.

With this in mind, on to the rest of your test pages...

Regards,

Rich

-----Original Message-----
From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of Adam Twardoch (List)
Sent: Monday, October 12, 2009 5:22 AM
To: www-font@w3.org
Cc: www-font@w3.org
Subject: Web font test cases: file linking vs. data URI embedding, CSS font stack subsets

Guys,

I have created a few test cases for various techniques used to link or
embed web fonts in HTML pages:

 1. linked as one external file (EOT and TTF)
 2. linked as external subsets (EOT and TTF)
 3. embedded as one internal data URI (TTF)
 4. embedded as internal data URI subsets (EOT and TTF)

The test cases are available at:
http://www.twardoch.com/webfonts/

Findings so far:

1. Safari 4 performs well on Mac and Windows with all four test cases.

2. Firefox 3.5 performs fine on Mac and Windows with all four test
cases. However, initially, my test font had a "name" table that was
larger than (I don't remember what...) -- then Firefox on Windows did
not load the font.

3. Internet Explorer 8 on Windows performs fine on cases 1 and 2 but
does not permit data URI embedding even if the subsets are <32 KB (i.e.
test case 4).

4. Opera 10 on Mac and Windows performs fine with test 3, but performs
erratically (sometimes renders, sometimes does not render, sometimes
crashes) on tests 1 and 2, and only renders the first subset from the
CSS font stack in test 4.

I hope you guys will find it useful.

Best,
Adam


-- 

Adam Twardoch
| Language Typography Unicode Fonts OpenType
| twardoch.com | silesian.com | fontlab.net

Reporter: "So what will your trip to Ireland look like?"
Lech Wałęsa: "I get into a car, then onto a plane, and then the other
way around."

Received on Monday, 12 October 2009 19:48:37 UTC