The navigation text to the left (←) is rendered using its namesake method. To check the pre-render behavior of each, clear your cache and reload the page.
A couple of notes: This page will only render correctly in firefox 3.5 or above, any webkit browser, or IE7/8. It looks pretty jacked up in IE6 at the moment, but most of these techniques should work in that browser, with some cajoling.
The demos on this page are set in League Gothic, a font released under the SIL Open Font License by the League of Movable Type.
sIFR (scalable inman flash replacement) has been around for a while and is sort of the granddaddy of font-replacement techniques. It utilizes fonts embedded in a .swf in conjunction with javascript to render the text. You basically open an .fla file, change the font in the textfield, export the swf, and then edit the sifr-config javscript to point to the swf, and choose which DOM elements to target.
sIFR has served designers well for headlines or short passages of text, but not for body copy as it can be extremely slow to render. In addition, development of sIFR3 stagnated in early 2009 as some influential figures in the web design and dev community have declared sIFR dead in favor of the more the modern, faster, canvas-and-VML based cufón.
sIFR does look consistent cross-browser and cross platform, as it is rendered in the flash plugin.
pre-render: sIFR can take a while to load and render and can leave a blank spot on the page until it's finished.
Below are some screen shots of sIFR-rendered text on different platforms in different browsers:
Cufón uses a web-based 'generator' (which is basically a FontForge interface) to render your chosen font in SVG, which then gets converted to JSON. The JavaScript-based renderer then reads the font's .js file and then renders it using one of two rendering engines (one for canvas-enabled browsers, and a VML engine for IE). Cufón is considered by most to be preferable to sIFR, due to it's ease of implementation, non-reliance on flash, and almost 4-times greater speed.
Cufón is fast, but it's not meant for large bodies of text. It does take css styles – including css3 properties like text-shadow and rgba colors. It also does accept hover states, though for performance reasons, that feature is turned off by default. You just have to specify hover:true in the options object when you're calling Cufon.replace()
Cufón, as it doesn't rely on the operating system or the browsers for hinting or anti-aliasing, renders text pretty much the same in all browsers.
Pre-Render: Cufón does not show the content until it's replaced by the canvas elements, except in IE, where you can get a flash of unstyled text. This is easily solved by putting Cufon.now() in a script tag just before the closing body tag
UPDATE: Google has just announced their font api for loading fonts from their open source font directory. In addition they've teamed up with TypeKit to release the WebFont Loader JavaScript library to help control the behavior of font loading on your page. Very cool!
The @font-face declaration is actually part of the css2 spec (published in 1998), which makes it a web standard for font embedding. Barriers to it's wide adotion have included proprietary browser support for different font formats and font-foundries' resistance to font embedding (which allows the user to freely download the embedded font). Recent advancements - including Paul Irish's bulletproof @font-face syntax, and the font squirrel @font-face generator have made cross-browser @font-face implementation technically easier, but most font licenses still don't allow @font-face embedding. Hosted services such as Typekit provide a solution for this (obfuscation and javascript serving of the source font), but the selection of typefaces is limited and the monthly cost can be something to consider.
@font-face is good for body text as well as headlines, as it is real, rendered text, rather than some sort of replacement trickery. It's fully selectable and stylable with css.
It's important to keep in mind the rendering differences for different font methods in different browsers on different platforms. Some fonts have not been hinted for screen use, and can therefore look pretty bad at body-text sizes.
In addition, IE7/8 will apply ClearType rules, which can make embedded fonts at large sizes look craggy and sharp. here is a blog post that describes how to deal with that problem. As always, it's a good idea to make sure it works with each font. Heres' a blog that talks about the problems with font rendering on different platforms.
pre-rendering: Text using @font-face embedded fonts behave differently on different browsers while the font is downloaded. In webkit browsers, the text will not appear until the font is retrieved by the client. In firefox, the will be a flash of the text in a fallback font before it's replaced with the new font. Paul Irish has a great article about how to deal with it.
Below are some screen shots of text rendered on different platforms in different browsers, using different methods:
The following are live text demos set in the methods labeled
Type in some sample text below to see it rendered in the different web font options in League Gothic