CSS3 has a property called “font-smooth” that is designed to provide an anti-aliasing of web fonts.
As of today. it does not appear to be supported by any of the major modern browsers.
In the absense of that, what might I do to smooth the jaggies on the “Signika” headline font seen on this page?
Uhm… easiest way? Don’t waste bandwidth on webfonts 
– only partly a joke. It’s a cute technology, but it’s not entirely ready for prime time in many alternative browsers.
There is another approach that’s not perfect, but kind-of works. Add text-shadow to it that’s 0 0 2px and then the color you’re rendering the font in. It’s not perfect, but that slight bit of blur hides the jaggies.
Though I suspect that the problem isn’t so much with the renderer or smoothing as it is that font lacking hinting to do the smoothing in the first place and/or being too complex or manually doing it’s curves. Not all fonts are viable for web deployment – even when google lists them as such with their silly “google fonts” nonsense (which I’ve had NOTHING but headaches with)… I would suggest downloading the original TTF version of said font, converting it with font-squirrel, and hosting it yourself to see if that helps any.
Or pick another font because that’s a UGLY font for low dot-pitch use.
Thanks for the text shadow tip.
I have to say, I’ve heard this argument before regarding GWF. However, my experience with them, with a WordPress theme in use by over 2k owners and thousands more sites, has been 100% reliable and effortless.
I have not had a single complaint or issue with using them and they have performed flawlessly from day one.
I’m just talking about tweaks here, but outside of that, absolutely zero issues.
Get a Mac. The font looks fine to me.
Congratulations, though, on getting a Google font to work. Not once in my experience have they worked cross browser, so I’ve ruled out every looking at them again (at least for the next year or so, until I forget. :D)
Couldn’t agree more 
Also font’s included through CSS will only have a jagged edge if hardware acceleration doesn’t exist in the browser or if your not on a Mac which by default has anti aliasing built right into the OS.
Hi Scott and All,
Rendering quality of fonts on Windows based computers is one of the biggest pains of web fonts today. Why? As pointed out in the thread you are running into a technology that is still in development but mostly you are running into poorly created fonts or fonts that were created for print and not onscreen reading. Search Google for Windows Font Hinting and you will find any number of articles about the topic and the pain that Windows poor text rendering causes. Also look at the information about ClearType rendering that was introduced by Microsoft Windows in XP but not turned on by default.
A couple of places to start if you want to fully digest the issue:
http://blog.webink.com/webink/font-rendering-in-web-browsers-a-find-your-font-adventure/
http://blog.typekit.com/category/type-rendering/
You might wonder why are all of the fonts at GWF or other service like mine WebINK, Typekit, Fontdeck, and others not all hinted for Windows onscreen viewing? Basically its pretty expensive to do well. It requires going back by hand and tweaking the font outlines at various point sizes and this can take up to a week per font face to complete. There are some automated scripts that can be run but they just don’t cut it yet. The fonts you are used to Arial, Times, Verdana and so on have all be built with the computer screen in mind and have this hand-hinting built into them.
So what can you do?
What you are looking for are fonts that have been hand-hinted and there are some really nice ones out there. For instance the fonts from Adobe that WebINK and Typekit have in their libraries are all hand-hinted for the web. There are many others and more and more are being added each day and some foundry’s are even going back and redoing the fonts to work better onscreen.
For now its a bit of hunt and peck issue that requires some testing and deciding what works in your situation. I am sorry I can’t give you an complete solution other than you get what you pay for these days with web fonts and some are just better than others.
Keep in mind too that it’s only the art… folks who piss and moan about font rendering; as a lot of people (myself included) cannot stand the blurry illegible mess that Apple has the giant brass monkey balls to call font rendering. Some of us actually LIKE for-screen hammer the glyphs in to be legible approach as opposed to the “preserve the glyph at all costs, who cares if it’s legible” approach Apple takes to it.
Personally I’ll stack cleartype against Apple’s renderer any day of the week – and don’t even get me STARTED on what a disaster freetype is on the subject (no matter how much you tweak it, it st ill ker ns tex t li ke a swee tly ret arded rhesi s monk ey on cra ck) – something that was really exacerbated in OoO for the longest time when they tried to use the freetype kerning with the windows glyph renderer. It be spacin g…
It’s part of why for me *nix as a desktop OS (particularly anything X11 based) still feels like a rinky incomplete half-assed tinkertoy; but then I’m REALLY sensitive to kerning issues. Screens most people seem to see nothing wrong with in Linux make me go “what are you, blind?”
Great additional info.
I hear you on the preferences but the Masses prefer the Apple rendering as a good enough average. I have personally seen a lot of issues with ClearType depending on the font and how it was hinted where it can actually be worse. But then again there are good fonts and then there are not so good fonts. A good font can mean all the difference and can take years to fully develop.
I have really begun to like some of the rendering done with the DirectWrite engine that IE9 uses and that Firefox now has in it as well.
With epub making such a strong push over the next few years I really think we will see some great improvements in rendering. But until then a quality font can make a world of difference.
Which is really what it boils down to in many cases. So many fonts as many have already said in this thread are made for print, and JUST print… Screen lacks the resolution and detail for those fonts to look good; sometimes that level of detail also results in fonts that are too massive (anything >64k IMHO) to be deployed on websites.
A lot of it is also that many people making fonts don’t entirely grasp the technology or practices – it’s why when you declare different fonts at the same font-size you can end up with all sorts of different heights and widths – A LOT of font designers don’t obey the caps-line, base-line, x-height, mean-line, or any of the other bits that you are supposed to stay inside when building a character… things that if followed prevent those sorts of issues. Look at the font the OP was trying to use – the top of every glyph is 2 to 5% over the stated caps-line or mean-line, which is why all the renderers are showing just a single pixel at the top of every glyph; they think the top of each arc is a serif and not part of the core glyph. You run an arc up to the ascender line, it’s going to be anti-aliased as a serif instead of an arc.
For those of you unfamiliar with the terminology, there’s a great picture here explaining it:
You don’t follow the conventions it often still looks fine at 1200dpi… at the physical 75 to 96 ppi of most displays, not so much. (did you know most 14" displays people ran at 800x600 and most 1024x768 LCD’s are actually 72-75 physical dpi, not the 96 most OS assume? Only with recent LCD’s have we gotten to that 96 physical ppi, which an increasing number of people are bumping to 120dpi OS setting for being too small)
I mean think on that – 72 to 96 physical DPI with fonts meant for 300 to 1200dpi output; of COURSE they look bad.
Great replies guys with some interesting information.
I must admit I’m not a great fan of embedding fonts as I dislike the wait and the blip when the font appears/changes in some browsers which can occasionally cause layout errors if the page was already drawn.
Glad you found some of the information interesting and useful. I think our friend deathshadow60 has a very good understanding of the issues that remain in this new and expanding technology. It has to get better considering the push for ePub and the nature of how ePub works it will push for better rendering across the board.
Paul one thing you mentioned about the blip is mostly related to Firefox 3.5 and 3.6 and IE. Safari, Chrome and FF4+ now all do not render the text until the font is downloaded and just like images fonts from services like our are cached in the browser cached for 30+ days. Thus your visitor will only see any delay’s or reformatting once which i think we can all attest to seeing with CSS, JS and image downloads since day one. Plus, a number of us have taken steps to control the blib or what we call FOUT (Flash of unstyled text) we created a drop-in JS file called Fout-B-Gone http://www.extensis.com/en/WebINK/fout-b-gone/ and Google, Typekit and Fontdeck created the Web Font Loader JS. Both of these JS add-ons really do help with this issue.
Brad
Thanks for the extra info Brad and very interesting first few posts. Welcome to Sitepoint.
I’ll have to look into font embedding in a bit more detail next time a client asks. I must admit I’ve generally avoided using embedded fonts for the reasons mentioned but maybe I’m just old fashioned and perhaps things will improve.
