A black dot on a huge white canvas is much more efficiently encoded in a vector format, while a large stack of semi-transparent real-world images is much better off encoded as a bitmap, because this stuff is nearly impossible to do with vectors. The only question is at what level of complexity vectors start to lose out on bitmaps.

And anyone who thinks that flipping individual pixels is a good thing will be in for a surprise when our displays get resolutions that are high enough to make it impossible to see individual pixels and we can simply scale a high resolution bitmap or a vector image as required. Just look at the print industry, they’ve been here for decades.

Trust me when I say that this is a lot of work for the programmer. They’re not going to do just to have slightly better quality.

There is no image file format that combines bitmap and vector formats into a single file.

The bottom line: choose bitmap or choose vector. You can’t have it both ways.

-ch

I added a list of links and comments to related texts at the end of this post. Daniel Jalkut touches some of the challenges of resolution independent user interfaces……

Also, the ‘extra time’ argument is moot. As I noted, if you want to use vector-based toolbar icon artwork for higher-end desktops, you can do so with the code I specified.
And if you need to go resolution-independent, and you assign me, or you a case to make said toolbar resolution independent, we make vector icons. I’d say that anyone who uses a bitmap editor for such work is in the wrong business. Therefore, there is no drawback to using PDF-based Postscript icons and a 32 pixel original representation; they just have to line up correctly. So the client could say he wants the same toolbar icons at 128×128, 288 DPI – then you downscale and export the vector icon as a bitmap. I haven’t seen Toolbar icons with overwhelming complexity and detailing (as I said in the post, Dock icons are a sure case to be excluded from the PDF usage). So I stand by my point; for an interface that can scale into the future, PDF icons should be used on a switched basis with the original 72 DPI bitmap resources.

Compare the specification for SVG against the

specification for PDF.

You’ll see that there are a completely different set of graphics primitives in the two systems. As an example, the specification of gradients is completely different and only SVG has a filtering mechanism (allowing things like Gaussian blur.)

A compact representation in SVG does not mean that the same thing will happen with PDF.

Also, as you note, SVG is not an option on Mac OS X. And given the history of Quartz (as a descendent of Display Postscript on NeXT) it’s unlikely that will change. Adobe seems to be abandoning SVG in favor of Flash — it’s likely that SVG will fail to see wide support in other operating systems even though it’s an a more advanced format.

Next, it’s entirely possible to create a toolbar icon with PDF. It’s also possible to walk through a minefield.

You just have to take your time and make every step carefully.

If you have a paying client, the extra time comes at a cost. We stand by our original advice of limiting PDF icons to very simple shapes. A good example are the Carbon stock icons:

http://stockicons.com/detail/113

-ch