Phil recently designed Developers Developers Developers Developers, an event we’re running for Boston-area high school and college students:
It looks awesome in part because of liberal use of @font-face.
These days, it’s simple to use @font-face. Just use a stylesheet referencing a web service like Google Font Directory:
<link href='http://fonts.googleapis.com/css?family=Lobster&subset=latin' rel='stylesheet' type='text/css'>
… then use the font as part of a normal CSS font stack:
#schedule .event-time {
font-family: 'Lobster', arial, sans-serif;
}
What if the font isn’t on an @font-face web service
There are plenty of commercial @font-face web services, which Kyle has covered in detail.
However, there are cases where the font you want to use isn’t on an existing service. Or, the font you want to use requires explicit permission from the font’s creator before you can use it.
We ran into this problem on Developers Developers Developers Developers.
First attempt: serve fonts from the app
To solve it, we included the font files in our git repository. This worked, but wasn’t ideal:
- Unnecessarily adds large files to the repo.
- No HTTP caching by default, downloading font files on subsequent requests.
- Repetition. Soon after, I wanted to use League Gothic again on another app.
Second attempt: serve fonts directly from Amazon S3
So our next attempt was to upload the @font-face stylesheet and font files to S3 and serve them directly from there like:
<link href='http://our-bucket.s3.amazonaws.com' type='text/css'>
At first, this seemed to work well. We could set some HTTP headers to handle caching and everything seemed like it was in the right place:
- application code in version control
- assets in an asset host (S3)
However, Firefox (and probably some versions of IE), balks at this technique because of the same origin policy.
On S3, you’re not allowed to tweak the Access-Control-Allow-Origin
HTTP header to allow Firefox to serve your font from S3. There’s a long Amazon
thread where S3
customers are asking for this ability.
However, even if you could set the Access-Control-Allow-Origin header on S3,
you also want the Content-Type, Cache-Control, and Expires to all also be
set in a standard way. It’s a pain to have to do that manually.
Solution: serve fonts from a DIY web service
Our final solution was a small Sinatra app called Fist Face. It is now open source under the MIT License and it solves all the problems we experienced.
Fist Face
It works exactly the same way as Google Font Directory, Typekit, or any other @font-face web service, except that you have full control over it:
<link href='http://your-font-face-service.com/league-gothic.css' rel='stylesheet' type='text/css'>
To use Fist Face, this is all you have to write:
# Gemfile
source 'http://rubygems.org'
gem 'sinatra', '~> 1.1'
gem 'fistface', '~> 1.0'
# config.ru
require 'rubygems'
require 'bundler'
Bundler.require
run FistFace
Then deploy it. Follow a few conventions in the README regarding your asset host (ex: S3) and a few minutes later, you’ll be serving fonts via your own @font-face web service.
Why would I want to do it myself
If you’ve run into the same issues that we did, have you solved this problem differently?
Among the weaknesses of this approach are:
- No CDN. (patches welcome!)
- Up to you to write a decent cross-browser CSS file.
- The font files you use might be old-school (not “hinted” for computer screens).
- Requires deeper knowledge of typefaces.
With an open mind, the last weakness is actually a strength. Typography is pretty interesting. You’ve got all these independent type foundries doing beautiful work and some release their fonts for free under permissive licensing.
In that way, hunting great typefaces for your @font-face web service is like building your own art collection. It can differentiate your work.
