Ask HN: Custom Fonts & Anti-Aliasing
11 comments
Whether the font is anti-aliased or not depends on the operating system settings, not on the font itself.
That said, I do notice that some custom web fonts look ugly on Windows due to the very crisp quality of the rendering engine, especially when Cleartype is enabled. Those fonts look a lot better on Linux and Mac browsers.
Therefore, whenever I choose to use a custom web font and know that my target audience includes Windows users I give more attention to selecting a proper font and testing how it renders on the page.
I encourage the use of embedded fonts over traditional techniques such as image replacement, because the text looks and behaves the same as it would in other applications on the user's computer.
(I'm a developer doing some design on the side)
That said, I do notice that some custom web fonts look ugly on Windows due to the very crisp quality of the rendering engine, especially when Cleartype is enabled. Those fonts look a lot better on Linux and Mac browsers.
Therefore, whenever I choose to use a custom web font and know that my target audience includes Windows users I give more attention to selecting a proper font and testing how it renders on the page.
I encourage the use of embedded fonts over traditional techniques such as image replacement, because the text looks and behaves the same as it would in other applications on the user's computer.
(I'm a developer doing some design on the side)
Not quite, Windows uses hinting information from the font, OSX doesn't. Many freely available fonts contain terrible or no hinting, and they will look bad at small sizes on Windows.
Even more important: Windows uses _very_ aggressive hinting for its default fonts, especially the new set introduced with Office 2007 and Windows Vista (Calibri, Cambria, Consolas). Though I very much like the effect for my programming font (Consolas is great in that respect), it destroys the scalability of a font to a very high degree (this is the reason why zooming a Webpage in any Browser reflows your text, and why some fonts look different in shape and/or height/width ratio in different zoom-levels; beside that rendering-engines decision to round the font-sizes to the next full pixel).
IE9 promises to not do this anymore, and on high-density displays (the better smartphone ones) it is simply not needed.
So the problem is two-fold: a very distinctive look of Microsoft fonts, and a sub-optimal fallback for non-aggressively hinted fonts in Windows.
However, if one uses font-sizes that one can actually read (for instance, bigger then 12pt, thank you all very much) the pixel-per-character count gets big enough that the results start looking better -- especially as the user does not unconsciously move his nose to meet the display in person.
IE9 promises to not do this anymore, and on high-density displays (the better smartphone ones) it is simply not needed.
So the problem is two-fold: a very distinctive look of Microsoft fonts, and a sub-optimal fallback for non-aggressively hinted fonts in Windows.
However, if one uses font-sizes that one can actually read (for instance, bigger then 12pt, thank you all very much) the pixel-per-character count gets big enough that the results start looking better -- especially as the user does not unconsciously move his nose to meet the display in person.
So what would you consider an acceptable cut-off point for Windows users, after which you'd go for an embedded font over a "safe" solution?
Add text-shadow: 0px 0px 1px rgba(0,0,0,.05); (Or any other text-shadow value)
This makes a huge difference in Windows Chrome as it apparently causes the font to take a different rendering path.
Don't use text-rendering: optimizeLegibility; It ends up doing either nothing or making things look worse on some mobile webkit browsers.
This makes a huge difference in Windows Chrome as it apparently causes the font to take a different rendering path.
Don't use text-rendering: optimizeLegibility; It ends up doing either nothing or making things look worse on some mobile webkit browsers.
When using shadows on text with css you put the users CPU to test, if the users is on a mobile device or slow computer the CPU will work hard to make the shadow look good, so keep that in mind and try to avoid text shadow.
Keep in mind though that using the text-shadow hack may cause the text to reflow and jump around when you select it.
just tried this out, didn't know about it but it really works well. I didn't see any jumping around-ness when I tested it.
For css -webkit-font-smoothing you may try between "antialiased" and "subpixel-antialiased", then there is css text-rendering: optimizeLegibility.
Also you should notice a bug in Safari for OS X that turns off antialiasing: http://seanmcb.com/typekit/webkit-antialiasing-test.html
Google has free webfonts that are already prepared for including in different browsers, you may consider them: http://www.google.com/webfonts, also there is http://www.kernest.com/.
FontSquirrel was already mentioned in this thread.
Also you should notice a bug in Safari for OS X that turns off antialiasing: http://seanmcb.com/typekit/webkit-antialiasing-test.html
Google has free webfonts that are already prepared for including in different browsers, you may consider them: http://www.google.com/webfonts, also there is http://www.kernest.com/.
FontSquirrel was already mentioned in this thread.
Also, If you use css 3d transform in Safari or Chrome under Mac OS, then absolute or relative positioned text will be badly antialiased. To fix that you need to explicitly set background color for these elements.
Why? Because the system strikes a balance between good semantics (for SEO if you need to justify this commercially), expressing a design effectively and licensing typography legally for the web.
It's an improvement over Cufon/Sifr generally and the one downside it does have (rendering under non-mac) will get better soon and I'll have to do zero work to benefit from that (theoretically).
Plus I saved a lot of time (and cost for the client) getting from design to live site quickly. It's a small price to pay, given that most ppl won't care that much, and those that do, a good proportion will understand what the issue is.
It's an improvement over Cufon/Sifr generally and the one downside it does have (rendering under non-mac) will get better soon and I'll have to do zero work to benefit from that (theoretically).
Plus I saved a lot of time (and cost for the client) getting from design to live site quickly. It's a small price to pay, given that most ppl won't care that much, and those that do, a good proportion will understand what the issue is.
On a side note as a font-lovin' designer type: I personally love it when sites break out the webfonts to great effect.
If a site is designed well then the small detail of the font AA is easily missed, ignored or forgiven as the site is a joy to use/view.
Quipsologies is a case in point. http://www.underconsideration.com/quipsologies/
The slight clipping of their sub-heads under chrome is overlooked given beautiful layout and clear delivery of information.
If a site is designed well then the small detail of the font AA is easily missed, ignored or forgiven as the site is a joy to use/view.
Quipsologies is a case in point. http://www.underconsideration.com/quipsologies/
The slight clipping of their sub-heads under chrome is overlooked given beautiful layout and clear delivery of information.
In my experience, some webfonts look okay at smaller sizes but most of them don't.
Typekit shows browser samples that you can break down by OS as well. ie. http://typekit.com/fonts/adelle-web click on the 'Browser Samples' tab
Look what happens when you change the h1 on custora.com from 50px just up to 51px on Chrome [Win 7]: http://dl.dropbox.com/u/4129016/50-51.png (it looks a lot better)
Typekit shows browser samples that you can break down by OS as well. ie. http://typekit.com/fonts/adelle-web click on the 'Browser Samples' tab
Look what happens when you change the h1 on custora.com from 50px just up to 51px on Chrome [Win 7]: http://dl.dropbox.com/u/4129016/50-51.png (it looks a lot better)
Thats why I think its better to use generic font on the body copy, and custom fonts for comparatively larger headings.
You've raised a good issue.
I recently redesigned my blog and that included updating the typography. I decided on DroidSerifRegular for the body text. It looks beautiful on a Mac but when I previewed it on IE/Windows, it looked absolutely horrible (the lowercase a, especially). So for IE I use Georgia.
My blog: http://techiferous.com
I recently redesigned my blog and that included updating the typography. I decided on DroidSerifRegular for the body text. It looks beautiful on a Mac but when I previewed it on IE/Windows, it looked absolutely horrible (the lowercase a, especially). So for IE I use Georgia.
My blog: http://techiferous.com
I set the body text to DroidSerifRegular on IE7 for Win and it looks fine:
http://dl.dropbox.com/u/4129016/droidserif-ie7-vs-chrome.png
Also, it looks like the bottom of the "g"'s and possibly some other characters are getting cut off. It's fixed by adjusting the font-size.
http://dl.dropbox.com/u/4129016/droidserif-ie7-vs-chrome.png
Also, it looks like the bottom of the "g"'s and possibly some other characters are getting cut off. It's fixed by adjusting the font-size.
Thanks! That reminds me that it was actually the lowercase t's I had an issue with, not the lowercase a's. Notice the "inkbleed" at the bottom of the t.
Probably not the font-size, but the line-height. Narrow line heights sometimes cause text clipping.
Custom fonts seems to have problems here and there on Chrome/Chromium. No matter how hard you try you would get mediocre fonts on Windows box.
May be chromium devs need a way to unitize ClearType when custom fonts are being used.
May be chromium devs need a way to unitize ClearType when custom fonts are being used.
[deleted]
top tip: Adding text shadow (use the background color so it's invisible) makes fonts render a lot better in Webkit. No idea why, it just does.
Also, if you're using @font-face for links, you may get some weirdness with hover states etc. You can use the same trick, but you'll need to tweak the blur for each state to get rid of any artefacts that stick around.
It's not about the font display it's about accessibility and usability (being able to process the text, seo, copy paste etc)
Chrome on Windows has some of the ugliest web fonts in general, but I've found that including an EOT, Woff and SVG in addition to the TTF.
FontSquirrel's '@font-face Kits' execute this as perfectly as I've seen, and I can't find a scenario wherein their fonts look ugly.
FontSquirrel's '@font-face Kits' execute this as perfectly as I've seen, and I can't find a scenario wherein their fonts look ugly.
I'm curious, what version of Windows? Chrome for me on XP and Windows 7 has the most beautiful webfonts out of all browsers.
The syntax from the kits at Font Squirrel are also what most other subscription/pay webfont use, so Font Squirrel fonts shouldn't necessarily be any different from Typekit fonts.
Most recent bulletproof syntax: http://www.fontspring.com/blog/further-hardening-of-the-bull...
The syntax from the kits at Font Squirrel are also what most other subscription/pay webfont use, so Font Squirrel fonts shouldn't necessarily be any different from Typekit fonts.
Most recent bulletproof syntax: http://www.fontspring.com/blog/further-hardening-of-the-bull...
Do you have a screenshot of good-looking webfonts on Windows?
Here is a sample image I've made comparing various font rendering engines. The "Windows" one is by far the worst, IMO, and that's Chrome: http://twitpic.com/1ynx3e .
Edit: I looked around on fontspring, and noticed that most of those fonts look OK on Windows/Chrome, though not as good as on Firefox with DirectWrite enabled. Does the way you embed the font affect how well it renders?
Also, I've noticed that many free fonts (like those available from Google) render poorly. Is this an artifact of them being poorly designed?
Here is a sample image I've made comparing various font rendering engines. The "Windows" one is by far the worst, IMO, and that's Chrome: http://twitpic.com/1ynx3e .
Edit: I looked around on fontspring, and noticed that most of those fonts look OK on Windows/Chrome, though not as good as on Firefox with DirectWrite enabled. Does the way you embed the font affect how well it renders?
Also, I've noticed that many free fonts (like those available from Google) render poorly. Is this an artifact of them being poorly designed?
Yeah, definitely looks better in FF4 with the new rendering APIs, or OS X. Those jaggies are pretty ugly :).
I was specifically referring to XP, but I just checked against the new settings and you're right, it's looking gorgeous.
@Developers: What's your take on using these fonts against using normal ones?
@Designers: Would you rather have a font that's correct against initial design, or an anti-aliased one that isn't?
Examples: custora.com, locations on creativemornings.com, elated.com post titles. YMMV looking at these, based on what your OS/browser combo is.