When Johno first asked me to write about Typekit, I jumped at the chance. I’d received a beta invite to try out the service about a week before, but deadlines had got in the way of actually getting round to it. Now I had the perfect excuse to have a proper play, create a test site, and immerse myself in the technology that got the web design community frothing at the mouth when it was announced a couple of months ago.
However, as I started to experiment with Typekit, I realised that the really interesting thing isn’t the technology itself: it’s what Typekit — and other services in the same vein — mean for the way we experience type on the web. And I’m not talking about it from a user’s perspective, where they get to see the end results of using a variety of typefaces, but from the web designer’s perspective: the way in which we’re going to be using and paying for fonts.
To jump back to Typekit’s positive features, however, one of the most overlooked features is that it offers a fall-back for Internet Explorer by serving up an .eot file. Why this is important is because it simultaneously solves two major problems: the availability of multiple typefaces and an integrated delivery method that copes with cross-browser (in)compatibility. Briefly put, it means @font-face is more readily available on IE than it has ever been before because we designers no longer need to worry about all of the fiddly workarounds. This is great news for everyone.
Rumour has it that the Fontdeck team are also considering free support for rare script typefaces, providing a way of getting these lesser-used languages on the web, where currently they are invisible. It’s a noble cause and a great example of why proper typography on the web is more important than just pleasing the tastes of us poncey designers.
With Clearleft handling the UI of Fontdeck, we know it’ll look great and have a strong focus on usability. With OmniTI handling the security, we know it’ll be as tight as a safe. The company’s track-record in online security is flawless, and with reliable sources claiming that Typekit’s security has already been hacked with relative ease, it’s natural that foundries will be more interested in signing up with a provider that can guarantee the safety of their fonts.
And make no mistake: this is what it really comes down to. A very large part of @font-face’s painfully slow adoption has been down to the font foundries and their concerns over font piracy, and rightfully so. Microsoft’s EOT format in its current state is far from ideal, but because of its potential to offer DRM, it’s the format that foundries have been happy to support, albeit half-heartedly. Now, with services like Typekit and Fontdeck, foundries finally have a reason to embrace type on the web: to open their product to a whole new audience without fear of their typefaces being stolen by anyone adept enough to click ‘view source’. Unfortunately, though, the pricing structure of these new services is still a mystery. With Typekit already in public beta, it’s likely that we’ll find out sooner about its price plans than Fontdeck’s, but right now all we can do is speculate. Undoubtedly the various services will price themselves competitively, but there are so many concerns that go way beyond the service itself: ultimately, with large foundries’ support being such a huge factor in the success of any given service, the price has got to be right for the foundries, not just the service providers or consumers.
And it’s not just a case of deciding on a figure, either. The choices of pricing models are potentially endless. Do you charge the user (that is, the web designer) per typeface? Per family? Do you offer a font purchase with an extended license for web use? Do you charge a subscription for a certain amount of service? Do you charge by the quantity of typefaces needed (5 families for $X a month, 10 families for $X a month, etc.)? Do you offer some for free and reserve some weights (or even glyphs, like ligatures) for paid customers? With the amount of questions that need to be answered and the the amount of question-askers who need to be appeased, I wouldn’t wish that kind of decision making upon anyone!
But, whatever the details of the exact services that end up being offered, one thing will be true: unlike ever before, where previously we had only purchased a font as a closed, finite, singular product, we are now entering the age of the font-as-service: where the font becomes synonymous with web hosting, mobile data plans, and movie rentals. No longer fixed, fonts will be borrowed, subscribed to, removed, expanded upon, and provided on-the-fly.
In his comment on Mike Davidson’s post, Jeff Croft raises the important question about the reliability of the service; not from the view of security I mentioned previously, but from the view of scalability:
With font files being delivered by third-party services, it’s a big concern, and another reason I feel reassured that a company like OmniTI will be looking after the infrastructure behind Fontdeck.
I praised Typekit when it was first released, and although we won’t know what the best solution will be for quite some time, I stand by my original message: it deserves praise because it was one of the first solutions to a long-standing problem; it got out there and said, ‘we can do this,’ when most other people were content to sit there and complain about it. But really this isn’t about what Typekit does, what Fontdeck does, what the various bespoke foundry solutions do, and how each of them does it better or worse than the other. Nor is it about the specifics of formats like .ttf, .otf, or the recently-proposed .webfont (which was summarised very neatly in Johno’s recent post). It’s about how service-based models are finally allowing typography to grow up and take its rightful place on the web.
Are we just hacking away to find a solution that satisfies our demands until a workable standard like .webfont or WebOTF is eventually approved and we can all hold hands and sing songs? Probably, yes. But as Mike Davidson said, “the entire world wide web is a hack.”