The Typekit Blog

We’ve rolled out support for Typekit fonts on IE9; republish your kits to see the difference. Since IE9 is not yet mature, this support remains experimental; but we are continuing to work on it and are very excited about the direction it’s heading.

What’s new in IE9? First, IE9 now fully supports the WOFF font format, which is rapidly becoming a W3C standard. And it permits linking to all variations within a font family, as opposed to previous support for only four fonts per family. Perhaps the most exciting development is that IE9 has dramatically improved the quality of its screen rendering. See for yourself:

Skolar rendering comparison: IE8 on the left, IE9 on the right

With all of these improvements, we encourage you to republish your kits and review your sites in IE9 so that you can be ready when IE9 is released.

It’s important to note that your site must render in documentMode 9 in order to take advantage of the new features included with IE9 (that includes all new features in IE9, not only the ones related to web fonts). If you haven’t heard of documentMode before, Microsoft has put together a guide which explains what it is and how you can use it on your site. Overall, we think this is a big step forward and will continue to work closely with the IE9 team to ensure that support for Typekit on IE9 is first class.

Are you intrigued by typography and the web? How about beer? We want to meet you.

Amsterdam: Monday, September 13th, 6-9pm

Join Typekit founders Bryan Mason and Ryan Carver at the Adaptive Path Amsterdam studio for an evening of geeky conversation about the web, fonts, and more. We’ll serve refreshments and provide a wireless connection so you can show off what you’ve been working on. Space is limited, so please RSVP.

New York City: Tuesday, September 14th, 6-9pm

Back in New York, Bryan will be joined by Jeffrey Veen, Don Loeb, Mandy Brown, and others for an evening of beer and type at The Magician. We hope to see you there.

As part of our ongoing work on the Typekit API, we’ve added support for JSON with callbacks. This means you can now easily use Typekit data in your Javascript code.

JSON with callbacks

JSON with callbacks, also known as JSONP, is an alternative to XmlHTTPRequest that avoids the same origin policy. In other words, it allows code on your site to request data from our site.

Most libraries have built in support for JSONP. For example, we can fetch information about Typekit’s library using jQuery:

var url = "http://typekit.com/api/v1/json/libraries/full?callback=?";
$.getJSON(url, function(data){
  var count = data.library.pagination.count;
  alert('There are ' + count + ' fonts in the full library');
});

The URL we’re requesting includes a callback parameter that tells the Typekit API you want JSONP output. jQuery does the hard work of requesting the data and then turning it into a Javascript data structure for you to read from.

A step-by-step example

So what can we use this for? One small but useful thing we’ve built is a bookmarklet that tells you which Typekit fonts are used on a page.

We start out by iterating over the page looking for the Typekit embed code:

var kitId;
$('script').each(function(index){
  var m = this.src.match(/use\.typekit\.com\/(.+)\.js/);
  if (m) {
    kitId = m[1];
  }
});

One we have the kit ID we make an API call for more information about that kit:

$.getJSON("http://typekit.com/api/v1/jsonp/kits/" + kitId
          + "/published?callback=?", function(data){
  // …
});

Then we use that data to generate the HTML for a box containing a list of font families used in the kit:

var box = $("<div><p>Typekit fonts used on this page:</p></div>")
$.each(data.kit.families, function(i,family){
  var item = $('<p><a href="http://typekit.com/fonts/'
               + family.slug + '">' + family.name + '</a></p>');
  item.appendTo(box);
});

We then give that box some style, and insert it into the page body:

box.css({
      'border':"1px solid #ddd",
      'background':"#ffffff",
      'color': '#666',
      'position': 'absolute',
      'right': '5px',
      'top':'5px',
      'width': '200px'
});
popup.appendTo('body');

And we’re done!

Learning more

You can view the full code for the bookmarklet and instructions on how to use it over at github. You can also check out the full documentation on the output formats supported by the Typekit API.

If you have questions or feedback, let us know in the comments, or jump into the typekit-dev google group. We look forward to hearing from you.

When we first built Typekit, our research showed that Internet Explorer had serious limitations when it came to handling multiple fonts from a single font family; as a result, we served just one font per family to IE.

But that often meant that when IE was called upon to display a bold or italic style, it would synthesize that style by thickening or slanting the glyphs of the family’s normal font, instead of using the actual bold or italic font. The difference between actual and synthetic styles can be significant:

Adobe Text Pro italic in Internet Explorer 8

We’re continually investigating how browsers support web fonts, and we’ve recently confirmed that in many cases IE can in fact use up to four fonts from a given family. As a result, we can now serve IE up to four of the fonts you’ve enabled for each of the families in your kits. This allows you to use more real styles in IE instead of relying on synthetic ones. To see these improvements applied to existing kits, just republish them via the Kit Editor.

Note: if you’ve enabled more than four fonts for a given family, we’ll serve all of them as usual to other browsers but will choose which four to serve to IE based on IE’s own weight matching algorithm. If your pages use weights and styles other than those we’ve served, IE will use the closest match from the available fonts. The following tables of results (click to see full sized) from our research show which of a family’s fonts IE will display when your pages use various weights (the table columns), given each combination of defined weights (the table rows). When a weight is shown in bold in this table, that means a synthesized weight will be displayed.

Font weight matching in Internet Explorer 6/7/8 (click to see full sized)

That looks pretty complicated — and this is just for IE! Not surprisingly, we’ve observed other browsers behave differently. That’s why our next improvement will be an addition to the Kit Editor showing you which of a family’s fonts will be used in which situations and in which browsers. This will help you make informed decisions about how to optimize your kits.

The Typekit team is heading to Los Angeles this week for TypeCon 2010, the annual type industry event hosted by The Society of Typographic Aficionados. This Thursday, August 19, we’re hosting the opening night party along with Adobe and Font Bureau. And on Friday, Typekit’s Bryan Mason and Tim Brown will be on stage hosting a special session titled The Future is Now: The Brave New World of Web Fonts as well as a followup panel discussion featuring participants from Google, Adobe, Microsoft, Monotype, and the W3C.

Registration is still open and we’d love to see you there.

Today marks the one-year anniversary of Typekit’s launch. It’s been an unbelievable 12 months of growth and learning, not just for us but for webfonts, web design, browser development, and so much more. And we can’t think of a better way to mark this moment than to announce one of our most exciting partnerships to date.

Adobe and Typekit are teaming up to bring some of the world’s most popular, recognizable, and respected fonts to the web. Starting today, you’ll be able to use classics like Adobe Garamond, News Gothic, Myriad, and Minion plus many more on your website — all of them newly optimized and hinted for the screen. These fonts look fantastic.

We’ve been using these fonts internally here at Typekit for a few weeks and the quality is simply amazing. These are the original cuts of the celebrated typefaces you’ve been waiting for, not reproductions or knockoffs of their designs. That means you can use them with the assurance that your creative work is being presented with all the accuracy and technical detail the print world has known for decades.

The Adobe type team has put a lot of work into these fonts, bringing their years of experience with type and staying focused on the best practices for the web. In addition, they have also made fonts available at every Typekit account level. You can even use Adobe Garamond with our free Trial plan! Have a look through the collection. Be inspired. Create beautiful work.

If you don’t yet have a Typekit account, it only takes a minute. Sign up for full access to thousands of fonts here. For even more details, see the announcement on Adobe’s blog.

We’ve just added a feature that should make using Typekit on subdomains way easier. You can now use * as a wildcard in the authorized domains that can link to a font.

This makes it possible to use Typekit on services where every user has their own subdomain (*.myservice.com). It also gives you the flexibility to get Typekit to work on all of your Development and QA servers (*.dev.example.com, *.qa.example.com).

You can manage your authorized domain list from the “Kit Settings” tab in the Kit Editor.

Today we’re excited to announce the launch of the Typekit API.

Our goal with Typekit is to be the easy to use high quality fonts on any website. As we’ve watched people use our service, we’ve realized that the web interface to Typekit is one of many ways to build a website. But some companies need to generate thousands of kits for the sites they host; others would like to build alternatives interfaces on top of our infrastructure. So we got to work on a way to unleash that creativity and offer a simple way to integrate Typekit into any web-based service.

The Typekit API gives you the ability to programmatically create, modify and publish kits. It also allows them to fetch metadata about all the fonts in the Typekit library. In short, it allows you to write an application that does almost everything you can do with typekit.com.

If you’d like to dig in to the technical details, you can read the documentation and reference or take a look at the sample applications.

Of course, this launch is just the beginning. We’re planning on adding more data and functionality to the API as we see how it’s being used. If there’s something you’d like to see added, or if you want some help building your app, you can let us know through the new typekit-dev google group.

We can’t wait to see what you build!

We put a lot of effort into the quality of the fonts in the Typekit library. As part of that work, we’ve been researching the relationship between font math and CSS, and would like to share what we’ve found. If you’ve ever wondered why some fonts look smaller than others at the same typeset size, or why the vertical space between lines of text is such a guessing game, this post is for you.

Font math

Font files contain more than just glyphs, the designed characters and symbols that are the essence of a typeface. They also contain mathematic instructions for spacing those characters, such as the actual amount of room a glyph should consume relative to its CSS-specified size and the amount of horizontal space on either side of a glyph.

FF Meta Web Pro on an infinite canvas.

Some of the most interesting, critical font math for web designers is related to the visible and invisible vertical space at play when we typeset web text. When type was made out of wood, lead, or film, designers had to adhere to physical constraints when typesetting. Now, we typeset using CSS — setting font-size, line-height, margins and padding. Our letterforms live on an infinite canvas; they are mathematic points and curves, independent of resolution. Let us imagine a glyph on this infinite canvas, stretching in any direction as far as it pleases.

Font files provide structure for glyphs by establishing the invisible bounds that will govern them. A font’s em square and baseline determine its relative size and placement when typeset. Vertical metrics influence the height of ascenders and depth of descenders.

FF Meta Web Pro (left), Athelas Web (right)

Font math and CSS

Even when fonts’ em squares are sized to the specification of our CSS, the positioning of fonts’ baselines, the size of letterforms relative to their em squares, and fonts’ vertical metrics will vary from typeface to typeface. So the size and spacing of text we see in web browsers will also vary.

14px FF Meta Web Pro (above), 14px Athelas Web (below)

If letterform heights or depths exceed the values set by ascender/descender vertical metrics, glyphs can appear clipped. Not helping here is the fact that type designers must juggle three sets of vertical metrics values that (surprise!) are each used by a different array of web browsers. For example, while most web browsers use hhea metrics, Internet Explorer instead uses OS/2 metrics.

Example of a vertical descender metric that clips some characters in web browsers.

Vertical metrics can be confounding for web designers. These measurements seem not to influence type size or line height, as they overlap (rather than push against) vertically adjacent lines of text. However, when two typefaces are combined on the same line of text, vertical metrics can influence the vertical space consumed by that line. An explanation of how this works deserves its own post, so we’ll save that for later.

Two fonts’ combined math can affect spacing. More about this in a dedicated post.

These complexities can be a drag. There’s nothing like hacking on font math when you could otherwise be finished with a project. That’s why we’re studying this stuff here at Typekit — to give web designers more control and a deeper understanding of font math and CSS, and to make things easier in cases where we want the math to “just work.”

Partner Tools

We also want to help our foundry partners better understand how CSS works with their typefaces, so we’ve developed a suite of Partner Tools that help double check for missing glyphs, inconsistent metrics, and metrics values that might clip glyphs. With this information, type designers can review and adjust their fonts for better translation in CSS.

Font review tools for Typekit partners.

Control and peace of mind

Type designers need to know how font math translates to CSS typesetting, and Typekit users should never have to worry that type will be spaced unpredictably in any browser. We’re looking forward to growing Typekit and continuing to share what we learn.

We are happy to report that Typekit now has full support for serving fonts to the Opera browser. We’ve been dealing with small inconsistencies in how that browser handled our method of font serving, but it’s been resolved with changes on our side and the release of Opera 10.6. To upgrade your site, just sign into Typekit and republish your kit.

The change is especially poignant for us, since it was Opera’s CTO Håkon Lie who re-ignited web typography with his seminal article, “CSS @ Ten: The Next Big Thing” in A List Apart nearly three years ago. In it, he asked what many of us had been thinking for a decade, “But shouldn’t web designers have access to a wider selection of fonts and be able to use them without having to resort to creating background images?”

It’s been a lot of work to achieve that vision, and it still feels like we’re just getting started. Our Opera support, for example, doesn’t yet include the Linux version and we’re still working on adding screenshots to our specimen pages. But we’ll continue working on not only those features, but also our goal of getting beautiful typography onto every page on the web.