
We're in an icon-sharpness limbo - tbassetto
http://simurai.com/post/19895985870/icon-sharpness-limbo
======
WiseWeasel
I think the answer is SVG for anything we've got vectorized, and I've started
delving more deeply into the format, which turns out to be pretty awesome.

First, to create them, I draw icons with vectors at the actual size the final
icon will be rendered on regular non-retina displays, then export as SVG with
Illustrator. But what I really want are the paths; fill and stroke colors and
shading effects can be added manually.

Then, I open the SVG output in a text editor, and since it's all XHTML
formatted, I can easily modify everything to get the look I want. I can re-
organize the path and fill elements, change their fill colors, and add things
like shadows right in the SVG file as filter elements, in case your editor
makes sub-optimal choices as to how to encode your design.

These icons look perfect when rendered on both normal screens at 1x and retina
displays at 2x resolution. If I needed an in-between size, I'd have to design
a new vector for the new target size. One vector design will typically not
work well for different rendered sizes at this small scale, as every pixel
counts, and anti-aliasing does more harm than good. That problem is just
unavoidable, even when you try to make a flattened PNG at all these in-between
sizes.

I've also found SVG ideal for small bits of text with special non-web-safe
fonts. Converting text to paths and exporting to SVG is the way to go over gif
or png text, and looks great on retina displays.

~~~
luminarious
As SVG supports CSS and Media Queries, it's possible to optimize the display
for different display sizes. Like demonstrated here:
[http://my.opera.com/ODIN/blog/2009/10/12/how-media-
queries-a...](http://my.opera.com/ODIN/blog/2009/10/12/how-media-queries-
allow-you-to-optimize-svg-icons-for-several-sizes)

~~~
WiseWeasel
OK, I take back what I said. SVG _can_ be used to create a single asset that
looks good at ALL resolutions; it's just going to take some work and possibly
add too much bloat to be worth it in some cases.

So let's say you have a 16px icon design, with an element 7px wide, and you
want a 24px version of that icon. The problem is when you scale an odd-
numbered-height or width element by a factor of 1.5 in this example, you get
an element with a height or width defined as a non-integer (10.5px wide in
this case), which is when anti-aliasing kicks in and replaces that extra .5
pixel of element and .5 pixel of background with one pixel of element at half
opacity. this makes it look fuzzy.

What you need to do is have a media query like this in the SVG file:

    
    
        <style>
        @media screen and (max-width: 24){#element {width: 10px}}
        </style>
    

Or maybe:

    
    
        @media screen and (max-width: 16){<shape id="element" width="7px"</shape>}
        @media screen and (max-width: 24){<shape id="element" width="10px"</shape>}
    

I haven't played with it to be sure yet, but something like that might allow
you to set the width, height or radius to an integer for the sizes you care
about.

Complex paths would still likely need to be redrawn for various target sizes
to get rid of the more egregious anti-aliasing issues. In that case, we're
adding bloat to everyone's SVG files to serve the needs of different clients.
Maybe we're still better off with different SVG files served to different
clients when we pass a certain threshold of duplicated content within the SVG,
and duplicated paths would seem to me to be in danger of crossing that
threshold.

------
mmahemoff
I'm curious if there are any standards for "patching" vector graphics. So you
could download the base SVG and a separate vector and/or bitmap-based patch to
produce something appropriate for the resolution. (As well as being
appropriate for the bandwidth constraints etc.)

The patch could be downloaded simultaneously or progressively, i.e. after the
base image has been rendered.

~~~
natevw
I've always wondered if adding something like "font hinting" would cover most
use cases. Although I suppose for e.g. icons sometimes at the smaller sizes
the actual graphic is pretty much a completely different image, rather than
just a hand-tweaked rasterization.

~~~
schmerg
See [http://www.pushing-pixels.org/2011/11/04/about-those-
vector-...](http://www.pushing-pixels.org/2011/11/04/about-those-vector-
icons.html) for a detailed exploration of precisely the issue with icons and
real-life examples of how smaller versions are actually different images (eg a
large 3d image with drop shadows gets gradually flattened to a simplified 2d
version).

One thing you can do for patching SVG is to have multiple versions of
images/shapes and use CSS rules to select just the most appropriate one to
show depending on a class you add to some root or parent item - hiding the
other until needed. I haven't tested this, but wonder if the browser would be
smart enough to prioritise loading of the different images depending on the
visibility.

Otherwise you could generate those parts of the SVG as required, and use the
load event to only swap the display to the more appropriate version of an
image once loaded.. hence as you zoom the display, you first get the "core"
image/shapes etc simply scaled by the browser, and then as background images
are loaded, these scaled versions are replaced by more appropriate versions.

This would match the way that zooming works with tiles in apps like Google
maps - when you first zoom in you simply get the base tile images scaled by
the browser, and then replaced by the more detailed versions as they're
loaded.

------
alexchamberlain
We need a multi-resolution image format and/or support for browsers to dictate
to the server what size they want.

~~~
ars
There is a workgroup working on it: <http://www.w3.org/community/respimg/>

Some of the options: <https://etherpad.mozilla.org/responsive-assets>

~~~
alexchamberlain
We need to send the dimensions with the image request. It's the only way.

~~~
pornel
There are many factors beyond screen size that could be involved in selection
of image DPI: bandwidth availability and cost, screen density and current zoom
level, amount of free memory available, hardware limitations (like iPad's max
1024px bitmaps).

Sending all these factors to the server would be problematic, so IMHO it's
better if page declaratively specifies what sizes are available and lets UA
pick one (so my UA doesn't need to tell every server when I'm out of my
bandwidth allowance and _hope_ server acts as expected).

~~~
alexchamberlain
I disagree to some extent. Given DPI, screen density and zoom level, the CSS
etc should dictate the pixel width/height which can be sent to the server to
obtain the correct version.

