Size of "Medium" icons
Zack Rusin
zack at kde.org
Wed May 9 10:51:46 BST 2007
On Tuesday 08 May 2007 10:52:58 pm Boyd Stephen Smith Jr. wrote:
> On Monday 07 May 2007, James Richard Tyrer <tyrerj at acm.org> wrote
>
> about 'Size of "Medium" icons':
> > When a 128x128 pixel SVG image is
> > rendered to 22x22, it is always going to render poorly while with 24x24
> > boundaries in the image on a 16 pixel grid will be pixel perfect.
>
> I thought the whole point of SVG what to be resolution independent and
> infinitely scalable. To me the whole idea of a 128x128 pixel SVG image
> sounds wrong.
That's not how resolution independence works. It doesn't mean "your image will
look the same in all resolutions" but "resolution doesn't affect construction
of your image" which in turn does not translate to "it will look good at all
sizes" :)
With the current output devices the rendering has to be rasterized before it's
displayed. Digitization of that signal of course produces artifacts on all
grids but the native grid. So if you rasterize your SVG, the artifacts in the
output will be proportional to the size difference between the SVG native
grid and the output grid and will increase if the grids don't map with finite
mantissa multiplier.
The way SVG icons are designed is that their grid (viewport) is made into one
of the native icon rasterization grids e.g. 128x128 which means that at all
but 128px x 128px resolution there will be some artifacts (because only at
that size there's a 1x1 coordinate correspondence).
This is one of the reasons font designers introduced the concept of "hinting",
by which the designers can assure that at the very least grid-fitting happens
(meaning primitives that happen to fall in-between scan lines are shifted to
integer coordinates thus eliminating undesirable anti-aliasing and artifacts
as a result producing a lot sharper images). SVG doesn't have anything
like "hinting" to improve rendering quality at non-native grid sizes.
We (most likely "me" in this context) could sit down and come up with
something to fix the situation but I'm not sure if the problem is worth it at
this point.
z
More information about the kde-core-devel
mailing list