In the meantime, I’ve been carefully watching WebKit creep closer and closer to implementing the W3C File API (Go Kinuko!). Something I’ve been eagerly waiting for more browsers to do so you can open up local files in SVG-edit.

And then it hit me.

Why not a comic book reader done directly in the browser?

In case you don’t know, comic book archive files are just ZIP or RAR files containing JPEG images. Browsers can handle images. Some browsers can now handle opening local files. Even binary ones. So theoretically you could write unzip/unrar in pure JavaScript, extract the JPEGs, turn them into data: URIs and shove them into an <image> element. You can even do the unzipping in a separate thread using Web Workers.

Theoretically.

kthoom was how far I was able to get in a weekend.

Some limitations:

• Unzipping is slow. None of the code has been optimized yet and I’m probably doing a lot of really stupid things.
• Only supports CBZ files, not CBR files at the moment – I am accepting patches
• Unzipping is really slow. I need to provide visual progress reporting from the Web Worker thread, I know.
• kthoom will crash Firefox 3.6 about half the time. Firefox nightly (3.7) seems to handle it just fine. I opened this bug.
• Did I mention that unzipping is slow?

If I’m honest, this was really an exercise to see just how easy/hard it would be to do something like this in the browser – and to get some hands-on experience with Web Workers. And hey, I’m not the first or even second person to think of doing unzip/deflate in JavaScript either.

It was my first experience writing JavaScript to handle binary files. It was fun. It took a weekend.

Some essential tools: Firebug, a hex editor, pen & paper, a clear mind, patience.

Now swinging my attention back to stuff I should be working on…

I decided to go with my Solitaire demo because it was the most complete, didn’t infringe on any copyrights (looking at you Tetris), and most visually recognizable. It’s not the most innovative, but then again the point of this is not necessarily to win any prizes. It’s really about increasing awareness.

Unfortunately, the SVG (26kb) and JavaScript (16kb + 21kb) totaled 63kb. I did some cleanup of the SVG, minified the JS and then put the script inline with the SVG and then gzipped it. The result was a .svgz file that was 9kb. Perfect!

I then got an email from a friendly marketing/evangelism person at Microsoft who said that the engineers did not know how to open the svgz file to review the code to ensure it was under 10k. Woops! I explained to her that I thought it would be ok for the SVG to be gzipped, much as PNG/GIF files use compression and sent her the uncompressed SVG file for them to review. After all, SVG is just an image format, right?

Was I following the rules? Did Microsoft give me a fair shake? See for yourself. Who knows, maybe this is the first time a Microsoft admin had to figure out how to serve SVG on a Microsoft web server.

Out of curiosity, I later tried to see how far I was able to get down the Solitaire game: 5811 bytes. Not bad for a complete game that has scalable graphics. I’d be curios to see the equivalent SWF file.

I don’t expect you to vote for my entry, but what I do expect you to do is now go out and submit .SVGZ entries to the MIX 10k challenge. That one SVG entry is looking pretty lonely. If I can get Solitaire down to 5811 bytes, surely you can do better?

Thanks a lot to Amy, the evangelist/marketing person who really was quite patient with me.

A warm congratulations to Sam and a heartfelt Good Luck!