The Typekit Blog

It’s 2013; we’ve come a long way. But there are no jetpacks yet, and we still have to test websites in older versions of Internet Explorer. While many of you probably haven’t had to open IE6 in a while, IE7 and IE8 are still with us. At Typekit, we still test our web fonts in all three (along with all the other major browsers), but today we wanted to discuss a potential testing pitfall that some of our customers encounter.

IE9 has a feature called Browser Modes that attempts to simplify cross-browser testing by emulating how a site would render in a real copy of IE7 or IE8. It’s available within IE9’s Developer Tools. While it’s a good idea in theory, in practice these emulated Browser Modes create more trouble than benefit because they behave differently than real copies of IE7 and IE8 would. In the case of web fonts, the differences in behavior are drastic, and can lead to inaccurate and misleading conclusions about what your page and web fonts will look like in these older browsers.

Here’s an example of one way that IE9’s Browser Modes for IE7 and IE8 are completely different than the real thing when it comes to web fonts. When loading Typekit fonts on a site, we use @font-face under the hood. If more than one weight or style of a font is present, each one is listed in an individual @font-face rule, each with the same family name but different weight and style values. In actual copies of IE7 and IE8, as well as all other major browsers, the order of the @font-face rules for the various weights and styles in a family should not affect how that family renders in the browser.

However, when using IE9’s Browser Modes to emulate IE7 and IE8, IE will pick the first @font-face rule in the stylesheet and use that weight and style for all text on the page set in that font family; regardless of the weight/style CSS declarations that are applied to the elements on the page. One common symptom of this is seeing lots of text in the italic style instead of the normal style, since “italic” is alphabetized before “normal” and we include the @font-face rules in alphabetical order.

Below is a set of screenshots taken of the same test page, which features four weights and styles of Chapparal. Although the markup is exactly the same, the rendering in IE9’s IE8 Browser Mode and an actual install of IE8 are very different, as you can see.

Chaparral Basic Styles: IE9 using IE8 Browser Mode. Testing with this Browser Mode, the normal styles of Chaparral appear italicized because of a rendering error in the IE8 emulator. Also, the bold weights shown here are faux-bold created by the browser instead of using the actual Bold and Bold Italic of Chaparral.

Chaparral Basic Styles: Installed IE8. Testing actual IE8, the normal styles show up as expected and the bold elements are using the actual Bold and Bold Italic for Chaparral. Much better.

On a related note: We’ve seen some sites using X-UA-Compatible meta tags to force more recent versions of IE to use one of these older emulated Browser Modes. This is a bad idea, as you’re opting all of your visitors that use IE into the the same buggy rendering that you would see while testing.

Older versions of IE have some interesting bugs when it comes to web fonts, but we shouldn’t add to them by using imperfectly emulated Browser Modes in IE9. To ensure that your sites look their best, we recommend that you avoid using IE9 Browser Modes as a cross-browser testing tool. Instead, you should test with real installed copies of IE7 and IE8, or try using a service like BrowserStack that can run real copies of those browsers for you.

Update: Several users have suggested modern.IE as a resource from Microsoft with tools and advice for testing sites in IE. We checked it out and it has some good information as well as a special offer for 3 months free testing with BrowserStack.

Yesterday, 5 March 2013, from approximately 12:00 PM PST to 12:43 PM PST, our font serving network experienced a widespread outage for users around the world. This outage affected users of the Typekit hosted service; Typekit Enterprise customers using CDN Integration were not affected.

The downtime resulted from the deployment of a change that updated the sorting of font names in CSS URLs, causing all CSS files served by Typekit to fall out of cache simultaneously. We anticipated this and were ready with additional capacity, but a problem with our load balancer caused a vicious cycle of slow and failed requests that took time to recover from.

Eventually, by bringing up even more capacity, increasing the frequency of health checks between the load balancer and the individual web servers, and giving the load balancer time to adjust to the sudden spike, our infrastructure was able to recover. More and more responses were served and cached successfully. Most Typekit customers and their visitors saw request times and error rates return to normal by about 12:43 PM PST.

A follow-on issue: Incomplete CSS files

A few hours after the initial outage, we received reports of lingering issues, and were able to identify a related problem: some users were receiving incomplete CSS files, which were missing crucial font data. These files had been unexpectedly cached by our content delivery network (CDN) during the outage. This second issue wasn’t nearly as widespread as the original outage, but it was very difficult to isolate and fix, and it continued to cause problems with loading fonts on some sites until approximately 9:28 PM PST, when we completed a gradual rollout of a fix.

We now believe the problem has been completely resolved, and service is restored to all customers.

Next steps

We learned a lot from this outage and the resulting issues. We’re going to put that knowledge to good use, and make our font serving system even more robust. Here are just a few of the changes we’ll be making as a result of this outage:

• We’ll roll out large changes like this gradually in the future, to mitigate sudden traffic spikes that could cause instability.
• We’ll properly prepare our load balancer for any expected traffic spikes or surges when they can’t be avoided.
• We’ll work with our CDN provider to determine why incomplete responses were cached as if they were successful and complete.

We know that uptime is critical to our customers, and we sincerely apologize for the interruption in our service yesterday. As always, if you’re having any trouble at all with Typekit, you can reach our support team at support@typekit.com.

Every day, our customers write us asking if we can add specific new fonts to the Typekit library; it might be a font that they’ve chosen for a project, that is part of their corporate identity, or that they’ve custom-designed for a client. We love hearing these requests from you, since they help us understand which foundries, designs, and designers are most popular with our customers, so please keep them coming!

We’re continually working with new fonts and foundries, and in this post we wanted to share some of the details with you about what’s involved when we add a new font to the Typekit library.

Licensing

The most important obstacle between you and your new font is licensing. Before we can offer a font via the Typekit library, it must first be licensed to us by the issuing type designer or foundry. The foundry must first agree that they want their fonts to be available this way, and then work with us to create a license agreement that works for both sides.

Today, more than 60 major commercial and independent foundries have license agreements with Typekit. These relationships make it possible for us to offer one of the broadest and most diverse libraries in the industry. However, the individual attention that must be paid to each of these agreements can make them time-consuming to complete.

Many people assume that if their company has already licensed a font for use in their branding, they already have the license they need to use the font on the web. This usually is not the case: most commercial desktop font licenses do not permit the licensee to use the font on the web.

Specifically, many licenses prohibit the licensee from redistributing any version of the font file to a third party, or from putting the font files on servers accessible to the general public. Any commercial web font service must be certain not to run afoul of those requirements when preparing fonts for use on the web.

Font processing

Many of you are familiar with free or open source tools that convert standard desktop files into the formats used on the web, or with web fonts services that allow you to upload your own fonts directly. While we do use some of these same open-source tools for font processing, the results they produce on their own are very different from what you’ll find in the web fonts we select for inclusion in the Typekit library. In addition to licensing issues, the reason Typekit doesn’t offer any facility for end users to upload their own fonts is simply because we haven’t found an automated process to dependably produce results that measure up to our own standards.

Our font processing pipeline also depends heavily on the careful evaluation of each font variation by our Type Team throughout the conversion process. Here are some of the main issues that we deal with when processing fonts:

• For file size efficiency, we rebuild fonts so that reusable parts (like accents that appear above many letters) are only present once. This is called componentization, and it involves editing glyphs’ bezier outlines. Outline editing is also occasionally required after format conversion from PostScript to TrueType (or vice-versa), to ensure design fidelity.
• We sometimes contribute PostScript hints and, if a typeface was made for use at text sizes, TrueType instructions. These adjustments dictate the rasterization of font outlines on screen.
• To be sure that fonts have proper semantic value, we remove or reassign glyphs that have incorrect Unicode code points. We also add common missing glyphs like nonbreaking space and soft hyphen, and work with our foundry partners in cases where essential characters are absent.

Browser testing

We understand how important it is for visitors to your sites to have a consistant experience across different browsers and devices, but even with the very best processing and the closest attention to detail, font rendering will always vary from one platform to the next. This is why we’ve made such an enormous investment in our Browser Samples system, which we recently updated and described.

In addition to demonstrating how a given variation will look across a variety of devices, this engine also gives us an incredibly powerful means for revealing rendering issues that might only show themselves in the context of a specific combination of font variation, browser, and operating system.

From left to right, JAF Bernino Sans Regular in IE6 on Windows XP, IE8 on Windows XP, Chrome on Windows 7, and IE9 on Windows 7.

On Windows, type rendering quality often depends on the success of TrueType hinting, which we measure by the legibility of rasterized letters and by their faithfulness to the typeface outlines. But Windows rendering also depends on the operating system’s active rendering engine, which can vary by OS version, browser, and browser preferences. So it’s critical that we study hinted TrueType fonts in a variety of Windows scenarios.

Freight Text Pro Book at 16px in Chrome on Windows XP: above, without smoothing; below, with smoothing enabled.

Font files contain a ‘gasp’ (Grid-fitting And Scan-conversion Procedure) table that controls the sizes at which smoothing is enabled in Windows GDI Standard rendering scenarios. Browser samples have shown us that disabled smoothing often results in poorly aliased text, so in general we apply smoothing at all sizes. This is especially important for the display fonts we serve with PostScript-based outlines, because they trigger GDI Standard rendering in many Windows browsers.

On the left, a blurry top edge; on the right, reducing the size of glyphs within their em box produces a more crisply rasterized shape.

Mac OS X ignores TrueType instructions, so the only way to control the way glyphs are rasterized is to change the shape of the outlines themselves. In a few cases, we have adjusted fonts’ outlines to avoid blurry edges at key font sizes in Mac OS X browsers.

Why we do all this

We put more time and effort into font processing than any other service we know of, and we do it so that we can be assured that we’re not compromising on quality. It’s important to us that we empower our customers to focus on designing with inspired type, without worrying that their end users might see something subpar as a result of poor quality control. We’re continually blown away by the amazing sites people build with Typekit fonts—in fact, we keep talking about them!

Our end of the deal is to make these fonts the absolute best they can be when we add them to our library. We can’t wait to see what you’ll do with them from there.

On September 24 of last year we announced that we’d completed a partnership with Monotype, long in the works, that would allow us to offer more than 1,000 of their most popular web fonts via Typekit.

At the time we said that these fonts would be “coming soon” to Typekit. Clearly, we have fallen short on that promise. We’d like to explain what’s going on with this product and why there’s been such a delay.

It’s a big subject, so we’re splitting it into two posts. Today we’ll share what we can about the Monotype update, with the goal of enabling you to make the best decision about when and how to use Typekit going forward. In a forthcoming post, we’ll provide more detail on how fonts are added to the Typekit library, in terms of licensing, font processing, ensuring browser support, and more.

Our progress

At the moment, we expect that we’ll be ready to make the Monotype library available to you by summer of 2013. We realize this is a pretty broad timeframe, but unfortunately that’s as precise as we can be right now.

Making the Monotype library available through Typekit is a complicated project. Coming to a licensing agreement with Monotype was a big part of that work, and our excitement in that accomplishment is what led us to make our pre-announcement.

The balance of the work involves preparing the fonts using Typekit’s web font processing engine, and making them easy to find and use in the Typekit library. This turned out to be an even bigger job than we anticipated. Even though it’s well underway, it continues to share resources with other big projects that are also extremely important to our customers. Monotype has been a patient partner as we work to resolve these issues.

Another issue is structuring the plans and pricing for this new offering. We mentioned in our announcement that Monotype fonts will be offered as an upgrade. While some people interpreted this to mean that Monotype fonts would be included with their existing subscription, we want to clarify that this isn’t the case. There will be a separate charge in addition to your Typekit or Creative Cloud subscription.

This arrangement is the first of its kind for us, so it also requires significant changes to the architecture of our billing and payment systems, which comes with some engineering complexity that we didn’t fully appreciate when we made our announcement.

We’re sorry

In comments on the blog, on Twitter, and in your emails to us, many of you have let us know that you’re frustrated and disappointed by this delay, and we want you to know that we’re sorry we let you down.

We announced our partnership with Monotype too soon—we should have waited until we were ready to commit to a delivery date. By saying that it was “coming soon,” we realize some of you may have made plans to use Monotype fonts via Typekit in your upcoming projects, and we didn’t mean to steer you wrong.

Also, while our announcement said that the Monotype fonts would be made available as “an upgrade to any Typekit plan,” we’re concerned that we may have left you to assume it would be included in your current Typekit or Creative Cloud subscription, instead of an additional subscription at an added cost.

We especially regret waiting too long to share more information with you. To that end, for any customers who chose to buy a Typekit account based on our pre-announcement, we’d like to offer your money back. If you bought a Typekit account since the date of our announcement (September 24, 2012) through today, and you choose to cancel your account any time in the next 30 days, just write support@typekit.com and request a refund.

Thanks for your patience and understanding, and thank you for using Typekit.

Today, BlackBerry (formerly known as Research In Motion) officially launched their new BlackBerry 10 operating system for mobile devices. It includes numerous improvements over the previous version, but here at Typekit, we’re most excited about the new web browser. Built on top of the WebKit rendering engine, it brings support for the standard WOFF web font format to BlackBerry devices. We’re celebrating this advancement by announcing official Typekit support for BlackBerry 10 and up.

Screenshot of Typekit fonts rendering on a BlackBerry 10 device.

BlackBerry joins iOS, Android, and Windows Phone as the fourth major mobile operating system with support for WOFF, further boosting the share of mobile devices that have support for web fonts and the latest web standards.

In order to get BlackBerry 10 support with your own kits, just head to typekit.com and republish. If any of your kits were published on or after December 15, 2012 (when we first implemented experimental support for BlackBerry 10), then they should already work on the platform without any action on your part.

As with the rest of our supported mobile platforms, we’ve added an option to disable support for BlackBerry in kits. You’ll find this option in the Kit Editor under Kit Settings > Mobile Settings. Uncheck the box for BlackBerry and republish your kit to turn off support. This option is useful if you’re building a site that doesn’t require web fonts to be loaded on mobile platforms, or if you run into issues on BlackBerry and just want to turn the fonts off.

Settings for enabling and disabling support for mobile platforms, including BlackBerry.

As always, if you encounter issues with web fonts on BlackBerry or another officially supported platform, contact us at support@typekit.com and we’ll be happy to help.

We’re delighted to announce a new partnership with Squarespace, the beautiful and intuitive website publishing platform that allows you to design and maintain a professional website without touching a line of code. Starting today, you can use Typekit fonts in your Squarespace site, pairing the quality and reliability of Typekit fonts with the sophisticated style editing tools in Squarespace. This powerful combination makes innovative web design and typography accessible to more people than ever before.

The integration is simple to use. Just go to the Preview section of your Squarespace site, open the Style Editor, click on a text element to bring up its Typography options, and choose a Typekit font to apply:

As you select different fonts, you’ll see your site’s Preview update on the fly. When you’ve found the perfect font, just click Save, and you’re done. That’s all there is to it.

You don’t need to have a Typekit account to benefit from this partnership, but if you do have one and you’d like to use a specific kit from your Typekit account on your Squarespace site, you can do that, too. Just enter your kit ID in the General Settings area of your Squarespace site:

Once you save the setting, the fonts from that kit will show up in the Style Editor’s font menus, where you can use them as described above.

If you have any questions about how to use Typekit in your Squarespace site, just head on over to Squarespace to learn more.

Do you run a platform that would benefit from a Typekit-powered web font integration like the one described here? Drop us a line at support+partners@typekit.com to learn how to get started.

This past Tuesday, 18 December 2012, from approximately 6:00 PM PST to 6:45 PM PST, our font network experienced a partial outage for many users around the world.

Our font network uses a worldwide system of servers run by a major commercial content delivery network (or CDN). Each request for fonts is routed to the nearest server in order to return a response as quickly as possible.

Unfortunately, our CDN provider pushed a bad configuration on Tuesday evening, and a change that was meant for only one of their customers got applied to many customers instead, including Typekit. From our CDN provider’s post-mortem:

The outage occurred as a result of a change we made to a configuration in our core caching platform. It’s important to note that this was not a security issue, or even a bug, but a simple human error that was not flagged by our standard staging and testing procedures.

This mistake resulted in font requests failing, which meant that some visitors saw fallback fonts on sites using Typekit for a period of about 45 minutes. The configuration change rolled out slowly, which meant that more and more traffic was affected over time. Typekit Enterprise customers who use their own CDN environment weren’t affected by the outage.

We have external and internal monitoring to detect problems with our font serving network, but our monitoring didn’t pick up on the growing issue until approximately 6:18 PM PST. At that time, we quickly got in touch with both our CDN provider and our customers (via the status blog and Twitter). At approximately 6:45 PM PST, our CDN provider finished rolling back the bad configuration changes, and font serving was restored to normal.

Requests for fonts failed quickly during the outage, and the fallback fonts specified in each site’s CSS were shown instead. This illustrates one reason why designing and implementing good fallback fonts is important. Not only does it improve the appearance of your site during an unlikely outage, but it’s also important for older browsers that don’t support web fonts.

We know that our customers have high expectations for uptime on our font network and prompt communication about issues and downtime. We sincerely apologize for the impact that this outage had on our customers and their visitors, and our delay in detecting the problem. Our CDN provider has responded proactively to prevent this type of configuration error in the future. At Typekit we’re working to improve our monitoring so we can detect and respond to outages like this one more quickly.

If you have questions or concerns, please get in touch with us at support@typekit.com.

Photo © Jason Santa Maria

The historic Hamilton Wood Type and Printing Museum is being forced to shut its doors, and needs your help in finding and moving its vast collection to a new location where it can open them again. From the museum’s press release:

Hamilton Wood Type and Printing Museum will no longer reside in the building that bears its name. The property owners recently informed the museum that the 1619 Jefferson St. building in Two Rivers, Wisconsin will close and must be vacated, perhaps as early as February 2013. Hamilton Wood Type is urgently seeking donations to address this sudden need and to protect its vast collection of wood type, antique printing equipment and rare type specimen catalogs. The museum’s director Jim Moran, artistic director Bill Moran and assistant director Stephanie Carpenter remain committed to transitioning to a new space. [Read the full press release.]

Hamilton Wood Type and Printing Museum houses one of the world’s largest collections of wood type, with over 1.5 million specimens. Read more about their history and continued efforts in preserving, producing, and teaching about wood type. And check out HWT American Chromatic, a collaboration between Hamilton Wood Type Foundry and P22 Type Foundry, here at Typekit.

Please join Typekit and Adobe in donating, volunteering, and spreading the word.

We have released a new Troubleshooting Guide, which covers common issues that you might run into. Based on the questions we get via email and Twitter, this guide is organized into a concise table of problems and solutions, to help you get your site working as quickly as possible.

Screenshot of the troubleshooting guide.

The guide will continue to be updated as new issues arise or existing ones become obsolete.

If you have any feedback on this new troubleshooting page, let us know in the comments. You can also get in touch with the support team directly with questions or comments by emailing support@typekit.com. We are here to help!

On Monday, Microsoft officially announced their new Windows Phone 8 operating system for mobile devices. It comes with a long list of new features, but we’re most excited about the new web browser: a new mobile version of Internet Explorer 10 that finally brings support for web fonts and the standard WOFF font format to Windows Phone. Today, we’re announcing official Typekit support for Windows Phone 8 and up.

Screenshot of Typekit fonts rendering on a Windows Phone 8 device.

Windows Phone now joins iOS and Android in supporting web fonts on mobile devices. We’re excited about this release because it increases the number of mobile devices that support web fonts and the latest web standards.

We began working on initial support for Windows Phone with Microsoft in July of this year. After collaborating with them to add and test support using developer devices, we launched experimental support to kits published after August 16. Now that Windows Phone 8 is officially launched, we’re making our support for the platform official as well.

In order to take advantage of Windows Phone support in your own kits, all you need to do is head over to typekit.com and republish. If your kits were published after August 16, they should already have support for Windows Phone baked in.

Following the pattern for our other supported mobile platforms, we’ve also added an option to disable support for Windows Phone in individual kits. You’ll find this option in the Kit Editor under Kit Settings > Mobile Settings. Uncheck the box for Windows Phone and republish your kit to turn off support. This option is useful if you’re building a responsive site that doesn’t require web fonts to be loaded on mobile platforms, or if you encounter issues with Windows Phone.

Settings for enabling and disabling support for mobile platforms, including Windows Phone.

As always, if you run into problems with web fonts on Windows Phone or any of our officially supported platforms, contact us at support@typekit.com.