Live data from Hacker News

About those vector icons

pushing-pixels.org

11–20 of 41 posts

Re: About those vector icons

#11

I'd like: 1. native support for optional manual hinting vector icons 2. native support for optional auto-hinting vector icons Auto hinting is not the ultimate solution, but it can get you part way there, just like with fonts.

> Auto hinting is not the ultimate solution, but it can get you part way there, just like with fonts.

Even without auto-hinting, it still boggles my mind that "desktop" vector formats don't seem to support hinting at all: I recently discovered there is no possibility of hinting in SVG, therefore SVG fonts (fonts described using SVG shapes) can not be hinted at all, that's completely insane.

Re: About those vector icons

#12

I'd like: 1. native support for optional manual hinting vector icons 2. native support for optional auto-hinting vector icons Auto hinting is not the ultimate solution, but it can get you part way there, just like with fonts.

> Auto hinting is not the ultimate solution, but it can get you part way there, just like with fonts. Even without auto-hinting, it still boggles my mind that "desktop" vector formats don't seem to support hinting at all: I recently discovered there is no possibility of hinting in SVG, therefore SVG fonts (fonts described using SVG shapes) can not be hinted at all, that's completely insane.

YES. Given how long we've been building up to resolution independence, given the already long standing real-world examples of vector object hinting provided by fonts... it's amazing that there seems to be little work in this area and less work in terms of actual standards/implementations.

This is an area Apple is perfectly, ideally positioned to execute and lead on.

EDIT: I wonder if one could implement vector icons as fonts in order to properly hint them.

Re: About those vector icons

#13
The solution is in SVG itself. Set the id='s properly, and we can then do a simple map of existing hinting terminology directly into the DOM. Want less density at lower resolutions? Create a low-res layer within the SVG specifically for this case. The strength is entirely in the language used to declare the hinting; this can be directly incorporated in SVG, and thus made accessible to designers immediately (Inskcape -> Ctrl+Shift+X, start your engines..)

Re: About those vector icons

#14

Earlier quoted context omitted.

> Auto hinting is not the ultimate solution, but it can get you part way there, just like with fonts. Even without auto-hinting, it still boggles my mind that "desktop" vector formats don't seem to support hinting at all: I recently discovered there is no possibility of hinting in SVG, therefore SVG fonts (fonts described using SVG shapes) can not be hinted at all, that's completely insane.

YES. Given how long we've been building up to resolution independence, given the already long standing real-world examples of vector object hinting provided by fonts... it's amazing that there seems to be little work in this area and less work in terms of actual standards/implementations. This is an area Apple is perfectly, ideally positioned to execute and lead on. EDIT: I wonder if one could implement vector icons…

> I wonder if one could implement vector icons as fonts in order to properly hint them.

That's exactly what is happening these days with custom font embedding having become practical (in web pages): http://somerandomdude.com/2010/05/04/font-embedding-icons/ (that was in 2010, but this thing is really gaining traction these days following the release of "Font Awesome" for Twitter's Bootstrap[0])

In desktop OS, that is in fact a very old technique, that's why the Marlett font exists in Windows [1].

It does have a significant inconvenient though: the icon can only have one color for the glyph and one for the background. This provides a crisp look but lowers the expressivity of the icons. On the other hand, if the color scheme changes for some reason (or can vary from one page to an other), it is very easy to match the icons's color scheme to that of the application.

[0] http://fortawesome.github.com/Font-Awesome/

[1] http://blogs.msdn.com/b/oldnewthing/archive/2012/01/16/10256...

Re: About those vector icons

#15

Earlier quoted context omitted.

YES. Given how long we've been building up to resolution independence, given the already long standing real-world examples of vector object hinting provided by fonts... it's amazing that there seems to be little work in this area and less work in terms of actual standards/implementations. This is an area Apple is perfectly, ideally positioned to execute and lead on. EDIT: I wonder if one could implement vector icons…

> I wonder if one could implement vector icons as fonts in order to properly hint them. That's exactly what is happening these days with custom font embedding having become practical (in web pages): http://somerandomdude.com/2010/05/04/font-embedding-icons/ (that was in 2010, but this thing is really gaining traction these days following the release of "Font Awesome" for Twitter's Bootstrap[0]) In desktop OS, that is…

I've used custom embedded icon fonts on websites as well, but I was actually thinking of the more complex ui components through layering. I.e. button background/foreground combinations for buttons.

I suspect that there would be a whole host of other issues (rending of baseline location varying by a pixel, etc.).

Re: About those vector icons

#16

Long but good article. Glad he got into (and linked to the excellent article about) font hinting, because that is of course the solution. A simple vector format is not enough, you need to define what parts should scale how, which are rigid, which are elastic. I don't think higher resolution displays actually help, because the real limitation becomes the human eye. Though the new display could use the 'old' normal siz…

I agree it was a fascinating look at the problem. However, the assumption in the article is pixels. Let me sum up.

Scaling artifacts occur because at smaller sizes the quantitization of the unit pixel overwhelms the details of the image. When I was a system programmer at the Image Processing Institute at USC (you know the source of that Lena picture :-) this was characterized as the frequency response of the display. So if you were to take a horizontal line across the pixels, and then plot their intensity vertically along a line (so x becomes the position in the line, and y is the intensity of the pixel at position x) then you can then do an FFT across those pixels and see the distortion in the visual signal from the source material to the displayed material.

Now the part that gets confounded in articles like this one is that the UX designer doesn't really want a 16 pixel icon, what they want is an icon that has a certain size with respect to the whole screen. Working backwards, lets say the icon ended up being 16 x 16 on a 1024 x 600 screen which had 72 pixels per inch. The icon is about 1/4" on a side (.22" but you get the picture). Now on a screen that that has 240 pixels per inch, that icon at 16 x 16 pixels is only .06" or nearly impossible to see, but if you keep it at 1/4" you get 60 x 60 pixels to work with.

So lets bring two things together, you do 'hinting' because the artifacts that are created by the quantitizing effect of pixelation cause you to lose information. As screen resolutions get denser the information lost goes down (less quantization, or more signal bandwidth is available) so once your signal loss from a straight mathematical shrink is acceptable in all required sizes your done.

Bottom line is that this won't be an issue when the minimum icon size is being rendered into a field of 128 x 128 pixels or more. Might take one more generation of screens.

The second thing is that while a designer can poke pixels to get an icon that looks good, so can the computer. One of the things you can do is compute the frequency 'footprint' of the image, then change the render until the render foot print is as close as you can get to the original. HP did this for their ink jet printer half-toning algorithm. In a 16 x 16 pixel space you could almost exaustively search it on a modern machine.

Re: About those vector icons

#17

I'd like: 1. native support for optional manual hinting vector icons 2. native support for optional auto-hinting vector icons Auto hinting is not the ultimate solution, but it can get you part way there, just like with fonts.

> Auto hinting is not the ultimate solution, but it can get you part way there, just like with fonts. Even without auto-hinting, it still boggles my mind that "desktop" vector formats don't seem to support hinting at all: I recently discovered there is no possibility of hinting in SVG, therefore SVG fonts (fonts described using SVG shapes) can not be hinted at all, that's completely insane.

SVG fonts are a failed font format, which is why Mozilla refused to support them. They had a brief use as iPad fonts but that's dead now.

Re: About those vector icons

#18
This is an interface design/hardware issue, not a display optimization issue.

The article makes the bulk of the case for pixel optimization while discussing very small icons, and that's true, but it's a red herring. Interfaces should never rely on users being able to identify or interact with icons that are 16x16 pixels. At 64px, all of the icons seen in the article can be auto scaled successfully (in gimp, cubic transform): http://imgur.com/a/DOAyW

What we really need is to stop building hardware that demands 16x16 pixel elements, and to stop building interfaces that provide them. With high dpi screens, even character hinting becomes silly (or even without high dpi, I disable hinting on my 22" 1920x1080 screen because I like consistent letter spacing).

Pixel optimization experts may still have a place in the future, but it's likely in the same boat as audiophiles and $1000 HDMI cables.

Re: About those vector icons

#19
Oxygen icons (by KDE project) use SVG for all sizes of icons. Here is an example:

http://wstaw.org/m/2012/03/18/plasma-desktopA20554.png

(The icon on the left is suited for 16x16 size. The icon in right is the same icon, just suited for larger scales)

I think this scheme is supported by FreeDesktop.org's Icon Theme Specifications and other icon theme's used on Linux desktops (like Tango) use the same scheme.

Re: About those vector icons

#20

Long but good article. Glad he got into (and linked to the excellent article about) font hinting, because that is of course the solution. A simple vector format is not enough, you need to define what parts should scale how, which are rigid, which are elastic. I don't think higher resolution displays actually help, because the real limitation becomes the human eye. Though the new display could use the 'old' normal siz…

I agree it was a fascinating look at the problem. However, the assumption in the article is pixels. Let me sum up. Scaling artifacts occur because at smaller sizes the quantitization of the unit pixel overwhelms the details of the image. When I was a system programmer at the Image Processing Institute at USC (you know the source of that Lena picture :-) this was characterized as the frequency response of the display.…

> The second thing is that while a designer can poke pixels to get an icon that looks good, so can the computer. One of the things you can do is compute the frequency 'footprint' of the image, then change the render until the render foot print is as close as you can get to the original. HP did this for their ink jet printer half-toning algorithm. In a 16 x 16 pixel space you could almost exaustively search it on a modern machine.

Cool! Do you have a link/paper/book?

Post reply on HN