BACK TO BLOG

Jul 05, 2010

Exploring The Google Font API

Posted by: SethG

As a studio that does both print and web design, we have always wished for greater variety in the standard font options for web work to add to our creative toolbox. In the past year with the launch of new services like the paid TypeKit service and Google’s free Font API there are some exciting technology options that extend the library of available web fonts to an ever increasing amount of web browsers. These are not the first solutions to address web font choice. To name two, we have built Flash sites and experimented with techniques like sIFR which is very focused use of flash to dynamically render text in various fonts; however Typekit and Google’s Font API feel fresh due their ease of use and ability to degrade gracefully for those browsers that don’t support the required technology. We recently had the opportunity to put Google’s Font API to the test and though there are some notable issues that we will share, overall we were pleased with the experience and result.

Google recently released their Font API offering a small set of freely available fonts. Our team was excited to try it out and see how it works. The Haus (formerly know as Stray Dog Music) is a long time client of ours that recently reached out to us to do a relaunch of their website to coordinate with their rebranding effort. The goal of this site was to have a very simple, minimal look. So to balance that while providing a unique style, we felt it was important to choose a font that had a presence beyond the standard Arial, Verdana, or Times options. Our concept for the design worked nicely with one of Google’s available fonts. After some initial prototyping and research, the technology looked promising and after our production, development and testing it made it into the final launched site at http://thehaus.tv. Here’s a bit of how the technology works.


We used the Yanone Kaffeesatz font on details like the sub navigation in lower left and in the entry title type treatments.

At it’s core, the Google Font API hosts the font files on their servers and takes advantage of the font-face CSS property to load the font data and apply it to selectors (Header text, body text, ....) specified in the site code. For those browsers that do not support font-face, you can specify a default set of standard web fonts to load. For specific details on implementing the API, Google’s documentation is very clear and easy to follow, so we’d recommend you go to the source.

Like a hosted javascript or graphic, Google’s fonts need to be downloaded from a server. Standard web fonts like Arial do not, they are loaded directly through the web browser/operating system (not sure exactly of the magic there, but you likely are following me). There are two ways hosted fonts can be loaded. You can specify a google hosted style sheet for the font or use a javascript library called WebFont Loader which was co-developed with TypeKit. We chose the latter as it offers a little magic to make IE work like Firefox and other browsers in a very important way.

Internet Explorer will not display the desired type until the web font is completely downloaded. Firefox on the other hand, will display the default (backup if you will) font right away until the downloaded font has completed and then it dynamically replaces the default font with the desired one as specified. The WebFont Loader library helps IE to behave like Firefox to make sure type is displayed even if there is a delay in the font loading. In our testing the loading of the font we used was pretty quick and Google claims to have a number of behind the scenes optimization and caching activities to make this happen. So this is a con for which there was a solution and thankfully so, as this would have been a clear deal breaker issue.

So what are some of the other cons? Here are a couple we observed.

• Using the WebFont Loader and based on Firefox’s behavior, there is an occasional flicker as a site renders once the desired font is downloaded and replaces the default. We noticed this during our browser testing and I would imagine that a reason we did not see this all the time was due to the font being cached locally and/or Google’s serving technology.
• The biggest issue we encountered is specific to Windows for those whom do not have ClearType font smooth enabled. Frankly, traditional standard web fonts don’t look so hot without ClearType smoothing enabled and certainly some more intricate and curved fonts like the one we used in our project suffered. I am not sure what the percentage of users is that do have ClearType font smoothing enabled. It is my understanding that is it off by default in Windows XP and on for Vista and Windows 7. So the trend is in our favor, but there are certainly many XP users out there. I can only hope for the improvement in the aesthetic of XP user’s web browsing experience alone, that they all took the time to make the change.

With these potential issues being known, there were more pros that made the technology a viable one and that landed it as part of our final solution than cons. The use of the font served by the Google Font API allowed us to add a bit of style through type to what needed to be a simple and refined visual presentation. In addition many instances of the rendered type needed to be served dynamically by a CMS which made type graphics in these cases not a viable option. Also, the use of this font was very affordable both in terms of not having to pay for a font license or research whether a desired font can be licensed for web use regardless of cost (Google’s fonts are free to use) and because the effort/resources required to implement the feature was small.

It was certainly nice to have this additional tool in our tool box and we are happy with the results of our initial implementation with it.

Tweet

Design MOD-Lab Project Technology