Zero Dollar Bill

Los Angeles artist Brian Romero designed a zero-dollar bill as an anti-corporate statement:

I designed the font back in 1998. Well, ‘designed’ is maybe too strong a word; I traced the letters that appeared on a $50 bill and guessed (poorly) at the rest. Especially the X, which is just completely wrong, and the G, which is just completely awful.

But if you happen to like it (the font, I mean), you can download it over here. My other fonts are there as well.

Keynote Blues

Steve Jobs held the second annual WWDC 2006 conference this Monday in San Francisco. If we’d been seeing most of this stuff for the first time, it would have been amazing, but instead it was mostly old hat. Spaces? Yeah, neat. Time machine? Been there. iChat improvements? Yawn.

Gruber did nail it when he said that brushed metal was being taken out back and shot. It’s no longer anywhere to be seen in Leopard: Safari ditched it, Finder ditched it. I think even Calculator may have given it up.

A few interesting things were revealed, both in the keynote and on Apple’s website. Quick Look, as an operating system feature, is an interesting extension of the ‘Preview’ section of the Get Info panel. The Dock’s stacks feature is neat and useful, spelling almost certain doom for Stunt’s Overflow. The Finder finally gets rewritten, possibly in Cocoa, and sports an iTunes-esque interface.

Behind the scenes, native support for multicore machines will make it easier for developers to harness the power of parallel processing, and other improvements to I/O, networking, and computing abound. There’s really a lot of meat here, it’s just hard to see — which brings me to:

The Desktop, which gets superfluous menu bar transparency and reflective dock effects, altered shadows on the windows, and a general visual refresh. Apple really seems to be relying on Core Image and Core Animation for most of their UI, and therefore depending on a decent graphics card to drive it. Already on Tiger, older laptops with less video power are beginning to choke on Core Image effects.

Apple is not yet saying what the minimum system requirements are, but I’m guessing G5 and higher. If they don’t go pure Intel with this release, they certainly will on the next iteration.

Jobs’ “One More Thing…” was Safari for Windows, which was predicted by the Mozilla folks back in January. This seemed kind of lame for a development conference aimed at Macintosh developers. What are we supposed to take away from this — that Apple thinks it’s worth our time to develop applications for Windows?

Gragh.

Wither iPhone?

The only other big piece of news is that the iPhone will support third-party development via Safari. In the keynote, Jobs says that “The Way” to develop applications for the iPhone are with Web 2.0 / Ajax, distributed via standard websites.

This went over like a lead balloon. You can see it for yourself on the keynote address, starting at 1:13:52. The audience is dead silent. There is no applause, no enthusiasm as soon as they realize what they’re being sold. Even Jobs and Scott Forstall seem like they know how bad this ‘solution’ is.

There are two problems here. One is that no matter how many times Jobs said that these web apps behaved ‘just like native apps,’ it’s clear from the keynote that they don’t. Native apps don’t have a location bar pinned to the top of their window. Native apps don’t require you to click ‘Safari’ to launch them. Native apps don’t show a grey-white checkerboard where Safari hasn’t been able to re-render yet.

The other problem is distribution. Jobs played up the ‘distribution and updates are easy’ angle, since the applications are really running on your webserver. But as an application developer, I don’t want to be responsible for running the application. I don’t want to have to maintain a server that responds to web service calls. All I want to do is send the application to the user, possibly take some of their money, and never hear from them again (unless there’s a problem).

Introducing the need to run a server-side application which renders HTML for the iPhone is a huge, huge problem. I’ve done web applications before, and I’ve had to worry about whether or not my site can be reached, whether there’s a problem with the server, whether there are too many people trying to connect at once. It’s not very much fun.

I don’t have a problem with constraining iPhone applications such that their interface is rendered in HTML and their logic is implemented in Javascript — this is, after all, exactly how Dashboard widgets are implemented. But why the need to connect to the internet? Why not just provide widgets that use WebKit?

With WebKit + Javascript + Google’s Gears, you’d be able to make a nice widget for the iPhone, completely local, with its own data store. Slap it into a bundle, give it a nice icon, and let it sit in the home screen along with all of the other first class applications.

If it needs to get information from the internet, fine, but don’t require that. And don’t insult our intelligence by calling these ‘native apps’ when they clearly aren’t.

Truth & Beauty

A “Story Map” giving small bits of trivia that bind together the members of a wedding party, their family, and their close friends:

Absolutely gorgeous.

Vector Vs. Raster: The Fool's Game

Craig Hockenberry recently posted an article at the IconFactory regarding resolution independence in image processing. This is part of an ongoing public debate regarding the merits of using vector graphics instead of raster graphics for user interface elements, especially icons. I'm too lazy to link to all of the other people involved in this debate; there's a lot of them. Here are two of the salvos:

• Daniel Jalkut: Resolution Independent Fever
• Sven-S. Porst: Iconic

To paraphrase the problem for those just joining the party: monitors are getting bigger, pixels are getting smaller, and icons are becoming increasingly-larger in order to maintain their relative size on-screen. Some people think that vector-based images are the way to go, because their files are smaller and can scale cleanly to any size. Some think raster-based (pixel-based) images are the way to go, because even if they become very large, they can be specified exactly and are able to be drawn quickly.

This debate is becoming less academic and more pragmatic as time goes on, because Mac OS 10.5 Leopard supports icons that are up to 512x512 pixels large. Which, yes, is crazy.

I'd like to address Hockenberry in particular, because some things in his article really stood out for me. Hockenberry's article has the following main points:

• Today's icons require lots of vectors and are consequently huge
• Rendering vector icons is slow
• Vector icons look bad when scaled to small sizes

Someone's Snorting Something

To support his first argument, "vectorized icons are huge", Hockenberry posts two files -- a 512x512 rasterized PNG image of the CandyBar icon, and a corresponding PDF file that contains the same icon in vector format. As the PNG image is 100KB, and the PDF is about 30 times that size, he draws the conclusion that vectorized icons require more space.

Unfortunately, on this point he is dead wrong. If one uncompresses the PDF file (using pdftk, for example), you can examine the raw data inside of it. What does it contain? A total of 281 rasterized images, presumably one for each layer of the image:

 sdeken01@alondra: ~$ grep -i --binary-files=text "/subtype /image" CandyBar2.pdf | wc -l
 281

How much space do these images take? We can fortunately rely on the output to have a /length tag two lines following the /subtype /image tag, so we just need to look for them and tally them up:

 sdeken01@alondra: ~$ grep -A3 -i --binary-files=text "/subtype /image" CandyBar2.pdf | grep Length | awk '{ print $2 }' | perl -wlne '$t += $_;}print $t;{'
 48911164

Wait, how big was this file again?

 sdeken01@alondra: ~$ ls -al CandyBar2.pdf
 -rw-r--r--  1 sdeken01 pg528391 49306138 2006-11-15 08:05 CandyBar2.pdf

So 48,911,164 bytes out of 49,306,138 -- 99.2% -- are consumed by these images. That means that the actual vector data consumes roughly 394,974 bytes. That's still almost four times the size of the 103,102 byte PNG file, but it's not so bad.

We Don't Need No Steenking Compression

Of course, this is all assuming that PDF is the best format to use to store your vectorized icons. I submit that it is not. PDF is a verbose format which is geared toward representing anything that can be in a document -- text, vectors, tables, footnotes, etc. PDF exists to preserve the formatting of a document that is intended to be printed to a printing device or a computer monitor. It is far too heavyweight for the purposes of representing a vectorized icon.

In the long term, a better approach would be to develop a specialized vector icon format. (No, SVG isn't it. It's worse than PDF in verbosity.) A single Bezier path control point fits into exactly 24 bytes (48 if you want crazy precision), so in a 100KB file you can fit 4000 or so path nodes without any sort of compression. I have no easy way of counting the number of path nodes in the CandyBar vectorized file, but 4000 is an awful lot of points.

If we add compression, and we assume that we can get half the compression of the PNG file (which compresses the 512x512 image with 4 bytes per pixel from an original size of 1.05MB to 103KB, or 90%), we should be able to store close to 10,000 Bezier curve points in a 100KB file.

The gradients don't matter. They should add close to 24 bytes each, the same as a normal control point (8 bytes for the XY coords of each end of the fill, and 16 bytes for the start and end colors).

Rendering Vector Icons Ain't Slow

It's true that rendering the 8MB monstrosity that is the CandyBar PDF is an excruciatingly slow process. But this doesn't mean that rasterizing a vector image is slow. Computers do this all the time. Near-constantly, in fact. I suspect that just before you read this, your computer rasterized every letter in this essay using a vector-based font.

Did you notice a delay?

It's certainly true that rendering a vector-based image takes more time than rendering a raster-based image. However, the difference is small, and it can be mitigated in a number of ways. One way is to use intelligent caching, so that the image is rendered once and then resampled to produce smaller versions. Another is to leverage the graphics card to do some of the rasterization for the CPU.

But in general, rendering a vector image is not the slow, excruciating process that Hockenberry's PDF makes it seem to be.

Let Me Give You A Hint

The final argument -- that rendering vector icons at a small size produces worse results than placing pixels individually -- does hold some water. As the icon gets more cramped, there are more details competing for less pixels, and it's certainly true that an intelligently-designed 16x16 icon will beat a 512x512 icon scaled down in terms of crispness and general look.

But.

A generalization of this argument was put forth earlier by Josh Williams of Firewheel Design, and it's always sat the wrong way with me. Williams sets forth an argument that an icon designed for a specific resolution will look poor when scaled either up or down, because detailed line work which is intended to produce a single pixel at a particular resolution will be mapped to either multiple pixels (when scaled up) or fractional pixels (when scaled down).

Williams' argument bothers me because this is another problem which has been previously solved in the world of typography. Most major fonts have been extensively hinted so that they are legible at small point sizes. Verdana at 12 pt may seem like a bitmap on the screen, since it only stands 10 to 12 pixels high and does not contain any shades of grey, but it is stored on disk as a vector. The same font that produces the highly aliased 12 pt version on the screen is the same font that produces the highly anti-aliased 72 pt version on the printer.

It seems reasonable to me that a mechanism similar to hinting could be created for icon design. If you have a design element which is intended to be exactly one pixel wide, you could add hints to your control points to ensure that it uses exactly one pixel at every resolution. Or, as your design gets scaled down, you could use hints to remove paths that would result in unnecessary clutter, allowing the major design elements to stand out.

We do not have the tools to do such things today, and I'm not sure we ever will. After all, storing a customized 16x16 raster image doesn't take much space, and it's less cumbersome to work with than a series of carefully-crafted control point hints. I would expect icons to move toward a hybrid vector-raster format in the future, where certain sizes are represented with a raster image, and larger sizes are rendered from vector images. Apple has already laid the groundwork for this with their ICNS format, and some open source groups (such as the Tango project) are starting to get the same idea.

---

Hat-tip to John Gruber for the link. John notes:

Arguing for a new vector format optimized for iconography is not the same thing as arguing that vector art should be used for producing higher-resolution icons today.

I don't think anyone really disagrees about using vector art to design high-resolution icons. The majority of the 'sexy' icons on the Mac today are rasterized versions of vector icons -- the Firefox icon is vector-based, all of Jasper Hauser's icons are vector based, and there are plenty of other designers who use vector art extensively when producing icons.

The only question is: should these vector forms be distributed and used to render the icons directly on the fly, or should they be pre-rasterized and touched up for certain dimensions? I submit that we should have our cake and eat it too.

Update update: John meant distributing, not producing. Case closed!