The faster and faster JavaScript engines in modern browsers and the rise of new technologies like Typed Arrays, Web Workers, and the File APIs mean that browsers can actually be used to read in binary formats completely on the client-side (as long as native performance isn’t a requirement).

For now the library includes two main capabilities:

• streams for reading in bits and bytes from a Typed Array
• unarchiving zip, rar or tar files (that’s right, you can unzip and unrar in JavaScript now)

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…

One thought that occurred to me is if I can shove the SVG into a HTML5 Canvas element, I can then call toDataURI() on it to generate a PNG. Unfortunately only Opera seems to have experimented with loading SVG into a Canvas directly. Also, there are many effects that can be done in SVG that cannot be done in Canvas (filters, fonts, and more).

The Canvas2D API does mention that in the future, the svg:image element may support the CanvasElement DOM interface. I’m anticipating Microsoft to announce <canvas> support for IE9 later this year and probably to support this interface on svg:image elements. It’s one way they can innovate on the web standards front while they continue to catch up to other modern browsers.

This would be good, but why only the svg:image element? I’d argue that any element that contains some geometry could gain the toDataURI() method (particularly useful would be the <svg> element here).

Until such time as browsers all get in sync, there are other options. canvg is one such option and I’ve been dutifully raising bugs and writing teeny patches but there’s a long ways to go for a robust solution.

Ultimately this is another case of why am I doing something in script that all browsers already know how to do? You really have to think long-term in the web space, don’t you?

Other ideas?

One of the surprising factors in SVG-edit has been using GoogleCode in combination with Subversion. Let me tell you why:

Linked Information

Everything is an issue in SVG-edit. This is the way we keep track of things to do. This is the way other people discover things they can work on. This is the way we prioritize features for a release. This is the way we identify good first bugs for new hackers to work on. This is the way we sort problems into browser-specific, usability, interoperability categories. This is even where we put requirements and design decisions.

Making almost everything an issue is good because GoogleCode has some magic that detects revision commit messages and message comments and inter-links the two. For instance, if I fix issue 436, I might do:

$ svn ci -m "Fix Issue 436: Fixed the foo thing"

This shows up in GoogleCode here and provides you a link to the issue.

Now in the issue itself, I can mark it as Fixed and mention the revision that fixed the issue:

Fixed in r1275

Once again, GoogleCode provides a link to the revision when you look at the bug.

This kind of tracking takes a little bit of discipline, but it’s not that bad and the payoff is worth it. It really helps other developers keep tabs on what’s been solved where and how.

Host It

Since SVG-edit is a 100% client-side application (i.e. everything happens in the browser, no server component), and since Subversion allows you to specify MIME types by setting properties on files, we can convince GoogleCode to host the entire project in runnable form for the purposes of demo-ing the code.

This applies to the trunk as well as any branches and tags. For instance, you can actually see the evolution of SVG-edit over time:

• SVG-edit 1.0
• SVG-edit 2.0
• SVG-edit 2.1
• SVG-edit 2.2
• SVG-edit 2.3
• SVG-edit 2.4

Or you can look at the latest trunk build.

Or you can host the file in a web page by using <iframe> element like I’ve talked about before.

The fact that GoogleCode servers host the repo and also support web serving the content is immensely powerful: it means we don’t have to administer a source code repository and we don’t have to pay for a dedicated server or bandwidth costs to demo the software. Furthermore, because it’s a browser-based app, users don’t have to download anything, they can try out the code right on the spot.

Incidentally this is also one of the strengths of a web app in the first place: Zero downloads.

Tracking Down A Regression

GoogleCode’s hosting of the svn repo doesn’t stop at branches/tags. In fact, you can look at ANY revision in the browser directly. Coupled with the fact that we don’t really require a build step means that it is very easy to track down a regression.

git has this cool feature called bisect that allows you to hunt down when a regression occurred by seeking forward/backward across revisions in increasingly smaller increments, building each revision and testing until you find the first revision in a branch that exhibited a problem.

We can do this much easier in SVG-edit using Subversion on GoogleCode. Let’s say one day we notice a problem in the trunk and we’re at r1200. Well, we might decide to try out the editor at revision 1000 to see if the problem existed then. If the problem did not exist, we hop ahead 100 revisions to r1100 – was the problem present then? If so, hop back 50 revisions to r1050. Repeat in the browser until you isolate the earliest revision where the problem occurred, then add a comment to the issue and go review that revision.

Totally amazing capability and no more difficult than changing a revision number in the browser location bar. I have to credit Narendra Sisodya, the project founder, with uncovering that little nugget.

Not a Nirvana

There are still some grips/nits I have with GoogleCode+Subversion:

• Being able to serve gzipped JavaScript would be great
• Being able to display the current revision number in SVG-edit
• The wiki markup needs significant improvements

But this is free hosting and project management software, so I can’t complain too loudly.

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.

For those who have more time to kill, here are a couple screencasts I tried to make that demonstrate the new features:

And there’s lots more coming in SVG-edit 2.5 (codenamed Bicorn) that we’ll be talking about in the future.

To celebrate, here’s another comic I made using SVG-edit (view full size):