All this work of trying to achieve "pixel alignment" on icons is useless, in my opinion. Just change the browser zoom level, and it all breaks. It Retina, it's not necessary. And font rendering is so different between platforms and browsers, it's too hard to try to accomodate.
End-users don't really care about "blurry" (i.e. anti-aliased) icons, since all their text is rendered the same way. They only care if the icons aren't legible.
Much better than trying to hack hard pixel edges, would be not to cram so much stuff into an icon in the first place. Examples:
- Instead of a dogeared document with lines on it (indicating text), just use a blank dogeared document
- Instead of a book+bookmark icon, just use the bookmark part, or just the book part, depending on what the icon is for
- Instead of slapping a "+" onto an existing icon (e.g. on top of a book with a bookmark, to indicate "new repository" on Github), just use a "+" icon by itself, and ensure the context makes it clear that we're talking about a repository
GitHub tried to cram way too much information into a lot of their icons, and it's basically useless IMHO. Icons shouldn't be self-contained complex symbol languages; they should be simple and depend on context for full meaning. They're not sentences, they're signposts.
How many typical users change their zoom level? I suspect not many. What % of users online have retina displays? I suspect a growing but still small number. So, it would still matter.
I suspect people using a Retina display are more than likely to be using a WebKit browser, so it's easy to make icons render nicely with just the font technique. This is my motivation for wanting to use a font for icons.
But to improve the quality on the desktop in other browsers, you can use a canvas element. And you don't lose anything over image icons when zooming.
With an insight into font technologies, this is actually very easy to solve.
Opentype fonts can contain TrueType or Postscript curves. These two have a very different approach to hinting: In TrueType the font is clever and the renderer is stupid (lots of very complicated hints in the font). In Postscript the font only has a few simple hints, and the renderer does the rest.
On Windows an unhinted TrueType text font looks horrid, an unhinted Postscript font is ok.
So, if you want an unhinted font, because you're using icons, just use TrueType shapes and don't hint them (like Font Awesome seems to do)
(This doesn't cover the native mac renderer, it ignores any hints and does all the work itself)
Another way to sharp icon fonts (at least in Webkit) is using the SVG font format (placing it above ttf in the webfont stack). I demo'd this on my blog:
Swapping the order and removing the woff format in my example to match your scheme didn't result in sharp icons for me. Which OS and browser did you use?
In Firefox on the Mac, square elements have blurred edges. Look at icon-envelope-alt, icon-table, etc. And the round icons, eg icon-circle-*, have flattened edges.
In FF 13, IE 8, and Chrome (21.0.1180.15 dev-m) on Windows XP, I'm not seeing blurred or flattened edges with Font Awesome at all.
Actually, I'm not seeing any improvements in your "Web font icons rendering proof of concept" demo with either. Before and after look the same here for FF and IE. For Chrome, the after column is blank. (?)
I do see the blurriness in your PNG graphic on your page, so it's apparently not my eyes that are to blame: Safari looks good; FF, bad; IE9, fair.
canvas is inconsistent on webkit too. On iOS you need to create the element at twice the size because canvas size == backing size, while Safari/Mac "transparently" does this (and breaks direct pixel access). Chrome/Mac hasn't made up their mind which model to follow.
You need to look at both window.devicePixelRatio and canvasContext.webkitBackingStorePixelRatio to detect if you need to do manual pixel-doubling.
End-users don't really care about "blurry" (i.e. anti-aliased) icons, since all their text is rendered the same way. They only care if the icons aren't legible.
Much better than trying to hack hard pixel edges, would be not to cram so much stuff into an icon in the first place. Examples:
- Instead of a dogeared document with lines on it (indicating text), just use a blank dogeared document
- Instead of a book+bookmark icon, just use the bookmark part, or just the book part, depending on what the icon is for
- Instead of slapping a "+" onto an existing icon (e.g. on top of a book with a bookmark, to indicate "new repository" on Github), just use a "+" icon by itself, and ensure the context makes it clear that we're talking about a repository
GitHub tried to cram way too much information into a lot of their icons, and it's basically useless IMHO. Icons shouldn't be self-contained complex symbol languages; they should be simple and depend on context for full meaning. They're not sentences, they're signposts.