Blogging And All That Malarkey

First impressions of Typekit

This morning my inbox popped with an invitation to the preview of Typekit, a technology platform that hosts 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. Back in May I wrote that Typekit will change everything, here are my first impressions of Typekit in action at For A Beautiful Web.

The interface

As you might expect when you combine Jeffrey Veen and Jason Santa Maria, Typekit's interface emphasizes function with understated style. It doesn't try too hard to impress, instead it's quietly confident and self-assured.

Configuring Typekit

With your account active, create a kit by configuring the name of your site (for Typekit's internal navigation) and its domain name. Each of the kits that you create will be linked to a specific domain.

Create a Kit

Installing Typekit hosted typefaces on a site involves little more than copying a few lines of JavaScript into the <head> of your document. The script inserts a linked Typekit stylesheet.

Install Javascript

<link rel="stylesheet" type="text/css" 
href="http://code.typekit.com/k/xox1rlh-standards.css?12345">

This stylesheet contains font embedding @font-face declarations where, most importantly, the source of your chosen fonts are obfuscated. This is just one of Typekit's layers of copyright protection. (More on choosing these typefaces in just a moment.)

@font-face {
font-family : "skolar-1";
src : url(data:font/otf;base64,obfuscation;
font-style : normal;
font-variant : normal;
font-weight : 600; }

h1, h2, #nav-main a { 
font-family : "skolar-1","skolar-2","Palatino","Georgia","Times","serif"; }

Next it's on to browsing Typekit's library of typefaces and choosing one or more for your domain.

Browse typefaces

On For A Beautiful Web I'm using Skolar from TypeTogether. As Typekit's handy info panel explains:

Skolar is a text serif which has been originally designed with scholarly and multilingual publications in mind. The typeface maintains its credibility while incorporating a subtle personal style, neither neutral nor conspicuous. Prominent serifs and low-contrast modulation add to its robustness, and together with relatively large x-height, they improve the typeface readability in small sizes. Skolar family of six weights and large character set is flexible enough for complex text settings and editorial work. It becomes distinctive in bigger sizes, thus fitting corporate design demands.

Currently Typekit's available selection is a little thin itself, a situation that is sure to change as more designers and foundries come on board. The browsing functionality itself will need to change too and I would love to see both navigation by type designer and also suggestions from designers like Jason Santa Maria on which combinations of typefaces (serif and sans) work well together. You can preview your choice by characters,

Preview characters

Or by entering your own text.

Preview text input

When you have added typefaces to a kit, launch the Kit Editor to configure, among other things, the CSS selectors to bind your chosen typefaces to your design.

Configure selectors

On For A Beautiful Web I chose to use @font-face on <h1>, <h2>, main navigation anchors and the home page's introduction paragraph. More options including additional weights and styles are currently unavailable, but as this screen-shot on Flickr shows, they will include regular, italic, semibold and bold weights (presumably dependent on availability in a font) plus options to choose (or exclude) specific sets of glyphs in order to control the download size of a kit.

Typekit's Kit Editor also allows you to set a CSS stack for users whose browser doesn't support @font-face. So far I've been unsuccessful in seeing this working as this set of BrowserCam images and this screenshot of Internet Explorer 8 (courtesy of Ryan Brunsvold) shows.

The question of type rendering

Studying type rendering closely also calls into question the natural differences between the ways that browsers render type as I discussed in Walls Come Tumbling Down. Safari's text rendering is clearly more refined and superior to Firefox 3.5. Opera 10 Beta 2 on OSX also seems to have a few problems handling Typekit hosted @font-face, although somehow I like its punkish rendering.

Opera 10, Beta 2 on OSX (courtesy of Ryan Brunsvold)

Will Typekit change everything?

Although I never expected anything different, setting up and using even this first preview iteration of Typekit was simple, fast and actually a pleasure. Sure there are many areas that need improving, not least browsing and navigating through the (I hope soon to increase) typeface library.

I would love to see Typekit invent new ways for designers (and especially non-designers) to choose the right combination of typefaces based on designers' experience. Not so much a people who bought this also bought this approach, more intelligent typeface package combinations — what Mark Boulton calls smart defaults. I would also love to see Typekit develop its own fuzzy logic that might warn against certain combinations.

Will Typekit change everything? Maybe. With Jeffrey Veen and others behind it, I'm more than certain that it will deliver everything that it sets out to do. That's in the bag. Not an issue. I'm one happy designer.

Now I'd like to see a hint that Typekit will be more than just a typeface delivery service that increases the range of typefaces we can use on the web. That it can build on the experience of designers like Jason Santa Maria to create something that will truly improve web typography. Typekit. I'm talking to you — don't let me down.

(To best see the results of Typekit on For A Beautiful Web, head for the home page.)

Leave your comment

Jack Osborne

July 18 2009 @ 11:34pm #

I’m really excited that it’s finally out, or at least in a beta, I can’t wait until the day that I get to try it.

Sure, as you’ve highlighted above, it’s not perfect but it’s a start and a pretty darn good one at that too. The suggestions that you have highlighted above with regards to hints and tips for putting together your font stack are a must in my eyes. Can you image some of the monstrosities out there if a guide wasn’t put in place. But then again, it’s that persons website, they can do what they want with it. All I’m saying is that a little gentle persuasion wouldn’t go a miss :)

Cheers for the write up and the screenshots Andy, you could have kept this to yourself but I’m glad you’ve shown us ‘normies’ what the backend etc. looks like. I look forward to seeing you writing a little bit more about it as you delve further into it.

Enjoy playing with your new toy this weekend.

Signed a jealous boy.

Matthias Edler-Golla

July 18 2009 @ 11:37pm #

Thanks for sharing your impressions using typekit!
I am looking forward to test it myself when typekit will go “public” – hopefully soon!

(Until then there is still some time for us webdesigners to freshen up our knowledge about different fonts – a knowledge badly neglected because of the current web standard fonts…)

Andrew Ingram

July 18 2009 @ 11:38pm #

It looks great. My only issue is that I have a hard time believing that the obfuscation techniques will get in the way of people who want to steal fonts. As a quick test it only took me a couple of minutes to get the skolar font data from the data urls, though the end result didn’t work. But I imagine a far better hacker than me (ie someone who knows what they’re doing) would have no difficulty doing that last little bit that turns it into a real font again.

It’ll only be a matter of time before there are easily available tools that perform an ‘extract all fonts from this page’ function. Dishonest people are dishonest, a small technical barrier isn’t going to stop them. It’s so easy to get hold of commercial fonts as it is, the foundries are just going to have to keep relying on the fact that people who use them commercially are going to want to cover their ass by paying for them.

David Březina

July 18 2009 @ 11:44pm #

Please note that the type description you used is not for Skolar, but for another TT typeface: Crete. See http://www.type-together.com/Skolar for proper information.

Paul Randall

July 19 2009 @ 12:11am #

Other screenshots can be seen at: http://www.flickr.com/photos/tags/fabwtypekit/

The site really does look good, and apart from some rendering issues in IE6, and the duplication of the jQuery JS file in the Typekit JavaScript file this really does look promising.

Jeremy Orion

July 19 2009 @ 12:54am #

Looks beautiful and very promising.

One thing that bothers me initially is the noticeable flicker that you get when loading an uncached page (where one font is initially displayed before being replaced - occurs in both FF 3.5 and Safari 4).

Ryan

July 19 2009 @ 01:14am #

#3: My only issue is that I have a hard time believing that the obfuscation techniques will get in the way of people who want to steal fonts. As a quick test it only took me a couple of minutes to get the skolar font data from the data urls, though the end result didn’t work. But I imagine a far better hacker than me (ie someone who knows what they’re doing) would have no difficulty doing that last little bit that turns it into a real font again.
I agree. Also, if you’re viewing a site that uses a font, that font will already have been downloaded to your browser cache somewhere where it would probably be fairly simple to get at it. In this case, it would probably be a fairly simple task to just go preview fonts on TypeKit’s website and end up with the original font files. From what it sounds, they’re only obfuscating the URLs and not the actual fonts contained, because they wouldn’t actually be able to do that in any reasonable way.

TypeKit seems great, but I have a hard time believing yet that more foundaries would want to make their fonts available there without more promises of security than “we obfuscate the URL”.

Andy Clarke

July 19 2009 @ 01:25am #

@Andrew Ingram: y only issue is that I have a hard time believing that the obfuscation techniques will get in the way of people who want to steal fonts. As a quick test it only took me a couple of minutes to get the skolar font data from the data urls, though the end result didn’t work.

@Ryan: I agree. Also, if you’re viewing a site that uses a font, that font will already have been downloaded to your browser cache somewhere where it would probably be fairly simple to get at it. In this case, it would probably be a fairly simple task to just go preview fonts on TypeKit’s website and end up with the original font files.

— Although I’m not involved in Typekit directly, I have been told that its obfuscation methods do more than just deter the casual font thief. The typeface is split across multiple files that while they can be accessed from a browser’s cache, cannot be casually reassembled into a working font. Kerning and hinting will also be split into additional files to further abstract the font data. All of this combined should make the time and effort involved in reassembling a Typekit font hardly worth the effort.

Ryan

July 19 2009 @ 01:32am #

@Andy: I did little looking with some of the tools Safari provides out of the box and can confirm that. Looks like good news!

Jason Santa Maria

July 19 2009 @ 01:47am #

Thanks for the write-up Andy. The browsing experience currently in the beta was the first draft from a little while back, and we’ve already set to a thorough overhaul of it (which I’m currently working on and quite excited about). Like you, I’m also interested in finding new ways to inform and educate about typeface discovery and pairings. I think there’s a great opportunity to have smart recommendations and the like bubble up through the interface.

I also want to point out something about the flash of content while font files load. This actually has nothing to do with Typekit. The font file needs to load in whether it is remotely or locally hosted, resulting in the content flash. Some of the things we’re working on will reduce that (like character subsetting to produce smaller files) as well as the new .webfont format proposal which could reduce font file sizes drastically.

(typing this from an iPhone, forgive the brevity)

Joe

July 19 2009 @ 02:09am #

As one of the people on Mozilla’s graphics team, I’d love to hear what issues Firefox has with font rendering so we can fix them. Doing, say, a follow-up post with screenshot comparisons would go a long way!

I’m also looking so forward to Typekit making fonts super-easy on the web. Images for text is so 2008.

Jeremy Orion

July 19 2009 @ 02:46am #

@Jason: Thanks for pointing that out. I went and reviewed several sites using @font-face without TypeKit and saw the same flash-o-font. Strangely, I never noticed it before on those sites…maybe I was looking too hard for something to be wrong here :)

I hope the efforts you are making toward mitigating this problem are quick and successful.

Andy Clarke

July 19 2009 @ 03:06am #

@Joe Drew: As one of the people on Mozilla’s graphics team, I’d love to hear what issues Firefox has with font rendering so we can fix them. Doing, say, a follow-up post with screenshot comparisons would go a long way!

— Your wish is, of course, my command. So as requested, here is a follow up post on the subject of cross-browser type rendering, Type does not look exactly the same in every browser

John Holdun

July 19 2009 @ 06:18am #

Love the little hints at the service here, and finally receiving some insight into how TypeKit is actually protecting the font files. The Opera screenshot is hilarious. Auto-Dada.

Maybe I missed this, but TypeKit isn’t going to be free, is it? I had always assumed it would be a pay service, possibly with surcharges for foundry royalties. It makes sense that this preview round wouldn’t cost anything as it is invite-only, but do we know yet if it is going to stay that way?

Jeffrey Veen

July 19 2009 @ 06:43am #

Andy, thanks for the write-up. You’ve really put us through the paces! As Jason mentions above, we’re hard at work on a navigation system that will make it MUCH easier to find and select fonts. And of course, we’ll be adding many, many more fonts in the near future.

I’m currently working on a blog post about how the obfuscation works in Typekit. You’re right that no matter what, someone with enough time and knowledge can recreate a font from our service. There are, of course, much easier ways to steal digital assets. We make it significantly harder.

John Holdun: Yes, Typekit will be a paid service. We will, however, have a trial version that you’ll be able to use for free. It will be limited, but include enough for you to experiment with web typography on your site.

Jay

July 19 2009 @ 08:18am #

What’s the difference between this and Kernest.com? Don’t they both do the same thing? I like the look of typekit better, but at least Kernest is available to everyone now.

Andy Clarke

July 19 2009 @ 08:41am #

Jay: What’s the difference between this and Kernest.com? Don’t they both do the same thing?

— I’m not directly involved with Typekit and Kernest only came to my attention today, so I’m not best qualified to compare. Best that I point you instead to an interview with Kernest’s founder on 13th of this month.

Peter Bilak

July 19 2009 @ 04:31pm #

Splitting font files into two parts, is a clever hack. It certainly deters casual viewers. It has disadvantages too. One one them is visible in the Opera screenshot, which doesn’t see the ‘Skolar 2’ The other is that kerning, and OpenType substitutions will probably not work. Here is more info on this:
http://letterror.com/develop/webfonts/partials/

While OpenType substitution and kerning is not critical to web fonts at this moment, and only FireFox supports it.
http://opentype.info/blog/category/technology/
It just means that typefaces such Bello will not use their full potential, and will look rather static.

But this omission is more important for non-Latin fonts which rely on OpenType feature substitution. You couldn’t get Arabic, Hebrew, Hindi, etc to work without it.
http://www.typotheque.com/webfonts/multilingual_sample

Last note: Rendering of TTF fonts will be more consistent in browsers than rendering of OTF fonts. This page uses TTF fonts:
http://www.typotheque.com/webfonts/sample/

Garrick Van Buren

July 19 2009 @ 10:34pm #

Jay, Andy - This is Garrick from http://kernest.com. Kernest is a purely CSS-based web font service - and has been publicly available since July 16th. There’s some great web typography being designed with it - http://bram.me is my current favorite - but there’s a realtime list in Kernest’s home page. Thanks.

Andrew Mahoney

July 20 2009 @ 01:48am #

It sounds like the current issues are small and fixable. From a progressive enhancement perspective what does Typekit suggest? I see the mention of the CSS stack. I also see things look pretty bad in IE6 (BrowserCam images). Did the FOBW site CSS not address IE6? Why does it look so unstyled in IE6? In the corporate world IE6 is still alive and needs to be addressed.

Andy Clarke

July 20 2009 @ 02:05am #

@Andrew Mahoney: It sounds like the current issues are small and fixable. From a progressive enhancement perspective what does Typekit suggest?

— The CSS font stack takes care of browsers that do not include @font-face implementations.

I also see things look pretty bad in IE6 (BrowserCam images). Did the FOBW site CSS not address IE6? Why does it look so unstyled in IE6?

— This site uses Universal Internet Explorer 6 CSS. That is why I’m now advocating to my clients (and to you), that where feasible, not to waste hours in time and a client’s money on lengthy workarounds in an unnecessary attempt at cross-browser perfection. Instead, you and I should provide simple but effectively designed HTML elements. This means just great typography for headings, paragraphs, quotations, lists, tables and forms and no styling of layout.

Alex

July 21 2009 @ 11:39am #

Splitting the characters into multiple font files is a “smart” idea, although it’s going to break things (as mentioned before)

And the obfuscation isn’t obfuscating really, it’s a perfectly valid data: URL that if you open, will present a download dialog for the fonts.

If anything, it makes it easier to get the fonts, all you need to do is download the single .css file to get every font you use on the site in a working format (linking to the plain .ttf/.otf files makes it harder to grab)

Jeffrey Veen

July 21 2009 @ 11:38pm #

Peter, Regarding splitting fonts into multiple files—The Letterror experiment covers a lot of the same ground we have with Typekit. We’ve found that with a relatively simple algorithm, we can programatically evaluate kerning pairs and extract where we do no damage. In rare cases, we split where there is minimal kerning information, but even in that case we’re experimenting with sending the removed pair data via Javascript.

charles

July 22 2009 @ 11:52pm #

Looking at the forabeautifulweb site and reading your css files you only have 7 declarations for custom typekit fonts but the css file weighs in at 182k. Probably due to the font data being seemingly embedded in the file via a base64 encoded src declaration (which when decoding also outputs a nice long copyright message).

As this css file has a random character string on the end of it this file will never be cached by a browser, as it sees it as a separate file each time.

What if I used 20 typekit font declarations, just think how large that file would be and how long it would take to download as it never gets cached?

Glad someone tried it, think i’ll be staying well clear of it for now.

Jeffrey Veen

July 23 2009 @ 01:29am #

Charles, you know that old line about premature optimization being the root of all evil? We haven’t touched the font files themselves at all. They contain full character sets, metadata, copyright notices, and everything else in a print-ready shop. Of course they won’t in the near future, but we’re prioritizing new features and rolling them out as quickly as possible.

Scott Schiller

July 23 2009 @ 08:19am #

I think data: URIs are a good start, but would suggest perhaps a few other tricks - maybe serve the data scrambled in JS, decode and append a stylesheet on the fly with the “unencrypted” data: URI, so it isn’t so trivial to copy/paste the raw data from the CSS itself.

I think it’s unfortunate that JS is required for showing fonts as in this case, but I also understand the balance of this and security (and I have much respect for Mr. Veen et al’s work, etc.)

Andy Clarke

July 23 2009 @ 08:24am #

Just a quick note to say that Typekit‘s Weights and Styles palette launched today, enabling me to select only the weights and styles that I need from each typeface and so reducing the weight of a kit.

By selecting only ‘Normal’, I reduced For A Beautiful Web‘s kit weight from 204Kb to only 51Kb.

Scott Schiller

July 24 2009 @ 01:23am #

Serving the CSS with gzip should reduce the file size over the wire, perhaps 50%.

Jeffrey Veen

July 24 2009 @ 04:21am #

Scott, we are, indeed, serving gzipped CSS files (you can see evidence of this in our response headers). We’ve seen up to 65% compression rates in some cases…

Ryan Carver

July 25 2009 @ 08:11am #

“As this css file has a random character string on the end of it this file will never be cached by a browser, as it sees it as a separate file each time.”

The seemingly random character string does not change per-request. I’m aware that some say any query string will cause cache-invalitation but I have not seen this in real world browser tests.

Commenting is not available in this channel entry.

First impressions of Typekit

The interface

Configuring Typekit

The question of type rendering

Will Typekit change everything?

Leave your comment

Andy Clarke

Andy Clarke

Andy Clarke

charles

Andy Clarke

Hardboiled Web Design by Andy Clarke