31 May Truths on Resolution Independence.
Category: Apple, Design

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.

You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

5 Responses

  1. First off, any observations you make regarding SVG cannot be applied to PDF.

    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:



  2. 2

    First of all, it might be my awkward English but I didn’t suggest picking up SVG on OS X for any vector-based work. It can’t be done, and as you noted, I told about PDF being Quartz’s ‘format’. In no way do I suggest SVG is plausible or recommended for anything on OS X.

    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.

  3. @sebastiaan – Cocoa references toolbar images by name. Switching between bitmap and vector images would mean detecting that the screen resolution had changed and then swapping each name for the image reference.

    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.


  4. The part that I’m missing in this ongoing discussion is that for bitmaps without compression, the size and hence the amount of processing required to work with them can be expressed as width*height*bitdepth. So double your resolution, quadruple your bitmaps. For vector images, the file size and processing depend on the complexity of the image, and, to a lesser degree, the size of the bitmap it’s eventually rendered to.

    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.

  1. 5
    Quarter Life Crisis (via Trackback)


    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……


  1. Quarter Life Crisis