Mike Davidson: Examining Typekit

Ratings

3 of 5 stars
What’s this?

A typically thoughtful look at the promise in Jeff Veen’s forthcoming font-embedding technology which will allow Web publishers to license and embed typefaces on HTML pages. Davidson, a co-creator of the type replacement method sIFR, says, “It’s important to examine the following characteristics, in order of importance: compatibility, functionality, legality, ease of use, and hackiness,” and he proceeds to do just that, very effectively. The comments on this post are interesting too and worth a read (at least the first dozen or so were).

While we’re idly speculating in advance of having actual hands on experience with Typekit, I may as well weigh in with some speculation of my own: if in fact the Typekit business model allows relatively cheap licensing costs, that is of course ideal for everyone — independent Web designers would have access to a fully rich array of typographic options, and type foundries would both stave off illegal uses and open up new markets for their products. Unfortunately the type business has never really been a consumer business, and it’s quite possible that licensing won’t be particularly affordable for individuals — and yet Typekit could still succeed. There are enough big companies willing to pay a few hundred or a even a few thousand dollars to render their messages in their own typographic voice to make this work. However, fingers crossed that everyone involved sees the upside in affordability.

Jump to this link

+
  2. Keith Bell

    As others have said, this is a problem that requires a technical solution, and Typekit is not it — it is essentially another layer of licensing. Consider: I have a bundle of fonts, for which I have purchased legitimate licences. Those licences permit me to use the typefaces in printed documents, and to make and distribute unlimited copies of those documents without further payment to the type foundries. They also permit me (or do not clearly prohibit me, and the practice seems to have the de facto acceptance of the foundries) to use the typefaces in web page graphics, which are similarly open to unlimited distribution. They even (in most cases, at least) permit me to embed the font in a PDF file and distribute the file as widely as I please.

    This is OK by the type foundries, because there are significant technical barriers to getting at their intellectual property. In the case of printed matter or graphics, as long as you had a full set of glyphs you could trace them all and recreate the typeface, and sure, that has been done — but generally, who is going to take the trouble? I believe embedded fonts can be extracted from PDF files, but not easily. The notion that it is not impossible is probably why some licences don’t permit such embedding, but the difficulty (added to the fact that a PDF may only contain a sub-set of the glyphs) is probably why so many allow it.

    What we need in order to use @font-face on the web is an easily implemented technical mechanism that provides similar protection for the foundries without involving an already legitimate licence holder in additional expense, or putting a third party (like Typekit) in the way, or adding some half-baked DRM like EOT to the font. For example, putting the font files in a directory outside the web root would prevent anyone outside of that server downloading or hotlinking to them; unfortunately CSS can’t reference files outside the web root in the way that PHP or CGI scripts can. Maybe someone could come up with some kind of wrapper for font files.

    As you said, Khoi, the type business has never really been a consumer business, so “affordable” to them might not be affordable to me or to my smaller clients. All I know is that if I’m being asked to pay more (and probably on a per domain if not an ongoing basis) to use a font on the web for which I already have a legitimate licence, I’m going to continue using that font in graphics or sIFR, especially if the alternative involves a third party AND JavaScript is required to make it work. (I don’t care how few people might be browsing with JavaScript disabled; if I were paying extra for it, I’d want a solution that works for everybody.)

    Finally, Typekit doesn’t solve the foundries’ essential problem with @font-face: those people who don’t give a damn about intellectual property will simply go right ahead and put the raw font files up on their own servers and wait and see if they get caught.

  3. ron

    this idea will only play to a small niche audience. sure top flight design firms and corporation with budgets will probably play ball, but the majority will not bother with registering and setting everything up and also PAYING a recurring fee for something that they can just do super easily and for free by using @font-face.

    my own solution will be to use some of the growing legion of fonts that are free to use with @font-face. i’m not paying just so I can embed some font for some small insurance company’s website I designed. And face it, only us design nerds really care about fonts and web typography, no one else does. ok, maybe the ultra rare client does.

    my other comment is if typekit can write some solution to prevent downloading font files so can anyone else. and isnt that what the issue is? so whats the point?

Thank you! Your remarks have been sent to Khoi.