So I've been forced by circumstances into using #font-face on a site I'm developing, and have to say I'm impressed by the cross browser render quality compared to Google Fonts but it does seem to have a heavy impact on http requests compared to Cufon, as you need four variants per font for body copy and sometimes a couple for headings.
I've generally worked with cufon as I've found it to be flexible, reliable cross-browser and mobile, and despite some odd white-space issues on occasion, easy to work with. I've not done much with the Google fonts as the render sucks in some browsers.
Obviously tech has moved on! How do these three differ, are there any serious pitfalls with any of the three?
I think there are two considerations to choosing between #font-face, browser defaults, and cufon.
1. How easy it will be for you to maintain the look of your site using CSS
When using a javascript solution for any part of the site, it's important (to me at least) that the site looks decent with or without javascript. This means if a user clicks 'stop' before the page finished loading, that the type will still be in its place within the design. This means having a fallback using default fonts. I've found this to be really problematic in the past as cufon fonts' line heights can differ drastically from those of regular fonts, making it necessary to write superfluous css to control for these cases plus cross-browser irregularities-- in short, a pain in the butt.
With #font-face, particularly using google fonts or typekit, the fonts are quality picked and display predictably and consitently well (with respect to layout and line-height) cross browser. For example you can switch from proxima-nova back to the default arial with no implications in layout-- I've found this to be a challenge with cufon.
2. How the user will need to interact with the site
I like to be able to highlight text, search for text, and see a text cursor when I hover over text. You can't do that with cufon. If your site is more information heavy, cufon isn't a good choice.
I would say Cufon is a good choice for smaller sites where the aesthetic is of equal importance to the content (as in the content simply won't have the same effect without eye catching typography that your user needs to maintain via a CMS... www.macretailsolutions.com is a site that I did with Cufon that I think falls under this category). Otherwise my opinion is that on both a maintenance/development perspective and a usability standpoint, it sucks.
It's definitely true that Cufon will render much prettier in IE, but the truth is that if people are using IE in the first place, they're not too concerned about aesthetics to begin with.
Conclusion: don't use Cufon.
Related
font-display is a new CSS property that allows developers to control how fonts are rendered depending on if they load quickly enough. There's been a few articles on it:
Controlling Font Performance with font-display - Google Developers
font-display for the Masses
None of them mention icon fonts. The specification does have an example that mentions icon fonts for the block value, but to me it doesn't make sense to use that:
'block'
Gives the font face a short block period (3s is recommended in most cases) and an infinite swap period.
If I understand the specification correctly, this means if the icons haven't loaded after the "short block period", the fallback font will be used, resulting in random letters appearing in their place.
If I use the optional value, the random letters will never appear but neither will the icons if they haven't loaded in the "extremely small block period".
There doesn't appear to be a value for giving an infinite block period without swap (so it would show invisible text until and unless the font loads). Is there a reason behind this and is there a workaround?
font-display: block;
As you commented, block still has a swap period; so it's still rendered until it's loaded.
Quoting Chris Coyier:
Wanna hear something quite unfortunate? We already mentioned font-display: block;. Wouldn't you think it, uh, well, blocked the rendering of text until the custom font loads? It doesn't. It's still got a swap period. It would be the perfect thing for something like icon fonts where the icon (probably) has no meaning unless the custom font loads. Alas, there is no font-display solution for that.
Considering alternatives:
I've also been there. If you have the chance, you might need to switch to SVG for icons. It has a few advantages over font-icons: SVG is better at pretty much everything than icon fonts.
Even Zach Leatherman, web fonts expert, has opinions about it on his very famous Comprehensive Guide to Font Loading Strategies.
This guide is not intended for use with font icons, which have different loading priorities and use cases. Also, SVG is probably a better long term choice.
For my current workflow I use iconic web fonts generated with the Icomoon. It’s a very easy and fun technique with an obvious advantages:
Icon behaves just like any other glyph, so any text CSS transformations can be applied to it in a natural way, like text-shadow, text-decoration, color etc.
Easy reuse, just add necessary font-family to element.
But it has major flaws do not let me sleep.
Font icons are blurry no matter how perfectly its curves are aligned to a pixel grid. Not to mention awful Windows rendering.
It’s hard to add new icons to the font, especially when vector source font is made from is not available and even lost.
It requires bunch of different font versions (woff, eot, ttf) for acceptable cross-browser support.
In the end fonts are not really for graphics at all (especially not monochrome), it seems to not the right way to use dummy empty and non-semantic <span class="icon"></span> for this purpose.
Well, the obvious alternative is SVG, which has no mentioned disadvantages. But has it’s own flaws, which do not let me use it’s easily.
A lot of small files are quite simply not acceptable in our HTTP/1.1 era.
Creating of icon modification is not an easy task and requires manual editing, which is also rather strange for our just-type-npm-install era.
I've googled for some npm packages which hasn’t satisfied me for some reasons.
So, I’m asking your advice how to manage this trivial and routine task. Is there productive and reliable way to generate SVG sprites with modified variations of original icon and bitmap fallback for old browser?
It doesn't make sense to talk about "supporting old browsers" without:
knowing what the majority of your users will be on (which'll be multiple browsers of course), and,
what support for the feature you want to use is for those browsers, for which we can use the handy http://caniuse.com
With that said, this is not going to be an answer so much as an explanation of how all those points you present "against" fonts are unfounded. Answers are great, but in this case we need to set the record straight so you can make real decisions based on facts, instead of (either "never", or "no longer" valid) preconceptions. I spent way too many years of my life working with fonts from an engineering perspective to let you maintain these claims =)
"Font icons are blurry no matter how perfectly its curves are aligned to a pixel grid. Not to mention awful Windows rendering."
This is plain old not true. As vector graphics, if they render poorly, SVG will also render poorly at the same size, although SVG will typically render worse: fonts actually allow for micro-outline-optimizations for dealing with small point sizes (.otf is better at this than .ttf, but the font maker needs to have spent the time to put them in. Pretty much all professional fonts come with that work done), and SVG doesn't, because it has no instructions in its vector graphics language to do so. As such, fonts render either on par with (if they have no optimization instructions), or better than (if they do) SVG.
For example, Font-Awesome comes with outline optimization that allows it to render pixel-perfect all the way down to a font size of 14px, which is already smaller than what browsers use as default size for text on a page (virtually all browsers agree to use a default of 16px serif). If you took its icon set and converted it to SVG, then tried to use those scaled down to match a 14px size, they would look an absolute blurry mess.
Or you can use an icon set that goes further, such as Symbol Set which has explicitly been designed for grid alignment, which means that even at sizes lower than intended, it still renders remarkably crisply.
SVG loses here.
As for Windows rendering, it might look bad, but that's not Windows's fault. Both Uniscribe and DirectWrite are really good at rendering fonts. Like, really good (which may not be a surprise, since Desktop Publishing has traditionally been Microsoft's core business since pretty much its beginnings, although that's shifting). Browsers that hook into them render fonts really well: IE has even supported web fonts since IE4... That's 1997. That's before HTML4 was even a thing, we were still on HTML3.2 at the time.
The problem isn't so much "Windows", as it's "older browser that are not IE, on Windows". Browsers didn't really care about web fonts for a very long time. It's only the last few years that major effort has suddenly gone into making sure they come with good Font shaping engines (like Harfbuzz, which is now used by Firefox and Chrome), and you won't get nice results for Fonts unless you're using a modern version of "not-IE" on a Windows machine.
And then finally a problem specific for "font vs SVG" on Windows and IE: While IE has supported web fonts since pretty much forever, SVG support only landed in IE9, so if you need to support IE8, you can't even use SVG. In the case for this very specific target audience, "fonts vs. SVG" isn't even a question, you have to go with a font.
"It’s hard to add new icons to the font, especially when vector source font is made from is not available and even lost."
No it isn't, you're still using HTML with CSS, so do what we always do when we need "letters not in this font": use font-fallback: font-family: iconfont1, iconfont2, iconetc.
"It requires bunch of different font versions (woff, eot, ttf) for acceptable cross-browser support."
Not for a few years now. These days we do not need multiple sources: caniuse shows us that everything supports WOFF and has done so for a few versions.
Even IE, although if you need to support IE8 you'll have to also find yourself an .eot (which is literally just a ttf file with an extra bit of metadata so IE will accept it... just like WOFF!) and then live with the fact that if this requires a conversion from otf to eot, you're going to end up with a shitty font because it's a lossy conversion (like converting .png to jpg. Excellent conversion software can generate a decent result, normal software will generate a mediocre result).
And because everything supports WOFF, we (thankfully) don't need ridiculous all-encompassing sets of ttf+otf+eot+woff+svg anymore, with a "bulletproof" #font-face rule that tries to optimize load order so not too many files are needlessly loaded - just use WOFF. Done. And in a pickle, add .eot as first source (with format indicator) and everything except IE will skip over it.
It's also worth looking at SVG font support: virtually nothing supports it, and those that do are in the process of deprecating it. SVG fonts as a thing has been discontinued because the results of using SVG fonts turned out to be incredibly much worse than using real fonts, underlining the explanation on point 1.
"In the end fonts are not really for graphics at all (especially not
monochrome), it seems to not the right way to use dummy empty and
non-semantic <span class="icon"></span> for this purpose."
Both of these claims are incorrect.
Fonts are for encoding vector graphics that are to be used in typesetting context. That can mean letters, or icons, or emoji; it can even be musical notes or mahjong tiles. And the way they do this has until very recently been as "single color", which is literally what monochrome is. The only place where monochrome rendering for fonts might be a problem is on monochrome monitors in which case: where the hell are your webpages being accessed that they can render webfonts, but do so on ancient-even-for-CRT technology O_O
As for semantics: if you need an icon that has no meaning inside the document and is purely UI candy then you do want a non-semantic element, so that text readers and the like for people with visual or reading disabilities don't get your icon read out loud to them, and text indexers for search engines (private or public) can safely ignore them entirely. Your icon should definitely be a non-semantic empty element that can be skipped by everything.
With all that said, what about bitmaps?
Bitmaps absolutely win at low point sizes, but—and this may be a surprise—fonts can actually contain embedded bitmaps so that they can render actual bitmaps, not vector graphics, at small point sizes.
Of course, only high grade fonts come with those, but that's also a thing you check for: does the icon font you're looking at come with bitmaps? If so, we have a winner. If not, then you might want to take the icon font you want to use, generate your icons as a bitmap file, and then manually clean up the bitmap before using it on your site.
This process is inherently manual, no utiltiy will do this for you and not get it wrong enough times that you still need to manually fix things up, but if you do go down this route, and you make your own icons based on a well known font, at a point size that makes the icons look better than the font rendering: give back to the world and send those bitmaps back to the font creators so that they can use them to build out the font's EBLC, EBDT, and EBSC tables and everyone else gets to enjoy having the bitmaps live inside the font, so we don't need to do crazy CSS sprite rendering.
I'm working on a site where small caps are important: setting the text of the Bible. In the Old Testament the name of God is transliterated as Lord but in small caps—not LORD. However, the state of OpenType small caps support at the moment is… less than optimal. Safari (even up through Safari 8 on Yosemite, from which I am typing this) still doesn't support the -webkit-font-feature-settings: 'smcp' option, and a lot of the hits for this website will be coming from mobile.
Unfortunately, "graceful degradation" is problematic here: if you specify both font-variant: small-caps and font-feature-settings: 'smcp' in a browser that supports the latter (e.g. Chrome), the font-variant declaration overrides it, so the horribly ugly old-style version still comes into play. (Note: this is as it should be per the spec: the font-variant declaration has a higher priority than the font-feature-settings declaration). Given the current implementations of font-variant: small-caps, though—shrunken capitals rather than actual small capitals—the result is that using font-variant: small-caps realists in not-so-gracefully degrading everyone's reading experience.
In the past, I have exported the small caps as a distinct webfont and specified them directly; see this post for a simple example: the first line of each paragraph is specified that way.
While I can do the same thing here (and at least in theory could deliver a pretty small typeface, since I really only need three characters: o, r, and d), I'd prefer simply to enable sane fallbacks. As noted above, however, that's not possible. I am open to but would very much prefer to avoid server-side solutions (browser detection, etc.) as a point of complexity that is better to minimize, especially given how rapidly browsers change. How else might one solve this problem, and especially are there existing solutions for it?
Edit: clarifying based on comments—in the future, font-variant: small-caps will handle this nicely, as per the spec it should display a small-capitals-variant of the typeface if the typeface supplies it. However, at present, no browser supports this (at least, none that I can find!). This means that instead, they all render fake small capitals simply by scaling down actual capitals. The result is typographically unpleasant, and unacceptable on this project.
Last updated 2016/02/28.
I spent a considerable amount of time researching this and wrestling with it.
After digging around as best I could, the top solutions for now are:
#supports
Take advantage of the #supports rule in browsers. This is what I initially
opted to do on this project.[1] You use the rule this way:
.some-class {
font-variant: small-caps;
}
#supports(font-feature-settings: 'smcp') {
.some-class {
font-variant: normal;
font-feature-settings: 'smcp';
}
}
I've simplified by leaving out the prefixed versions; you'll need to add the
-webkit- and -moz- prefixes to get this actually working. Update,
2012/02/28: you no longer need the -moz- prefix, and this will work in
Safari in the next release (iOS 9.3 and OS X Safari 9.1).
This has the advantage that support for real small caps and
support for the #supports rule are very similar:
#supports: Can I Use Feature Queries?: Chrome 31+, Firefox
29+, Opera 23+, Android 4.4+, Safari 9+, Edge 12+, Chrome for Android
Update, 2016/02/28: as the chart linked above will make clear, all
evergreen browsers now have #supports support.
font-feature-settings: Using Small Caps & Text Figures on the Web:
Chrome, Firefox, IE10+
This isn't perfect: since IE10/11 don't implement #supports, you miss one
browser. (Edit, 2015/09/31: IE proper doesn't have #supports, but Edge 12+
does, and that should increasingly cover all consumer users of the site.)
Still, this gets you most of the way there, and it should be future-facing: this
should progressively enhance the site nicely. The normal (bad, but functional)
small caps are displayed in the meantime, and when browsers eventually get
around to using OpenType small caps by default for font-variant: small-caps,
this will continue to work just fine. It's "progressive enhancement" and it'll
work nicely for most purposes.[2]
Typeface subsetting
As mentioned in the question, one can create a subset of the typeface that
includes only small capitals. This is what I have done for the small caps on my
own website; see the first line of the first
paragraph in this post for an example.
To pull this off, you'll need to start by subsetting the typeface. You can do
this manually with a font tool, or (the simpler way) you can use FontSquirrel's
custom subsetting tool in their webfont generator. (Note: You
must check the license and confirm that the typeface in question allows this
kind of modification. See below.) In the web font generator, first upload the
file you wish to modify. Then choose the Expert radio button. Most of the
settings you can leave as they are; they're good sane defaults. Midway down the
page you'll see OpenType Flattening options. Here, select only "Small Caps".
Run the generator. The result will be a complete replacement of the normal
lowercase letters with the small caps set.[3]
In that case, you can simply apply a style to the elements you want to have
small capitals, e.g.:
.divine-name {
font-family: 'my_typeface_smcp', 'my_typeface', serif;
}
The major advantage to this approach is consistency: that typeface is going to
display on every browser out there, back to IE5.5, as long as you deliver it
correctly using the various hooks required by #font-face.
There are a few disadvantages to this approach, though:
It means delivering another font file. In my case, this would be an
acceeptably low size (since I actually only need four characters), but it's
still something to consider in general. It is in any case another HTTP
request, which is going to further slow the page load time or at least give
you some flash of unstyled text when it reloads.
It may violate the licenses of the typefaces in question. For at least one
of the fonts I am using on this project, it does: the license explicitly
forbids rebuilding the font using tools like FontSquirrel. (FontSquirrel was
the tool I used for this approach before, and it works quite well.) This is
a make-or-break issue for using a subset of a typeface to accomplish the
goal. That being said, if you have a good reason to do it, you may be able
to get support from the vendor (especially if they're a small shop). For the
project that prompted this question, I was able to do just that with a nice
email—the designer is a great guy.
The other major reason not to do it this way is that it has a significantly
higher maintenance cost. If at any point you need to change or update the
typeface, you have to go through the subsetting process all over again. By
contrast, the first option will simply work, though admittedly not as
pleasantly as one might hope, and will not only continue to work but will
actually improve over time as browsers increase their implementation of the CSS3
standard.
Notes
For various reasons (especially see note 2 below), I actually opted for the
second approach outlined here, which is the same approach I was trying to
avoid. Alas.
Issues remain: even in the latest Chrome (38 as of the time of this
edit), using the font-feature-settings: 'smcp' approach has some
issues. For example, if you turn on letter-spacing (a fairly common
recommendation for small caps), the small caps will revert
to normal lowercase letters. Fixed in Chrome 48. HT to answerer
below.
From the FontSquirrel blog post that introduced the feature:
If you have a font with OpenType features, you can now flatten some of
them into your webfont. For instance, some fonts have small caps built in,
but they are completely inaccessible in a web browser. By selecting the
"Small Cap" option, the Generator will replace all the lowercase glyphs
with the small cap variants, giving you a small cap font. Please note that
not all OpenType features are supported and if the font lacks OpenType
features, using these options won't create them.
Support for font-feature-settings:"smcp" has improved in recent browsers. Chrome 48 fixes the letter-spacing bug. And according to caniuse.com, upcoming versions of Safari for both iOS and Desktop will support it. The prefixed version is still required for -webkit, though.
You already mentioned it here, graceful degradation.
Use the font-feature setting and if a browser does not support opentype features then the user will receive all the content still, with the worst-case scenario being full-size capitals; nothing is lost. I'd say that is a graceful degradation.
Aa an alternative you might want to consider using Typogruby (http://avdgaag.github.io/typogruby/), or similar, or manually adding a class to that word which you can target directly in your html, faking it with CSS2 e.g.:
.caps {font-size: .83em; letter-spacing: .25em; text-transform: uppercase;}
Edit: Of course, with the above method you can also specify a different font for the .caps class, one with full caps that will work well at small sizes in place of true small caps.
Stop thinking OpenType for a moment and think content: you need different styling for semantically different data (in this case, smallcaps styling for a special religious word) That's literally what HTML markup was invented for. Just auto-wrap those words in <span class="smallcapped"> markup with javascript, and have its class use a dedicated small-caps font. This is very easy to do, and even allows you to find the best suite smallcaps look independent of the main text typeface.
Simply run some code every time a section is DOM-loaded (emphatically not after your entire content is done, unless you're only ever showing short stretches of text):
function wrapSmallcaps(element) {
var content = element.innerHTML;
["LORD"].forEach(function(term) {
var search = new RegExp(" W?"+term+" W?",'g');
content = content.replace(search, function(a,b) {
return a.replace(term, "<span class='smallcapped'>"+term+"</span>");
});
});
element.innerHTML = content;
}
ex: http://jsbin.com/cowumaxe/1/edit
We could solve this by trying to make use of OpenType fonts, but you'd be tying yourself to one font, rather than one for for each style, making it extremely hard to improve the looks later on without violating font licenses when a better running text typeface or smallcaps typeface is found, or user feedback prompts you to improve the looks.
(and of course, this code is literally universal for any browser since IE8 -- http://caniuse.com/#search=queryselector shows zero "no support" or even "partial support" for all browsers people actually use)
See images:
Firefox on Mac:
Firefox on Chrome:
On chrome you can see that the same font using the same styling takes more room. What can I do so that all browsers will render the font the same way rather than adding more width to it?
I am using a font with #font-face property.
Unfortunately, there isn't much you can do about the way each browser renders your chosen typeface. Check out this article, it explains how different browsers and operating systems render different type face files:
http://www.smashingmagazine.com/2012/04/24/a-closer-look-at-font-rendering/
In the meantime, you can do two things.
1.) There are many fonts that can be used that are effected by this rendering difference much less. Experiment with different fonts that hold the same esthetic value of the font that you are using, and try to find one that not only fits your typographic needs but also have a less distinctive difference between their individual renderings across different platforms.
2.) Create a script to sense the user's browser/OS and use that script to adjust your font-weight accordingly.
Best of luck.
You forgot to mention which of the two cases is the correct font rendering.
A few ideas that come to mind:
Since you mentioned using font-weight:600 I would try to replace it with normal/bold (depending which result you want) and check if it makes any difference. If the font file does not support a weight for 600 the browser will go on interpreting it by itself - sometimes it takes bold sometimes normal.
If the problematic browser is Chrome you can also try playing with font-smoothing - sometimes it helps improving the font rendering:
-webkit-font-smoothing: none || antialiased || subpixel-antialiased
Also I'm not sure how you are implementing the #font-face - if you wrote it yourself I suggest generating your #font-face rule trough some service like Fontsquirell since it will generate a crossbrowser compatible code which often eliminates a few problems.
For more help you will need to expand your question with a bit more data - add the #font-face code, font name and specify which is the correct font rendering. Poor questions get poor answers.
I'm working with some really great designers. In translating their design, they are asking me why sometimes we don't render non-system fonts exactly as depicted in their designs. A very recent example can be shown in the image attached to this question (ignore red annotations):
I'm using fonts from fonts.com via a javascript include, which allows me to utilize new font-family in my css. I want to draw your attention to two things:
a) On the left, notice the description text "In an effort to ..." is much bolder than "Lorem ipsum ...". Font is "Droid Serif W01 Italic".
b) On the right, notice "MEET ONE" is much bolder than "COMMERZBANK". The font family is "UniversLTW01-57Condense 723821".
I made sure font-weight:normal. And yet, things still look bold on some computers...and it seems to vary depending on which OS and browser you are on. It seems like the only way I can modify the weight of these fonts in an aesthetically pleasing way is by choosing another variation of the font family like the oblique or condensed version (if they exist). But often times, I still can't get the weight to render properly on all the different OS and browser combinations.
How do you guys address these issues? Are there techniques I can use to make the fonts render exactly as depicted in designs regardless of the viewers operating system and browser?
From my experience I always find that font-rendering on the web is nowhere near as good as it is in Photoshop or other design tools. This usually leads to problems like this.
In Photoshop, a designer can use "extra" settings like: "Sharp", "Crisp", "Smooth" and "Strong". All of these variants make the font rendering much nicer. These attributes are not available to us as developers though.
It all comes down to the anti-aliasing of the fonts which all browsers implement in different ways. It is impossible to get fonts to render in the same way across all browsers. This is a reason to use only fonts which are specifically created for the web since they are designed to have good anti-aliasing on screens in the most common sizes.
There are however, some tricks you can try. I have little to no experience with them but hopefully my background answer and these links will give you inspiration in where to find more information about this complex issue.
To me, the left image looks like a classic anti-alias problem. The right picture, I'm not so sure. It almost looks like another font and the size should be big enough for it to render properly.
Check these links out if you wish to read more, hopefully they can be helpful:
Does CSS support text anti-aliasing such as "crisp, sharp etc" yet?
How to do font antialiasing in web page?
Webfont Smoothing and Antialiasing in Firefox and Opera
http://blog.typekit.com/2010/10/21/type-rendering-web-browsers/
"The #font-face CSS at-rule allows authors to specify online fonts to display text on their web pages. By allowing authors to provide their own fonts, #font-face eliminates the need to depend on the limited number of fonts users have installed on their computers. The #font-face at-rule may be used not only at the top level of a CSS, but also inside any CSS conditional-group at-rule." -MDN
#font-face {
[font-family: <family-name>;]?
[src: [ <uri> [format(<string>#)]? | <font-face-name> ]#;]?
[unicode-range: <urange>#;]?
[font-variant: <font-variant>;]?
[font-feature-settings: normal|<feature-tag-value>#;]?
[font-stretch: <font-stretch>;]?
[font-weight: <weight>];
[font-style: <style>];
}
https://developer.mozilla.org/en-US/docs/CSS/#font-face
Its not a perfect solution, but it may get you closer to where you want to be.
We face the same problems you raised and I won't duplicate the good information that's already been covered here. Anti aliasing and CSS are just a part of the picture. So I wanted to touch upon how the typeface foundries and licensing can figure into things.
On the PC side, the reality of webfont services like fonts.com and Typekit usually means results that are noticebly worse. That's regardless of browser.
When you're using a webfonts service you're at the mercy of how that service handles font embedding.
However, if you're using a font that's optimized for web usage and it's available for purchase where you can directly control the embedding of the font files yourself, this article has an good tip to improve rendering on Chrome for Windows.
Examples of foundries that sell (or Google Webfonts at no-cost) fonts for direct embedding are FontSpring, MyFonts, Commercial Type, etc.
Hoefler Type just debuted their own font service that renders beautifully on the PC. It's similar to fonts.com and Typekit in the sense you don't host or embed fonts directly. They've went to an unprecedented level to address all the common issues with webfonts. They adjusted the scale of their font weights and customized their deployment for individual browsers. The limitation is, like many other foundries, as of now you can only buy their typefaces.
Because of these complications we'll usually consider the options for web usage of individual typefaces early on in a project.
From personal experience and high-level research I found that you can come close to achieving a pleasant result using either sIFR (Scalable Inman Flash Replacement) or pure javascript alternatives like Typeface (http://typeface.neocracy.org:81/) and Cufon (http://cufon.shoqolate.com/generate/). I have been using Cufon for a while and I find it the easiest and most effective way to get close to the results you are looking for at the moment. Hope that helps if you still havent come across those solutions yet.