Looking back, the Iconfactory’s post on resolution-independence has some holes in it (and looking back now, this post has too – see the end of the post and the comments).
Why, you ask? They claimed that PDF’s in the user interface as a new format instead of the current TIFF files, the entire OS would come to a screeching halt, that icons would go beyond megabyte sizes and general mayhem would throw all resolution-independence craving Mac users into a purgatory. We knew different then, we know different now. A few months back, I posted about the ‘new’ Oxygen icon suite for KDE, being all SVG-vector based, and it didn’t wipe Linux off the face of the Earth. Instead, some optimized SVG files and rendering tricks made it work quite good, and these days, some ‘dock’-applications for GNU/Linux put the SVG’s to good use.
You can test this kind of stuff on OS X too, you know. First of all, as we all know from the rather public Resolution Independence segment of the “Leopard Features in Cocoa” session, free on the ADC Online iTunes page that we can define image resources of varying DPI values. You’d have the same size images if you open them in, say, Preview, but once zoomed in, it’s obvious that one contains four times as much pixel data. Assume that drawing units (points) are independent of screen pixels – if you take a 100*100 point image with 72 DPI, it’s 100*100 pixels. if you take a 100×100 image with 288 dpi, you get 400*400 pixels, but this 288 DPI image isn’t ‘larger’ on-screen; it would be as large as the 72 DPI image on a 288 DPI screen.
But you can be more flexible with vector resources. Now, I wouldn’t really use my own icons in vector format, because it -would- put the OS to a screeching halt, but we all know that there is no plan to make the Dock icons vector – instead, we are simply putting 512 pixel icon resources in all new ICNS files to keep the scaling possible. Toolbar icons, on the other hand, are often very simplified graphics. Take the GNOME Tango icon set’s trash icon as an example;
As you can see on the right, this SVG icon has a 72 dpi version in which the dark outline is exactly one pixel wide – we could compare this to toolbar icons, which generally have the same characteristics. One pixel-outlines, and often a lot of pixel-art to get it all looking proper in the 32*32 pixel space. No more! In OS X 10.5, we can do it the Tango way. It takes two to Tango, doesn’t it? In our case, one PDF vector resource (we don’t generally use SVG’s, OS X has a PDF graphics subsystem with Quartz) and either include a DPI-ready vector resource in the PDF (one that has a 1 pixel border on 72 DPI, for instance), or a separate file (a multi-representation TIFF) that is used with a little bit of Cocoa’s help. Apple has been kind enough to give you something to grab the screen’s DPI value and thus, do something with that. In the session, a solution like this was suggested;
NSImage (pointer) Name=Imagename Size={100,100} Reps=(
NSBitmapImageRep (pointer) Size={100,100} Pixels=100x100
NSBitmapImageRep (pointer) Size={100,100} Pixels=400x400
)
Of course, assumed here is that we are talking about our earlier resources; one 72-dpi 100*100 pixel image, and a 288 dpi 400*400 pixel image get put in place conditionally. Cocoa will chose the resource accordingly. If we can, however, we should use vector resources. They won’t ever give problems because they scale with our interface – you can set the PDF as the icon resource and as the workspace scale factor gets higher, the graphic scales accordingly and loss-less. I hear you say that perhaps, some high-end systems with high scale factors are able to render vector graphics of increased complexity without too much strain, and all systems with a smaller scale factor (I assume laptops and low-end desktop systems) don’t really want to render out vector graphics because they are both hard to parallelize and take battery life in the case of portables. Although there is an argument that rendering out vector resources smaller is faster anyway, representing vector graphics still is a lot more intensive than just displaying bitmap data. Perhaps an if switch is needed?
- (CGFloat)userSpaceScaleFactor;
This method returns the workspace’s scale factor and lets you act on it accordingly. It’s simple to set up this method and make a switch of resources (I will leave that as an exercise to anyone who has a ‘Leopard to build on’). Afraid this might make your application bigger? I wouldn’t worry about this too much. If you would upgrade your toolbar to this dual-resource system, all your 32*32 resources wouldn’t need the 128*128 resources, whereas the vector resources included are generally smaller than any bitmap data. It’s a small price to pay for a better looking app. Now go forth, and make sure I see some both efficient, pretty, and resolution-independence ready apps soon! If you need help, you can get information about my services at icondesigner.net.
Edit: Craig Hockeberry of the Iconfactory has commented on the whole matter, and after a bit of chatting I agree that it is overboard for an interface designer to talk about these matters of switching resources – however, it was meant in a ways of throwing around idea’s. I must say that I was wrong in a few other points; vector in PDF cannot yet be seen as a medium for all toolbar icons because it’s not efficient enough. I’d like to thank Craig for all the input.
