Typekit and the future of web fonts

Now that all major web browsers finally support the CSS @font-face declaration, embedding fonts in a web page is possible with just a few lines of CSS. In theory this means that web designers no longer need to limit their font choices to a handful of system fonts, and are free to use any typeface they please. In practice that freedom comes with a caveat: we are only allowed to use fonts with a license agreement that allows web embedding.

The trouble is that digital fonts have no provision for DRM, and pirating a copy of an embedded web font is a trivial exercise for anyone with the mind to do so. That’s obviously not a prospect type foundries are too keen on, and consequently no major foundry offers a licensing option for embedding their fonts in a web page. If you link to a commercial font from your CSS stylesheet the chances are that you are breaking your license agreement. Even the number of free fonts with an EULA that condones @font-face embedding is pitifully small.

That’s where Typekit comes into the picture. Typekit is a new font delivery service devised by Jeffrey Veen that promises to take the pain out of licensing fonts for web embedding. In their own words:

We’ve been working with foundries to develop a consistent web-only font linking license. We’ve built a technology platform that lets us to host both free and commercial fonts in a way that is incredibly fast, smoothes out differences in how browsers handle type, and offers the level of protection that type designers need without resorting to annoying and ineffective DRM.

Here’s how it works:

• Typekit strike up agreements with type foundries allowing fonts to be licensed for CSS linking.
• Web designers subscribe to Typekit, and pay a monthly fee to embed typefaces on their websites using an @font-face declaration.
• Would-be font pirates are deterred from stealing embedded Typekit’s fonts by security measures including: allowing only authorised domains to link to their fonts; source code obfuscation; and splitting fonts into multiple files.

Problem solved, right? Well, perhaps.

Typekit’s font-as-a-service model navigates a clever path through the legal minefield of web font licensing, but I am not convinced that it is a perfect solution. In particular there are two aspects of Typekit’s approach that strike me as problematic: the fact that their pricing model is based around renting fonts rather than owning them, and the need to rely on remote servers for the delivery of fonts.

Renting vs buying

Because Typekit is still in beta details of its pricing are sketchy, but it is clear that customers will pay a monthly or annual subscription fee to access Typekit’s font library. This pricing model is significantly different to the traditional one-off payment required to license fonts for offline applications.

Will website owners be prepared to continue paying for a font month after month, year after year? Over time Typekit subscription fees could conceivably exceed the cost of a standard font license, despite the fact that Typekit’s fonts cannot be reused in any other medium, or potentially even on another website. And if you ever cancel your Typekit subscription, the fonts vanish into thin air. This is a radical departure from the current font licensing model, which grants customers the right to perpetually reuse any fonts they purchase.

Purchasing fonts twice

In addition to the fact that font subscription models require designers to pay for fonts they can’t reuse, in most cases it will also be necessary to purchase a regular installable version of each typeface.

To produce mockups and work on a production version of a website, a web designer needs to work with the same typefaces that will feature in the final live site. Typekit only offer web embedding of fonts, so to install a typeface on their local computer a web designer would have to purchase a separate font from another vendor. It’s not going to cut the mustard to produce mockups set in Arial and tell the client to “imagine that the headings are actually Avant Garde”!

When you also consider that many websites have multiple domain aliases (mysite.com, mysite.com.au, etc), and Typekit uses a per-domain pricing model, it is clear that the potential exists to pay many times over for the same font.

Network reliability

Another potential problem with Typekit is network downtime.

I can’t imagine many designers would trust their CSS files to a remote delivery network, and I think we need to accord fonts a similar importance. If major players like Google and Amazon suffer network interruption from time to time, then it is reasonable to assume that Typekit will too.

Admittedly, occasional network outages may not be a deal breaker, what happens if Typekit goes out of business, or a foundry retracts the right for Typekit to distribute their fonts? In either of these scenarios it seems probable that Typekit subscribers would have the fonts rudely stripped from their websites. In a best case scenario subscribers could turn to a Typekit competitor such as Fontdeck to revive their font links, but what if no competitor offered the same typefaces? The design of countless websites could be irrevocably ruined due to their dependence on remotely hosted fonts.

The future of font embedding

Despite the reservations I have outlined above, I have to agree with Andy Clarke when he predicts that Typekit will change everything.

By coming up with a practical answer to the problem of @font-face licensing, Typekit has paved the way for alternative font embedding approaches. Clearleft and OmniTI have joined forces to create Fontdeck, and at least one foundry, Typotheque, has a web font service under development.

Soon there will be a number of services vying with Typekit to win the hearts (and wallets) of web designers, however I suspect the deciding vote will ultimately be cast by large font foundries such as Linotype and Adobe.

The type industry’s major players will need to decide where they stand on the issue of font embedding, or they risk being left behind while smaller type foundries reap the benefits of web font licensing. If they follow the lead of their counterparts in the music industry it might be years before our @font-face woes are sorted out. On the other hand they might choose to take the bull the horns and launch their own font hosting services to compete with Typekit.

Whatever the response of large type foundries and vendors turns out to be, it will very likely determine the future of typography on the web. Hopefully we end up with a solution that is fair to web designers, website owners and font foundries alike.

Further reading

Introducing Typekit

Jeffrey Veen announces the arrival of Typekit, and explains the basics of how the service will work.

Ubiquitous web font embedding just got a step closer

John Allsopp argues the case for more liberal font licensing. Recommended reading.

First impressions of Typekit

A step-by-step tour of the Typekit beta.

On Typekit

David Yeiser shares some of my reservations about Typekit.

The Font-as-Service

Jay Elliot Stocks gives an overview of Typekit and its competitors.

Testing Typotheque @font-face embedding

Andy Clarke takes Typotheque’s new web license for a spin. It is interesting to note that Typotheque requires a one-off payment rather than a subscription like Typekit.