intertwingly

Raph Levien & David Kuettel: Today we are excited to announce a collection of high quality open source web fonts in the Google Font Directory, and the Google Font API to make them available to everybody on the web.

Thus launched a yak shaving journey.

First stop: the Lobster font, which initially seemed like it would be a delightful replacement for the font used in the header of this page.  Unfortunately, it was too bold.  Literally.  By that I mean that if you start with that font and add font-weight: bold you end up with illegible blocky ink smears.

This lead me to fonteo which hosts the gourmand font which is available in four variants.  I selected this font as it has many of the same visual features as the Georgia font that I use as a fall-back.

Downloading this font gave me a single TrueType file.  A quick trip to font squirrel and I had all of the font formats that any device could truly want.

Adding the following to my css:

@font-face {
  font-family: 'Gourmand';
  src: url('gourmandbolditalic.eot');
  src: url('gourmandbolditalic.woff') format('woff'),
       url('gourmandbolditalic.ttf') format('truetype'),
       url('gourmandbolditalic.svg#webfontRThD2c5z') format('svg');
  font-weight: bold;
  font-style: italic;
}

... and the following to my .htaccess file (to minimize downloads):

<FilesMatch \.(eot|woff|ttf|svg)$>
  ExpiresDefault "access plus 1 year"
</FilesMatch>

And now I’m ready to deploy the font using styles such as:

font-family: Georgia, Gourmand, "New Century Schoolbook", serif;

If the g in the header matches the SVG image on the top right of this post, you are using this font.  It is kinda odd that SVG fonts reverse the image, but that’s easily solved via a transform.

Returning back to Google’s Font Directory, I decided to experiment with Tangerine.  The way they suggest that this be implemented is that each page be modified to add a link tag.  That increases my file sizes and requires an extra server round trip.  Thankfully, Google provides the so-called advanced technique of putting a shorter line directly into your CSS file.

Curious about the content of the files, and how they are served, I took a peek.

HTTP/1.1 200 OK
Content-Type: text/css; charset=UTF-8
Expires: Fri, 21 May 2010 10:57:18 GMT
Date: Fri, 21 May 2010 10:57:18 GMT
Cache-Control: private, max-age=604800
Content-Length: 206
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE

Somehow I get the feeling that Google wants to be notified each time your page is visited.  Curious, I fired up Firebug, and it seems that if a CSS page is served from the cache, the imports referenced by that page are not refetched.  Everybody wins!  Well, everybody except Google, but somehow I expect that they will manage to survive without this crucial piece of data.

As an aside, I was pleased to see that Google is using X-Content-Type-Options: nosniff.  It seems that sometime between Firefox 3.0.1 and 3.6.3, they added support for this header.  Excellent!

Returning back to Tangerine, it too had a problem.  Whereas Gourmand is too bold, Tangerine is too... slight.  I could adjust the font-size to compensate, but that affects fallbacks too.  A way to mitigate this is to only increase the font size if you are hovering over the item.  For extra flair, this can even be animated on webkit.

nav a:hover {
  font-size: xx-large;
  -webkit-transition: font-size 1s;
}

There are two downsides to this.  One that only affects webkit, and one that affects everybody.  On webkit, hovering over the item has the inexplicable and jarring effect of reverting the font back to the default font, executing the animation, and then snapping back to the Tangerine font when done.  Furthmore, they way this this hover effect is employed requires users to obscure what they are trying to read with the mouse cursor.  It turns out that the solution for both is straightforward: make the hover effect apply to the list item instead of the anchor:

nav li:hover {
  font-size: xx-large;
  -webkit-transition: font-size 1s;
}

Why this fixes the Webkit font problem is beyond me.

I'm still not sure that I’m going to keep the use of Tangerine on the article headers.