Since then, excellent folks like Paul Irish, Jonathan Snook, Ethan Dunham, Zoltan Du Lac, and many others have made a solution possible. Thanks to their efforts, I can rely on my understanding of how to use @font-face to deliver real fonts to every amenable browser.

I have applied this best practice to my Graublau/Lucida and Museo and Sans examples. The Bello and Proxima Nova example, served via Typekit, takes care of itself.

Thanks again to everyone from whom I have learned. Without your ingenuity, hard work, and selfless sharing, I myself would have little to share.

The CSS:

@font-face {
  font-family: "Your typeface";
  src: url("type/filename.eot");
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename.woff") format("woff"),
    url("type/filename.otf") format("opentype"),
    url("type/filename.svg#filename") format("svg");
  }
@font-face {
  font-family: "Your italic typeface";
  src: url("type/filename-ital.eot");
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename-ital.woff") format("woff"),
    url("type/filename-ital.otf") format("opentype"),
    url("type/filename-ital.svg#filename-ital") format("svg");
  }
h2 { font-family: "Your typeface", Georgia, serif; }
h2 em { font-family: "Your italic typeface", Georgia, serif; }
em { font-style: italic; }

The HTML:

<h2>This headline is typeset in <em>your typeface</em>.</h2>

Before we get started

If you want to brush up history and basics, Håkon Wium Lie has a great introduction to the CSS @font-face property in his A List Apart article, CSS @ Ten: The Next Big Thing. And as always, there are the getting started resources here at Nice Web Type.

Acquire a typeface

You may have a typeface in mind, or you may have no idea where to begin. Either way, read my post about Where to get web fonts. The type you already have may not be licensed right, and whether you’re looking to buy or seeking free fonts, you’ll want to know all of your options.

I have also experimented with several properly-licensed typefaces in a series I call Nice Web Type Likes, providing bits of advice with each example and explaining what I feel are each typeface’s merits.

For this demonstration I’ll use Fontin Sans from Exljbris. If you use it in your example, don’t forget to provide this line of attribution just above your @font-face declaration in the CSS:

/* A font by Jos Buivenga (exljbris) -> www.exljbris.nl */

Go grab a properly licensed typeface, then continue reading here.

Use several font formats

Once you have acquired a typeface, you’ll need to do one more thing: make alternate versions for broader browser support.

Most likely, the typeface you want to use is in one of the following formats: OpenType (OTF) or TrueType (TTF). However, Internet Explorer will only use Embedded OpenType, a format Microsoft has championed for years with little success. And on top of that, other browsers will only use Scalable Vector Graphics (SVG) fonts.

Lucky for us, creating alternate font files is much easier than it once was thanks to the generous genius of folks like Jonathan Snook and Font Squirrel’s Ethan Dunham.

Jonathan has published two excellent resources: a screencast that explains converting OTF or TTF to EOT, and a blog post that explains how to generate Scalable Vector Graphics (SVG) fonts using a command-line tool called Batik.

Font Squirrel offers an automated way to arrive at the same array of font formats: its excellent @font-face kit generator.

This small, free web utility lets you upload a properly licensed typeface, then gives back the same typeface in many formats—plus some demo HTML/CSS files that show the font in action.

Worth noting: one of the generated formats is Web Open Font Format (WOFF), a proposed standard format for web-licensed typefaces. Including WOFF in our @font-face declarations now is a wise thing to do. Progressive enhancement, as they say.

Above, the files I received after having put Fontin Sans Regular and Fontin Sans Italic through Font Squirrel’s generator. Looking good.

Tools vs. “from scratch”

Whether to rely on handy services like Font Squirrel’s generator or roll our own solutions with guidance from smart folks like Snook? We’ll be faced with this decision until using real type in websites is as easy as, say, using images in websites.

As long as we understand how things work, and as long as we know what exactly our handy tools are generating, there’s no shame in using tools that make life easier. In fact, it’s just plain resourceful.

Get yourself organized

Having created versions of your typeface in a few different formats, make a few files and folders just for this tutorial. We’ll proceed as if your project is organized like so:

/My project
  /css
    /style.css
    /type
      /filename.eot
      /filename.otf
      /filename.svg
      /filename.woff
      /filename-ital.eot
      /filename-ital.otf
      /filename-ital.svg
      /filename-ital.woff
  /index.html

Make index.html really simple, like this (line wraps marked »):

<!DOCTYPE html>
<html>
<head>
  <title>Practicing @font-face</title>
  <link href="css/style.css" media="all" rel="stylesheet" »
      type="text/css" />
</head>
<body>
  <h2>This headline is typeset in <em>your typeface</em>.</h2>
</body>
</html>

Get down to business

Now let’s go through the CSS line-by-line and bookmark several excellent reference materials that explain the details thoroughly.

First of all, you may notice that this entire setup looks a little bulky. This is because we’re trying to reach (and avoid tripping up) as many browsers as possible. Go ahead and open up style.css.

Name that typeface

@font-face {
  font-family: "Your typeface";
  src: url("type/filename.eot");
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename.woff") format("woff"),
    url("type/filename.otf") format("opentype"),
    url("type/filename.svg#filename") format("svg");
  }
@font-face {
  font-family: "Your italic typeface";
  src: url("type/filename-ital.eot");
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename-ital.woff") format("woff"),
    url("type/filename-ital.otf") format("opentype"),
    url("type/filename-ital.svg#filename-ital") format("svg");
  }
h2 { font-family: "Your typeface", Georgia, serif; }
h2 em { font-family: "Your italic typeface", Georgia, serif; }
em { font-style: italic; }

Highlighted above are the font-family properties within our @font-face declarations, and matching names within our font stacks. These arbitrary names tie information about our typefaces (file names, formats, locations) to our font stacks, because we use the same name in both places.

Source sauce

@font-face {
  font-family: "Your typeface";
  src: url("type/filename.eot");
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename.woff") format("woff"),
    url("type/filename.otf") format("opentype"),
    url("type/filename.svg#filename") format("svg");
  }
@font-face {
  font-family: "Your italic typeface";
  src: url("type/filename-ital.eot");
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename-ital.woff") format("woff"),
    url("type/filename-ital.otf") format("opentype"),
    url("type/filename-ital.svg#filename-ital") format("svg");
  }

Highlighted above are the EOT versions of our typefaces which must be summoned first, via a separate src property than the others, for reasons Paul Irish explains in painstaking detail.

To paraphrase Paul’s explanation, the logic goes something like this. If a non-EOT file comes first, IE will load the non-EOT file even though it cannot be used, wasting bandwidth and time. Then, IE will choke on the format("whatever") part of the value and ignore the rest of the entire declaration.

All we need to do is put the EOT value first, right?

Not quite. Naturally, as per the CSS cascade, the declaration’s final src property takes precedence. So even though EOT comes first, IE still chokes. Internet Explorer, you magnificent bastard.

So what Paul has devised is a method of intercepting IE before it arrives at “problematic” formats. Using the best kind of CSS hack (one with no meaningless syntax), he diverts IE before it wastes bandwidth grabbing an unnecessary file—and before it chokes.

Think local, act local

@font-face {
  font-family: "Your typeface";
  src: url("type/filename.eot");
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename.woff") format("woff"),
    url("type/filename.otf") format("opentype"),
    url("type/filename.svg#filename") format("svg");
  }
@font-face {
  font-family: "Your italic typeface";
  src: url("type/filename-ital.eot");
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename-ital.woff") format("woff"),
    url("type/filename-ital.otf") format("opentype"),
    url("type/filename-ital.svg#filename-ital") format("svg");
  }

What Paul figured out is that IE chokes on not only local values, but multiple values of any kind within in a single src property.

Following Paul’s advice, our declaration’s final src property features a comma-separated list of values. In browsers other than IE, this series of values attempts to summon the typeface of your choice in several different ways, settling on whichever one works first (and skipping the rest).

Internet Explorer skips this whole line and sticks with the EOT file it has already loaded via our previous src property.

The local values tell browsers to check for your typeface on a visitor’s computer before attempting to load it from afar. Why have two when one will do? As Paul articulates, it’s because some browsers refer to full font names and other browsers to fonts’ PostScript names. John Daggett has tips on how to find these (scroll down to just below “Suffering succotash!”).

Our next three src values offer up WOFF, OTF, and SVG versions of your typeface. They’re listed in this order so that WOFF, and then OTF, take precedence.

Note that paths to SVG files include an ID. Here, #filename. If you convert your own SVG fonts, you define this value. If you use Font Squirrel’s generator, look at the demo CSS to find this value (for Fontin Sans Regular, I see this SVG ID: FontinSans-Regular).

And with that, you’re done. Preview index.html in a browser and see what you’ve got. Here’s my example using Fontin Sans.

Now don’t get too excited yet. There are some things left to consider, including browser support. Let’s keep talking about this while you still have the files open and are in the zone.

It takes two, baby

One of the most bothersome (but necessary) aspects of the syntax we’re using is that we define the roman and italic versions of our typeface as, technically, two different typefaces when they are actually two different styles of the same typeface.

@font-face {
  font-family: "Your typeface";
  src: url("type/filename.eot");
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename.woff") format("woff"),
    url("type/filename.otf") format("opentype"),
    url("type/filename.svg#filename") format("svg");
  }
@font-face {
  font-family: "Your italic typeface";
  src: url("type/filename-ital.eot");
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename-ital.woff") format("woff"),
    url("type/filename-ital.otf") format("opentype"),
    url("type/filename-ital.svg#filename-ital") format("svg");
  }
h2 { font-family: "Your typeface", Georgia, serif; }
h2 em { font-family: "Your italic typeface", Georgia, serif; }
em { font-style: italic; }

Above is our code. Below, see how it might look with “style linking,” a way of tying @font-face declarations to one another, and to font-style properties, similar to the way we connected values via font-family earlier in this tutorial.

@font-face {
  font-family: "Your typeface";
  src: url(type/filename.eot);
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename.woff") format("woff"),
    url(type/filename.otf) format("opentype"),
    url("type/filename.svg#filename") format("svg");
  }
@font-face {
  font-family: "Your typeface";
  font-style: italic;
  src: url(type/filename-ital.eot);
  src: local("Alternate name"), local("Alternatename"),
    url("type/filename-ital.woff") format("woff"),
    url(type/filename-ital.otf) format("opentype"),
    url("type/filename-ital.svg#filename-ital") format("svg");
  }
h2 { font-family: "Your typeface", Georgia, serif; }
em { font-style: italic; }

See what changed? Instead of specifying a separate font-family name for the typeface’s italic style, we use the same name and connect it to the regular style via font-style style linking.

As a result, we no longer have to specify that em tags within h2 tags should use the italic typeface; by virtue of style linking and CSS inheritance combined, em tags behave as we would expect.

The reason we can’t use this more logical syntax today is because Internet Explorer will ignore it. None of our text would be italicized in IE. Also, Opera would look all messed up.

Browser support

There’s browser support, and then there’s browser support. So far we’ve channeled our inner Paul Irish just to get real type working in browsers that support @font-face!

What about browsers that don’t support it at all? What about older browsers, or some mobile browsers? Well, as per our CSS font stacks, such browsers would see Georgia. Or if they didn’t have Georgia, they’d see a default serifed typeface:

h2 { font-family: "Your typeface", Georgia, serif; }
h2 em { font-family: "Your italic typeface", Georgia, serif; }

Good enough?

If not, and if you would still like to use @font-face where it works, you might try isFontFaceSupported, a bit of JavaScript (again from Paul Irish—this guy is awesome) that checks for browser support. This kind of detection is also available in Modernizr, a JavaScript library from Faruk Ates that checks for all sorts of new features.

If you decide that font stacks are good enough, my Roundup: CSS font stacks post from April may be of interest to you. And although these are not perfect, in their Likes examples I suggest Helvetica to understudy Museo and Museo Sans, and a Lucida Sans stack to understudy Graublau Sans. Crud mitigation.

If you feel zen enough for font stacks but you want to provide slightly different typesetting instructions depending on typeface availability, see Matt Wiebe’s links near the end of our chat.

Optimization

Arguably part of browser support are subtleties like typeface file compression, flashes of unstyled text (FOUT) in some browsers and, in other browsers, @font-face only working if typeface files live at the domain where they’ll be used. I believe these have more to do with general web logic. Same goes for using @font-face with theme customization via services like Wordpress and Tumblr.

Such nuanced issues have everything to do with how files are transmitted and parsed, and they deserve a comprehensive post. Until I have such a post to share, here are some links:

Cross-Origin Resource Sharing

“Firefox 3.5 has set a precedent: it only fetches your web fonts, when linked from other sites, if you have expressly set your server to allow it.” This page from the Open Font Library explains how to set your server to allow it, via .htaccess, either in general or on a per-site basis.

Fighting the @font-face FOUT

Solutions from Paul Irish that tell Gecko and Opera to give font files high priority upon page load.

Steve Souders on @font-face and Performance

Steve Souders details the myriad performance issues and usability hurdles incurred by pages that use @font-face, then recommends a solution he calls, “Lazy Load.”

Gzip your @font-face files

Among the stats, bits of advice: “Always send your font files gzipped” and “keep an eye on the font file sizes you’re about to use, they can be huge.”

@font-face gzipping – take II

Stoyan Stefanov: “Basically, the tests confirm that WOFF is already compressed, it doesn’t need to be gzipped by the server and woff file sizes is comparable to the compressed TTF or OTF.”

Rendering Fonts in Today’s Browsers

Ryan Carver: “We recently rolled out an upgrade to that Javascript which improved compatibility, rendering perception and reduced the file size tenfold. There’s more to come – for example, we’re adding hooks which tell you when the fonts have loaded.”

The spec, the future

There are all kinds of @font-face goodies on our horizon, and it’s all because of forward-thinking people who make browsers, sell type, and care about design. Progress amid changing business.

CSS Fonts Module Level 3

The official W3C Editor’s Draft.

WOFF in Firefox 3.6

John Daggett of Mozilla announces upcoming WOFF support in Firefox and details differences between WOFF and TTF/OTF, with great examples.

New font control features for designers

Editable via CSS – OpenType features like discretionary ligatures, alternate glyphs, tabular figures, fractions, and language sensitivity. Mozilla’s John Daggett and Jonathan Kew are planning to extend the CSS font-variant property, beginning in Firefox 3.7.

Keeping up

Thanks for reading. One final note: stay abreast of web typography links like the ones cited here with Nice Web Type’s bookmarks. Also on the homepage and in the iPhone-friendly stream.

One more thing

Much respect for Jon Tan’s excellent post, Making Web Fonts Work. Published 364 days ago, this investigative, ahead-of-its-time post got lots of people thinking realistically about web fonts. Now Jon’s prescience fuels Fontdeck—can’t wait to see it.

This year on Twitter, following @Typographica has yielded thoughtful criticism of @font-face examples as well as crystal clear mini-reports (often in the form of OH quotes, and with emphasis on web fonts) from type conferences like TypeCon and ATypI.

Follow. Subscribe. You may also enjoy my Typesites review of Typographica from earlier this year.

1. Matt: Check out http://thatwasnotok.com for a fun use of font embedding with Chunk.
2. Tim: Nice! Does Chunk lack proper apostrophe characters, or did primes just look better?

1. Matt: Thanks! Chunk unfortunately lacks a lot of glyphs, including apostrophes, smart quotes, and an ampersand.
2. Tim: What if you didn’t have an alternative (like if you needed an ampersand)? Would you substitute one from another typeface? Which typeface?
3. Matt:

   I knew up front that Chunk was lacking an ampersand, so I already had that in mind while writing copy. I also knew at the outset that the site would be small, so I wouldn’t need a versatile typeface with wide glyph support.

   I briefly tried substituting an apostrophe from Impact (as it’s 1. widely available on user’s computers and 2. similar in weight) but it looked really bad. At this point I decided that I didn’t mind.

4. Tim: And I see you’re span-kerning—thoughts on that?

1. Matt: It was the only way to get the effect I wanted. Wish I could do without them.
2. Tim:

   The problem I can imagine is that if some browsers don’t recognize @font-face, your stack understudies won’t take exactly the same kerning and might look oddly spaced.

   I know there are solutions for conditional CSS (if this font is available, do this, otherwise, do that)—do you remember hearing about this kind of thing? Might allow for different sets of “kerning” instructions.

3. Matt:

   You’re right about there being some issues with how the fallback font looks. As you suggest there’s a couple of potential strategies involving jquery plugins.

   1. Use http://code.google.com/p/jquery-fontavailable/ to check for your font, and then set something like class="chunk-available" on the body element. Use styles accordingly. I’d actually be more inclined to set class="chunk-unavailable" at this point. I’ll probably do this, as the kerning looks pretty crappy with Impact, the fallback font. I can also…

   2. Use http://github.com/philoye/fontunstack for more fine-grained control. It’s really doing the same thing as above, but with a whole font stack. Although the documentation suggests targeting specific elements, I’d just set it on the body if there was only one custom font to worry about but I still had a font stack with a few options. This is definitely the better option if you’re embedding more than one font face in a document.

   Now, I think I have to go and sort out the kerning for non-font-face browsers. It’s gonna bug me.

Let’s revisit WOFF, talk about EULAs, and list some places to find typefaces that are legal for use with the CSS @font-face property, including type delivery services, free font libraries, and curated lists of fonts available for web linking.

Moochers, go ahead and skip to the part about free fonts.

WOFF, the web standard for type

I wrote about the type selling business back in July, and not much has changed. What was called .webfont/WebOTF is now WOFF (Web Open Font Format). Foundries, browsers, and services have shown support for this emerging standard, and support will continue to grow (just today, Mozilla and others publicly expressed such support).

WOFF files include license-related XML data that can help type sellers enforce the legal use of their typefaces. So as WOFF is supported, we’ll be able to license type as we have done for years. Type sellers will happily hand us ordinary font files because if they fall into the wrong hands, or are used in a way that violates the license terms, it will be evident.

We’ll have a mixed bag of solutions, though, until WOFF gains more browser support and typefaces are produced and licensed in WOFF format.

But whether now or later, WOFF or not, the universal answer to our question, “Where do I get web fonts?” is: depends on the EULAs.

EULAs have the answers

What you want is a typeface that explicitly allows, in its End User License Agreement (EULA), linking with the CSS @font-face property. This is sometimes referred to as embedding, which can be confusing because type sellers have for years referred to PDF embedding in their EULAs, and distinctions aren’t always clear. Some smart folks offer clarification in articulate, easy-to-find ways. I like Mota Italic’s EULA and this FAQ from H&F-J.

If you can’t find licensing information, contact the seller and ask for details. Or, just go elsewhere. If details about where and how a typeface can be used are hard to find, that’s the type seller’s problem. Maybe in bygone years, when foundries sold to fewer design professionals, squirreling this information away within legalese, or within a clunky site, was acceptable. But now, licensing nuance should be easy like Sunday morning.

Have you seen clear, understandable type licensing information somewhere? Link it up in the comments so we can collect good examples.

Lists of fonts you can use

One step removed from EULAs are lists of “fonts available for use with @font-face.” These attempt to save you the trouble of referencing EULAs, but they’re only as reliable and organized as the people maintaining them. I know of only one good reference, and even so I see something missing.

As of this writing, the Fonts available for @font-face embedding wiki page at webfonts.info was last updated on August 18, 2009 and does not include web fonts from Mota Italic (which I know should be there, from having seen their aforementioned EULA).

I realize I could have added Mota Italic typefaces to the webfonts.info wiki myself in less time than it took to write this, but you see my point. Wonderful as Ralf’s resource is, and as similar community-managed resources are, there’s always a delay.

(Sorry Ralf! Just using you as an example here. Love the site, and I constantly reference the wiki. More on that in an upcoming post about how to use @font-face.)

Another thing to consider: the typefaces listed come from a variety of distributors and are not all free; browsing among sites with very different structures, especially without a direct link to licensing information that may be deeply nested, can be a hassle. Type delivery services and websites that offer free fonts have a distinct advantage in this regard, because you know exactly what you’re getting. Nothing you see is off-limits.

Free and freely licensed

Here are some typefaces you can use right now. They’re licensed for use with @font-face and they don’t cost anything. Someday I’ll explain why I prefer to pay for typefaces (it’s not just because I think type designers deserve to be paid), but go ahead. Go nuts. Free fonts! Woooo! Also: you may be disappointed.

The League of Movable Type

“Everyone is welcome to browse, download, and use our collection of hand-picked typefaces. In the spirit of sharing, all fonts made available by The League are subject to SIL’s Open Font License.”

I’ve used League Gothic, a revival of Alternate Gothic, and it sets nicely. For each of the typefaces offered, The League provides a “download” button; sometimes clicking this yields a single OTF file, and other times you receive a variety of files.

Font Squirrel

“This page showcases all the fonts that Font Squirrel offers for use with @font-face CSS embedding. Though we try very hard to verify compliance with license agreements, please read them yourself before using.”

Font Squirrel offers an impressive quantity of type, makes it dead simple to pick one out, and handily offers “kits” – the typeface of your choice, in several formats, packaged with demo HTML & CSS that uses very current @font-face syntax.

They also offer a way to make your own @font-face kits. If the typeface you want to use has been licensed appropriately (the ones that come with your computer are not necessarily okay), the generator produces EOT, SVG, and hey! WOFF files.

Type delivery services

Presently, type delivery services have one or two advantages over lists of fonts and freebie sites: real fonts and fewer headaches.

There are technical reasons why a new font format is being developed: WOFF offers file size advantages and a platform for license enforcement. There are also reasons why it’s hard to pinpoint a straight answer about how to use @font-face: browser support is in flux, and smart folks continue to fine-tune syntax as they learn and experiment.

Type delivery services work to address all of these issues at once, adapting as conditions change. Even today, before a web type standard has truly been established—they protect the typefaces they serve, alleviating some concerns about license enforcement, and they compress, optimize, and serve files in multiple font formats (OTF, EOT, SVG, WOFF) to achieve the broadest possible browser support.

As a result, some type sellers feel safe putting real fonts in the hands of web designers who use these delivery services.

Plus, because these services constantly monitor the state of web fonts and are paid to make sure type is delivered in the best possible way, folks who pay to have their type delivered needn’t worry about the technicalities. Fewer headaches. Not to mention that these services, particularly Typekit, make browsing for type a simple and enjoyable experience.

Typekit

Currently available by invitation only, Typekit has been in “technology preview” mode for several months. The folks behind the service communicate clearly and thoroughly about issues like serving and protecting fonts and have expressed public support for .webfont/WOFF. The service performs gracefully, is beautifully designed, and was well received by Andy Clarke.

Typotheque

Type foundry Typotheque offers its wares, licensed for print, web, or both, and serves type via its publicly available web fonts system. Typotheque has also expressed support for WOFF, and has, like Typekit, been well received by Andy Clarke.

Kernest

The first publicly available type delivery service, and the first type delivery service to serve WOFF files, Kernest seems always to be in the game. For what it’s worth, Kernest was not well received by Andy Clarke. What malarkey.

Where to get web fonts

So now you know.

We’ve talked about a web standard for typefaces, noted the importance of EULAs, and compared/contrasted the ideas of type delivery services, free font libraries, and lists of fonts available for web linking. While the details and players may change, these are concepts you can rely on for some context. Happy hunting.

In college, I was an undeclared major for the first two years. I took the liberal arts base, scanning the course catalog for ways to fulfill those requirements and learn what seemed most interesting. So I found myself in advertising courses, marketing courses, and any course I could find with a literary spin. I read a lot, wrote a lot, and used Microsoft Word a lot.

Ugh. What a ridiculous pain it was. Changing the margins of a document was always a gamble, because on each side there were three or so things to adjust, and I never chose the correct one, or I could never get them aligned again. Using tables or images created odd gaps. Paragraphs and bulleted lists always tried to guess at what I wanted. Stuff was shifting around haphazardly.

Some programs have a snap feature. Word had snap-to-ugly.

It was as if the document was fighting against me. Messing with my mind. It could adjust itself in an infinite number of clunky and garish ways, as if that should satisfy me.

I could not understand why it was so complicated, or why I had never heard of a simpler, friendlier competitor. Spacing, alignment, and indentation were fundamental issues, I thought. There’s got to be a better way.

For me, the better way was graphic design.

I wonder if Word is similarly frustrating these days, or whether it is easier for folks to find an alternative. And if there isn’t any reason to be dissatisfied with one’s page layout program, I wonder what’s prompting kids these days to seek a better way.

Being able to typeset OS-X-quality text for CSS image replacement is fantastic (you don’t need me to explain this if you’ve ever tried to decide among sharp, crisp, and smooth antialiasing options in Photoshop); however, command-line typesetting isn’t something designers will jump up and down about. Unless….

My people take care of that

What if type delivery services were to offer such high-quality, rasterized images of type? What if, say, Typekit knew the size at which I intended to use a typeface, and the color I wanted to use—how difficult would it be to run something like Textorize as an automatic part of serving the type?

If it’s feasible, this could mean that a visitor whose browser does not support @font-face linking, and who may be using Windows or Linux, would see the typeface I want them to see with quality equivalent to OS X.

Given the alternatives of serving visitors a font stack understudy, something plugin-dependent like sIFR, or a scripted solution like Cufon that some type sellers won’t abide, I can see how a sort of hands-free Textorize might be appealing.

Heh. A service would also need the actual text I intended to typeset, at which point we’re talking about a different service model. Hmm.

This is a web standard for typefaces. In a nutshell, it explains that a WOFF font file is “simply a repackaged version” of font files like TrueType, OpenType, and Open Font Format, compressed and designed primarily for use on the web.

WOFF files would consist of two basic parts: typeface data and XML-based metadata. Most of the proposed specification explains the guidelines by which this information should be organized, compressed, uncompressed, and reorganized.

Worth noting is that this proposal is concise, focusing on the integrity of font data and clarifying that special features are outside of its scope.

WOFF encoding tools (and web services that produce WOFF files) may add features like glyph subsetting and validation but, “must assure that the validity of the underlying font data is preserved.” Presumably, tools and services of a different scope may reference the XML portion of WOFF files for license enforcement.

Judging by the wisdom evident in this proposal and the reception its predecessor enjoyed, I believe this is the font format future to which we can look forward.

To all of my readers, followers, and advocates: Thanks! Your interest has helped put Nice Web Type on the map.

And one more quick shout to Smashing Magazine for including me in lists like July’s 50 New Beautiful Blog Designs. “Top # list” posts like this get lots of grief for their formulaic aspects, but they are successful in getting people to visit websites they otherwise might not. I appreciate the attention.

Regarding numbers two and three, I read everyone I follow, and I only post if I have a good, on-topic reason. (The rolling articulation of what constitutes “on-topic” is a constant challenge.)

But as for number one, here’s how I balance original content, found goodness, and other things I think are worth your time.

Multi-grain, heart healthy

Notes (blog posts), Delicious bookmarks, Flickr group screenshots, and Twitter favorites are the foundation of what I share. In that order, they range from original content to curated filtration. Each of these things can be subscribed to or visited independently (here are the RSS feeds: Notes, bookmarks, screenshots, favorites).

Now try some of this

Nice Web Type’s Twitter stream is for directing traffic, and also for things that don’t happen anywhere else:

• When I write a new Note, I tell Twitter followers. (These same folks might subscribe to the RSS, but knowing immediately when I press “publish” is a bonus.)
• When I collect enough bookmarks, favorites, or screenshots to warrant a visit’s time, I tell Twitter followers to take a look.
• I have occasional exchanges with excellent folks, although Twitter is not very good at conversation.
• A couple of weeks ago I had a small idea: Phonetic Friday. I’d like to do more things like this.
• Finally, sharing in others’ efforts is something I really enjoy. Recommending folks to follow, calling direct attention to others’ ideas, and using “RT” are things I try to do every so often.

It’s easy to get carried away, especially with things that fall into that last bullet point. Using Twitter in a focused way is as much about restraint as it is about actually generating ideas.

Do you follow Nice Web Type? Do you like how I’m handling it?