Unbluring web font icons: Response to GitHub's Octicons post | Hacker News Reader

Unbluring web font icons: Response to GitHub's Octicons post

bens.me.uk

19 pointsbensummers20 comments

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.

> How many typical users change their zoom level? I suspect not many.

How many people have less than perfect eyesight? I suspect very many.

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)

I'm using Firefox, and It looks perfectly clear to me. http://i.imgur.com/1GMdY.png

Firefox on Linux? It's very bad on the Mac, less bad on Windows, and looks like it's perfectly OK on Linux.

The same here, Firefox on Win7 seems to be doing it better than chrome.

http://i.imgur.com/Vmbh2.png

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:

http://t.cem.re/post/21179547863/the-secret-to-custom-sharp-...

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?

Font Awesome looks decent across browsers.

http://fortawesome.github.com/Font-Awesome/

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.

Just FYI...

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.

I wonder if setting opacity to 0.999 in CSS would prevent the blurring without stopping scaling on zoom.

Nice idea, but it doesn't stop the blurring.

On the iPad3 canvas looks blurry, the normal rendering looks sharp.. Maybe best to make it conditional?

Absolutely. If I deploy something like this, it'll only do the canvas rendering on non-WebKit browser.

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.

Except that it doesn't work when you increase the zoom level on Firefox on mac.

That's because it's effectively zooming a fixed size image, so you see the same effect as you would if you were zooming an img.

If it's possible to detect the zoom level and rerender, it should be possible to work around this.

Reply on news.ycombinator.com