If you don’t use typekit, that is.
Note for the SVG cases, I’ve changed the font from Quicksand to Roboto Regular. In an earlier post, I mentioned that a text-shadow trick might fix this problem, but I was incorrect then (and still am now) and was too lazy to correct it. My apologies to anyone who might have wasted their time with that.
-webkit-text-stroke: 1px transparent; has been heralded as a fix, but it isn’t. Using a color instead of ‘transparent’ gives smoother results, but everything is a bit too thick/strong for my liking.
-webkit-font-smoothing: [...] does not seem to do anything at all with Chrome 19, either, which is unfortunate.
I’ve seen suggested using -webkit-transform: rotate(0.01deg) as a method to trigger anti-aliasing. Unfortunately, it doesn’t appear to work with any degree amount.
I did discover that SVG webfonts will trigger anti-aliasing, but it would seem that either: a) SVG webfont support is currently buggy in Chrome 19, b) the Roboto Regular webfont I got from fontsquirrel is broken, c) I have committed a series of user errors. I’m inclined to believe some combination of a) and c).
The good news, though, is that it seems future Chrome will fix the problems I have been encountering. However, it seems the WOFF rendering in Canary hasn’t improved.
At this time, it seems the simplest thing to do would be to use typekit. I wonder if their method is public / reverse engineered.
Until that happens, I’m downgrading webkit to a system font:
h1, h2, h3, h4, h5 {
font-family: Quicksand, sans-serif;
@media screen and (-webkit-min-device-pixel-ratio:0) { /* temp hack for Chrome fonts :( */
font-family: Roboto, Helvetica, Arial, sans-serif;
}
letter-spacing:-0.05em;
font-weight:bold;
}
