When someone wants custom fonts in content what do you suggest?

[Ryan]

This has been bugging me all evening, but I eventually remembered the other common tool used to load fonts, FLIR, which stands for Facelift Image Replacement.

http://net.tutsplus.com/tutorials/ph...ish-with-flir/

I haven't found it as good as SiFR or Cufon though. It's dog awful at handling rollover links too.

[film_girl]

I wrote about this last week: http://mashable.com/2010/05/27/type-and-the-web/

Typekit, the new Google API and Kearnst, Fontdeck and a few others are the most cross-platform friendly. Cufon and SiFR have their own issues but they work in a pinch. I'm partial to Typekit myself, though Fontdeck's solution is slick. Monotype is also expanding it's web licensing options which means the bigger (Monotype is the biggest) foundries are finally coming around. I actually have a call with them tomorrow morning.

[Ryan]

Just to clarify in case anyone has misunderstood, there are four main methods suggested here:
Cufon
SiFR
FLIR
@font-face



Typekit, Google etc. are just places to get fonts for use with the @font-face CSS rule.

[Otto]

All modern browsers support the font-face method in some fashion. I'd not bother with any other approach.

Personally, I like Google's API best because of the sheer simplicity and speed of it. However, if you wanted, you could implement font-face locally and remove that dependence on Google's servers. Just make sure to provide both EOT and TTF versions of the font. How to do this is explained pretty well here:
http://randsco.com/index.php/2009/07/04/p680

[film_girl]

Google's method, which is basically just Typekit Events (Typekit made Events open source and it is the basis for the WebFont Loader API) can also be implemented by other type services too. I spoke to Monotype at length this morning and they told me they just committed a change to the WebLoader API project to also support Monotype's Fonts.com WebFonts service (currently in beta but open for everyone) and they expect that all the others services will follow suit.

Also, to correct Ryan a bit -- Typekit, the Google Font API, Fontdeck, Kearnst, etc. aren't just places to get fonts -- that's part of it, sure, but you could use the CSS3 @font-face declaration and either embed or link to a font anywhere. What those services do is also offer a way to provide cross-platform support, as the overall standard for embedded web fonts is still being debated. WOFF is likely what the W3C will choose and everyone, even Microsoft, will be on board. However, until that time comes, using methods like Google or Typekit can overcome a lot of the technical barriers that previously prevented @font-face from taking off back in the CSS 2.0 days.

Cufon, SiFR and other implementations are usually more resource hungry and they actually degrade some of the font files, which means that kearning, hinting and other display issues are often not ideal. Using @font-face is the way to go, declaring a suitable alternative for IE 6 and other browsers that are behind the times. From an accessibility standard, it's superior too.

[norcross]

Personally, I've always wanted to avoid any 3rd party APIs and javascript whenever possible, since it seems to add bloat where it isn't needed. For the sites I've developed, I create a separate stylesheet called 'typography' and set all my custom fonts there. I use font squirrel to handle the file conversions (of fonts that have the proper licenses, of course) and then have them all in my local WP install. One less thing to worry about.

[norcross]

Using @font-face is the way to go, declaring a suitable alternative for IE 6 and other browsers that are behind the times. From an accessibility standard, it's superior too.

Keep in mind that IE has supported font embeds since IE4 (using the .eot filetype). That's probably the 1 thing IE has done right from the beginning.