Shared publicly  - 
 
Took a closer look at font-icons, SVG and their sharpness.
39
26
Stuart Langridge's profile photoAntonio Holguin's profile photoAndreas Fritsch's profile photoMark Entingh's profile photo
15 comments
 
The absolute clarity can not yet readily available. I think the best way today to get that perfect clarity is helping with JavaScript, to download the correct image for the screen resolution the user has. Although, of course, we should create different versions of each image. :/
But whenever possible, I prefer to take advantage of Icon Fonts.
I loved the concept of icon-sharpness limbo! LOL XD
 
Not sure you're missing something, but maybe I am. I don't know how it's even possible to have an image which is sharp at all resolutions. I mean, if I've got an icon font which contains a character which is a 1-pixel-wide line at 8px font size, then it'll be 2px wide at 16px font size, and it will be 1.5px wide at 12px point size... you're always gonna have fractional pixels, by which I mean: blurriness. The only way around that is to explicitly draw all the sizes you want and apply human judgement -- at 12px, would you rather have that line be 1px wide (meaning that it'll look thinner than it ought) or 2px wide (and it'll look thicker than it ought)? I can't see how a computer could ever resolve that; it's a pure out-and-out design judgement call, isn't it?
 
I use a beautiful JS library http://www.raphaeljs.com which can draw SVG objects very well,and there are tools to convert SVG illustrator files to javascript to use with raphaeljs. The best part is that you can use jQuery to add classes to any element within your SVG object generated by raphael.
 
Simon: nice post on an important issue.

B.t.w. David Bushel has written about a work-around for the resizing issue: http://dbushell.com/demos/svg/scaling-09-03-12/

The 'hack' is basically to define your SVG 'canvas' a lot bigger (so upscaling does not blur). Optionally you could use e.g. `scale(100,100)` to your path so that you can still use 'small numbers' (and save some bytes).
 
About the lack of sprite-related tools: why not merge (server-side) distinct SVG files into a single one, optimized for the rendered page, inject it in the body (or header?) of the page, and reference them from CSS?
 
#facepalm
It seems +Stuart Langridge may be the only designer here not lacking work ethic and understanding of grade 5 arithmetic. This post exemplifies today's designers' laziness and denseness. Computers just do whatever it is we humans tell them too. So a computer sizing an icon is, and forever will be, simply doing math.

To reiterate Stuart's example: 24 is 1.5 times of 16. If you have a 3 pixel high rectangle in your 16 pixel squared asset, when you multiply by 1.5 you will have a 4.5 pixel rectangle in a 24 pixel squared asset. No matter how you tell the computer to do the math, it will never be a whole number that will automatically be placed so that it is on pixel.

This problem hasn't existed since the dawn of Apple's "retina" displays. It has been prevalent for years prior. There are already solutions out there. They just call for humans to know basic arithmetic and be willing to put in extra effort.

You certainly can use JS to grab different assets for different sizes. That is probably the best way for web work. For downloaded applications, you'll have to do something simliar. You'll have to create the various sized assets and programmatically call the correct ones for the correct resolutions—that is, of course, dependent on the programming language, runtime environment, and/or development tools used to create whatever it is you are creating. UIKit for iOS, for example, doesn't need you to do anything special beyond having two of the same asset, one with "@2x" appended (this gets trickier when creating a phone and pad app in one bundle). A font definitely won't help this (using a font just goes to show designer negligence). SVG won't do this (less lazy but not reliable, unless you create SVGs for the different sizes).

This means there is only one simple solution to all of this. It goes by the concept of Designer Diligence. You, Mr. and Ms. Designer are going to have to do extra work and learn how to do some simple math to get your assets on pixel for all various sizes, that is, if you care enough. No, it's not "easy," but it is your "job."
 
Hi Sim, couldn't the 'canvas' object be a solution. Of course transfering vector data to canvas might be overkill and I'm not sure if shadows work fine, but it is widely available and seems quite powerful.
 
Canvas is not a good solution for crisp, scalable graphics. It has the same problem as other pixel formats that the article talked about. SVG is the right approach :)
 
The Silver bullet will come with an improvement of the img container, the browser should start developing towards a High Density screen. Most of the cases scaling down will work if we were able to do it on the img instead of the background. So our only concern will be to check if the scaling down works or if we require a redo of the low-res icon.
 
I've been using Inkscape to create an SVG icon set, then generating WOFF, EOT, and TTF from that via FontSquirrel. In Inkscape, I do the art with a 1024x1024 base canvas size and a 64px grid. That gives me a 16x16 area in which to create shapes, which means that the resulting graphics render crisply at 16px multiples even after being transformed from SVG to the other representations. I use no hinting whatsoever.

Something to be careful with when using icon fonts in a browser - WebKit in particular - is that sometimes fractional pixels mess up the rendering. This can happen when you're doing positioning sometimes with fraction-of-an-em measurement.
Add a comment...