Update: The desktop font sync feature is rolling out in limited batches. Read our update to learn how to sign up for early access.

Last month, Adobe announced a bevy of new Creative Cloud software and features. As part of those announcements, Typekit showed a sneak preview of a new feature we’re working on for syncing fonts from Typekit to your desktop through Creative Cloud.

Today, Adobe announced the launch of the new suite of CC applications and many new features. We hoped that the desktop font sync feature would be ready for today’s launch, but we need more time to get it right. This feature represents the biggest change to the Typekit service so far, and we’re working to ensure that it’s a great experience for everyone. We apologize for the delay.

If you have any questions, you can reach us at support@typekit.com. We’ve also published a desktop font sync help page to answer some of the common questions we’ve been asked since the initial announcement.

Update on June 24, 2013

On behalf of the whole Typekit team, we’d like to reiterate how sorry we are to have let all of you down with the delay of desktop font sync. We’d like to share some more details about the issues we’re working through that we hope will be helpful.

The bulk of the work on the desktop sync feature has been complete for some time. Both Jeff Veen’s demo at MAX and the screencast by Ben Welch were done using a working version of the font syncing service and desktop client. The problems preventing us from shipping the feature have to do with deploying and supporting it at scale. Adobe’s worldwide community is huge, and we expect hundreds of thousands of simultaneous users for desktop font sync once it’s released. We’re working hard to handle that much traffic at the high level of quality and stability you expect from Typekit.

Unfortunately, we failed to reach our scaling milestone before the original June 17 target. Because desktop font sync relies upon Adobe’s file sync platform, which is not yet ready, we can’t give a firm estimate. It’s safe to say that it will be longer than a week or two.

If you purchased a Creative Cloud membership or standalone Typekit subscription after 7 May 2013 in order to use the desktop font sync feature and are dissatisfied, we’d like to help. Please email our support team at support@typekit.com.

We’re excited to bring Typekit to your desktop as soon as we can. Please stay tuned to our blog and Twitter for updates.

At Typekit, we believe in respecting the privacy of our our customers and their website visitors, while providing the best font service possible. Recently, we’ve received some questions about what kind of data we gather from individuals and how it’s used. To help answer these questions, we created a Typekit-specific supplemental privacy page. We hope this adds clarity about the kinds of data we gather and why. You can also read our main privacy policy for information beyond Typekit’s use of cookies.

The most common privacy question we hear from our customers is, “If I use Typekit fonts, does Typekit gather information from or set cookies in the browser when people visit my website?”

To quote the privacy policy:

“In providing the Typekit service, we do not set or use cookies on websites in order to serve our fonts.”

Typekit makes a point not to track visitors on websites that use Typekit fonts. However, we do collect information about the fonts being served to each site. This data does not include any information about the users who are visiting a site serving Typekit fonts. The tracking data is used to operate the Typekit service, as well as accurately pay our foundry partners.

We want to be as clear as we can with our users and hope you find this information helpful. As always, you can email Typekit support with any questions or concerns.

We’re happy to announce a new partnership with Storify, a platform for curating social media posts and turning them into stories that users can easily share and also embed directly into their own websites. Storify is used by major news organizations like CNN, The New York Times, and The Washington Post, by government and non-profit organizations such as the White House and the United Nations, and by brands of many kinds.

Now, Storify Business users can apply Typekit fonts to embedded stories, giving you more customization options and allowing you to maintain a consistent brand identity by matching your website’s fonts exactly.

To use Typekit fonts with your Storify Business account, add a kit ID from your Typekit account to the Embed Style settings in your Storify account.

storify-typekit-kid-id-setting

Then, select your Typekit fonts from the Headline and Body menus.

storify-typekit-fonts-setting

Storify has provided detailed instructions here.

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.

We’re excited to announce that Elliot Jay Stocks is joining the Typekit team as our new Creative Director. We’ve been working with Elliot since the beginning of the year, and we’re delighted to make things official.

ejs_typekit_blog

Elliot will be working with us to brainstorm product direction, design new features, and serve as the steward of Typekit’s visual identity. You may know him as the founder of typography magazine 8 Faces. He’s an incredibly talented designer with a special passion for typography. We’re fortunate to have him with us as we continue to build Typekit.


Elliot wrote about the new role on his blog; read more about it in his own words.

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.

The Basic 4 Styles of Chaparral rendered in IE9 using IE8 Browser Mode
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.

The Basic 4 Styles of Chaparral rendered in IE8
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 consistent 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.

benino-sample
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-sample
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.

glyphs
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.

Update on Monotype fonts

February 20, 2013

We will not be able to offer Monotype fonts for the foreseeable future; please read the Monotype fonts not coming to Typekit as announced blog post for more information.

The original blog post, while no longer relevant, is available below.

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.
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.
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:

Squarespace Style Editor

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:

Kit ID setting

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.