The Breakroom

My previous post on Resolution Independence for Developers has received some criticism. To begin with, I’d suggest that people read our initial post after WWDC—we do all our design work with vectors and recommend that method to others. We’re not trying to hold onto established bitmap formats; our workflow would be much simpler if we could deliver vectors directly to clients.

Other critics have commented that the CandyBar PDF contained images. To be honest, I didn’t think about this when I asked one of our designers to create a PDF file with an icon.

It’s true that the CandyBar PDF can be optimized. Printing to Postscript and then using Distiller to create the PDF is one method. This extra work shrinks our original 3 MB example down to about 1 MB. Much better, but still an order of magnitude larger than the PNG file, and you lose the ability to edit the icon.

The question you must ask yourself is why are there bitmaps in the PDF file in the first place? That’s where we begin our rebuttal.

As a software developer, I don’t care how a graphic designer creates an image. I know that they use tools like opacity, luminosity, Gaussian blur, inner glow, and transparent layers to achieve the final effect. I have no idea of how it relates to the final file size.

And that’s a good thing. Do you really want to put yourself in a situation where you have to specify the effects your graphic designer is allowed to use? Are you even aware of all the effects they have at their disposal? Do you know how each effect contributes to the final file size?

In spite of the fact that vectors work in any coordinate system, tools that produce illustrations have resolution settings expressed in pixels. Why is that?

The simple truth is some effects cannot easily be expressed with mathematical equations. This, in turn, prevents a compact representation in a layout language such as Postscript, PDF or SVG. The workaround is rendering the effects as bitmaps within the layout (using the selected resolution.) This is why file sizes increase as the working resolution increases.

To see this in action, let’s examine a simple Illustrator document. When the circles are rendered without any effects, you get a file that is 16 KB (non-optimized.)
When you add transparency, a blur, and a multiply between layers the file size doubles. The culprit is the circle on the right—it is now a bitmap.

Of course, it’s entirely possible to create an icon without any effects. It’s even possible to do some very creative things with simple vectors. But it won’t fly with a client who’s intent on winning an ADA.
To them, it will look like it crawled out of a Postscript printer in 1990.

So where does that leave us? With a realization that, in practice, “vector” PDF files are no longer resolution independent.

All of this is just a long winded way of explaining Apple’s recommendation in the Resolution Independence Overview (pg. 23):

Vector-based art is automatically scalable, so you should use vector-based images for simple artwork; such as black-and-white images or flat images without dimensional detail (such as shadows or gradients).

In summary, our original advice remains. If you’re a designer, create with vectors to future-proof your work. If you’re a developer, bitmaps provide the best combination of size, speed and appearance. And if you decide not to take our advice, we promise not to hold it against you. :-)

The Iconfactory is pleased to offer a significant upgrade to IconBuilder, our powerful and flexible icon construction filter for Photoshop and Fireworks. Version 8.1 adds full support for building Windows Vista icons including updated grid files and Photoshop actions. It also includes support for larger icon sizes in Mac OS X, multiple resolution TIFF files and a host of other updates and bug fixes. This upgrade is free for all registered Iconbuilder 8 users. Please visit the IconBuilder homepage for more information.

Over the past few days, a discussion about resolution independence in Mac OS X has started on some of the developer blogs we follow. The whole thing started with Resolution Independent Fever by Daniel Jalkut. Sven-S. Porst followed up with a more user centric view of the situation.

Although we’ve touched on some of the design and workflow issues required with larger icons, we haven’t offered any advice targeted at developers. For our readers who don’t know an NSImage from a DPI, we suggest that you go get some nice icons, because the rest of this message will get technical :-)

In many development tasks, the first solution you come up with isn’t necessarily the best one for the final product. When we first encountered resolution independence, it seemed like vectors were the way to go. You only have one file and it can be used on the desktop, in a UI or for promotional materials.

But as you begin to use vectors, you realize that there are some inherent problems with size, speed and appearance:

Size: Today’s photorealistic icons require a lot of vectors. More than you may realize. Unless you’re dealing with simple line art, effects such as gradients, shadows, and highlights result in enormous files. As an example, compare this 512×512 pixel PNG file of the CandyBar icon with a PDF file containing the same image. The PNG file is about 100 KB while its PDF counterpart is a whopping 3 MB. Consider a five icon toolbar with PNG files versus a toolbar with PDF files—500 KB versus 15 MB. Your ISP will love you and your PDF icons!

Speed: As developers we love to deal with abstractions—unfortunately, concrete reality often gets in the way. Vectors present a nice conceptual image model which fails when you consider today’s graphics hardware. Simply put, a GPU can’t deal efficiently with vectors. Processing of raster images can be sped up significantly by performing tasks in parallel—no such speedup is obtained with vectors. Try opening both of the sample images above in Preview. You can zoom in and out to get a feel of the performance characteristics of vector versus raster data.

Appearance: Like all Mac developers, we’re concerned about our application’s appearance. Scaling vectors that are optimized for presentation at a large size will result in images that look unacceptable at small sizes. The trained eye of a designer knows which pixels to keep and which ones to throw away—automated scaling of an image does not.

As you begin thinking about resolution independence for your application, keep these things in mind. A basic rule-of-thumb would be to use vectors if you can imagine the paths used to create the image. Daniel’s pie chart graphic would definitely fall into this category. If your brain can’t handle the complexity of an icon like the one for CandyBar, it’s unlikely that your Mac will be able to either.

If your graphic designer is following our previous advice for designing multi-resolution graphics, it will be a simple task for them to create the images you need with a tool like IconBuilder.