Font Hybridization in HTML 5

Over this Christmas break, I was over at a friends house and got to sit down and tinker with my friends Mac. I’d forgotten how good fonts look, and I suddenly realized why so many sites are now using custom web fonts. Since I primarily use Windows at work and at home, I get annoyed by fonts that are difficult to read or that don’t render well on the screen. Somehow, I’ve never been 100% happy with font rendering on windows. It’s been getting better, but it’s still not as good as a Mac is. Maybe its the screen, maybe its the OS, maybe its the app, maybe its a combination of all of the above. Because I’ve been on this HTML kick, and I’m on windows, I’ve tended toward Cufon as my font replacement tool of choice when building sites since it’s the only one that produces a “more-reasonable” output on my machine.

But Cufon by it’s nature has several drawbacks. First, you can’t copy and paste text rendered with Cufon. With most of the newer browsers you can select it, but there’s not much more you can do beyond that. So, I usually limit Cufon usage to titles, headers, and the more “design-ery” aspects of a page. Second, because Cufon is image based, if someone zooms in on your text beyond 100% Cufon rendered text gets all fuzzy the same way it would if you zoomed in on an image. And finally, because Cufon renders with javascript on the client, there’s no way to cache the text. Javascript is fast, but when you’re rendering a large amount of text on a phone, there’s usually not a good way around a flash of unstyled content. And it happens each time you go to a new page because it can’t be cached.

Web fonts on the other hand, allow you to use fonts in a very similar manner as if you had them installed on your device with native rendering by the OS. You can select, copy, paste, and use it as you would any other piece of text. Web fonts are cacheable, so although you could get a flash of unstyled content when you first visit a page, subsequent visits should render immediately. The disadvantage however, is the OS. On windows, the rendering of fonts just… Sucks. So people don’t use it.

But what if there was a way to do a hybrid between Cufon and Web Fonts?

Besides the rendering issue, Web Fonts are the best option. They’re the most flexible and the most future proof. But they still suffer on Windows, some phones, and on older browsers that don’t support the new @font-face CSS syntax. So what if we did a hybrid? Use @font-face, then fall back on Cufon for older browsers, and for windows. The advantage is that on a new browser the@font-face‘s will be cached, used for the initial rendering of the page, and then cleaned up with Cufon later.

Using Modernizr and a little custom javascript to do user agent testing I put together a page to test out the hybrid font idea:

http://www.paulrohde.com/demo/cufon-hybrid/demo.html

It’s a rough draft. I have some screen shots below from both Mac and PC’s (click for full size versions).

Mac

PC

For simplicity, the javascript code to test and load Cufon and my custom cufon polyfill looks like this:

function rendersNiceFontface() {
	result = navigator.appVersion.indexOf("Win") != -1 
		|| navigator.appVersion.indexOf("Android") != -1;
	return result;
}

var supportsNiceFontface = !rendersNiceFontface();

Modernizr.load([
	{
		test : Modernizr.fontface && Modernizr.canvas && supportsNiceFontface,
		
		nope : [ 'cufon-yui.js', 'BebasNeueRegular_400.font.js', 'cufon-polyfill.js' ]
	}
])

Using the Modernizr yepnope.js, I’m able to completely skip loading Cufon at all if the browser supports good @font-face rules. There’s more that I’d have to do to clean it up before I’d use it in a real setting, but it demonstrate the concept, and is something I could definitely use later as a @font-face polyfill. It does have some drawbacks though, you have to maintain both your CSS rules and your Cufon replacement calls, and Cufon doesn’t work well with a large amount of body text, so if you don’t support @font-face, I’d fall back to a good secondary font and forgo Cufon in those cases.

I hope this got some gears turning, I’m looking forward to some comments.

Fonts and the Web

Here at InterKnowlogy, we get time each week to tinker and dive into technologies that interest and inspire us. We call it RECESS, which stands for Research and Experimental Coding to Enhance Software Skills. This week I’ve been noticing sites ‘sprucing it up’ by using custom font embedding with services such as TypeKit (Or similarly related projects such as Google Web Fonts) that allow you to license and use custom fonts in a site.

There’s a problem though. 90% of the time it annoys me.

Let me explain. First impressions are everything, and right after first impressions is readability. If I come to your site looking for information, to read something, I don’t want to get a headache doing so. The problem isn’t the design or the font itself usually, it’s the way the browser deals with and renders the font. Using a custom or weird font for the body text of the page WILL bother people. Its why standard fonts exist and are as popular as they are: readability. Now, that being said, there are really good design reasons to want to use custom fonts in a dynamic content driven site to augment the design. Especially in the title and headers since it will catch someones eye and because people spend a minimal amount of time reading them anyways. Whatever the reason, if your going to go down the custom font path its going to be important to refine and choose a solution that is going to be consistent and usable for the people that visit your site.

Coming back to RECESS, I spent some time examining the different offerings and essentially broke them into two categories: Browser/OS rendered text, and Image rendered text. Let me explain: For the Browser/OS rendered text (which TypeKit and Google Web Fonts use) the text is set using normal CSS rules, and then an actual font file is loaded by the browser and used to display the text. Almost exactly how text is displayed for application on your computer except that the font is never ‘installed’. The advantage is that it behaves exactly like normal fonts, you can type, select, copy, and do all the normal things you do with text. The second way is imaged rendered text, taking some chunk of text and turning it into an image that gets displayed in place of the text. Designers sometimes do this for logos and main headers that almost never change because it doesn’t require the use of a more modern browser and they KNOW that it will display the same way. Also in this category is a tool called Cufón. It’s a bit of JavaScript and a bit of a generator. It basically takes a font file, turns it into a bunch of shapes, and then on the users computer it uses JavaScript to load, render, and replace text in the page with those images. The disadvantage being you can’t select and copy the text in the same way, but the advantage is that it looks consistent and renders well.

I decided to tinker with these and see what I came up with (All screenshots are on Windows 7, the IE9 ‘font’ example is invalid as I would have had to convert it to a different format for it to display, but I was lazy. There is another example later that illustrates IE9 correctly showing a font this way.)

So here are some screenshots of the results on different browsers on Windows 7:

Chrome 12:

Firefox 6:

Safari 5.1 on Windows

Internet Explorer 9

I was surprised at the results. Same font, same file, but completely different results between Chrome / Firefox / Safari (IE9 excluded obviously) for the regular font rendering. Cufón came out the most consistent of all of these.

Next I went to TypeKit and found excellent illustrations of why embedding fonts is still so difficult and why I’m seriously considering using Cufón for the time being:

From top to bottom, Safari 5.1, Chrome 12, Firefox 6, IE9

The big thing to note is how jagged the letters look until you get to IE9. Readability wise, I would NOT consider using an alternate font for a large amount of text unless I had to, and for right now, Cufón seems a very viable choice for consistency.

There’s no final conclusion in this, since you will have reasons that will drive you to one option or another (Or simply throw your hands in the air and announce to the world that you are done with the web forever) So:

Nerd out.

Tinker.

Be careful with your font choices and how far you take this on a site that will be used on a regular basis. Cheers!