ecmanaut

Lately, I've been having a lot of fun hand optimizing SVG files for size, a bit like Sam Ruby does for his blog (it is highly instructive peeking at his collection, as I think I have mentioned before).

For me, SVG has something of the magical flair I first found in HTML in the nineties, back when it was the new bleeding edge New Thing, but I argue that it's even more fun than HTML was. The W3C SVG specs are not prohibitively difficult to read, and of course you have much greater graphical freedom than structured documents can afford you (duh!).

Like Sam, I try for something presentable in a kilobyte or less (uncompressed, though modern good browsers are as happy to render SVG:s delivered with content-encoding: gzip, of course, as long as they are otherwise correct and delivered with an image/svg or image/svg+xml content-type), and to never enforce a fix width in the svg tag itself – so they just beautifully grow to any size you want them to be, with no loss of quality.

Which is the other main beauty of SVG, besides being fly-weight, standardized, widely supported and still growing broader support in all the main-stream browsers. Over the last few years, the SVG front has been progressing happily and now is very practically useful already, for at least those of us that care most about Chrome, Firefox and Opera (I get the perception that Opera's often rather exceptional lead on the SVG support front is largely or even solely the work of Erik Dahlström, but I might exaggerate a bit).

Anyway, this weekend, I had fun turning the Laughing Man (from Ghost in the Shell: Stand Alone Complex) that @elmex vectorized at some point, into a 1000 byte version of my own, also featuring the gentle rotating text seen in the anime series (YouTube), via declarative animation (so there is no javascript involved here).

Edit: I initially missed an excellent opportunity here to plug Jeff Schiller's scour, which is an ideal first step when you start from an SVG source file. Be sure to run with -p something-large, as its defaults are being lossy about precision, which cuts needed decimals from some input files. With -p 99 you'll be on the safe side. Experiment with low single-digit numbers if you like (the current default – 5 – is often good), but make sure things are still looking right, or you may just ruin your file, rather than optimizing it for tiny foot-print. Broken images don't get extra credit for also being small!

The result is in this gist (if you install this user script, you can swap between *.svg text/plain source code image/svg rendition) or to the left, if your browser renders inline SVG:s properly in HTML content (I recommend the gist over view source, as Blogger inserts linebreak HTML tags unless I strip out all newlines first).

What surprised me, when I made this user script, is how far standards support has come in modern browsers: in order to inject the <svg> tag I create for the rendered version, I had to feed the source through DOMParser (as setting .innerHTML is lossy from treating the SVG content as text/html, not text/xml), and the few lines doing that, just magically worked in all of Chrome, Firefox 4 and Opera 11 (de-jQuery:fied, to make more sense outside of the script's context) with no special extra effort on my part:

// turn the raw SVG source string into an XML document:
svg = (new DOMParser).parseFromString(svg, 'text/xml');

// import it into an SVGSVGElement in this document:
svg = document.importNode(svg.documentElement, true);

// and insert that element somewhere in the document:
document.body.appendChild(svg);

To me, that's a rather clear sign SVG is ready for prime time now.

While github reports having no plans on serving *.svg gists with an image content-type (they don't want people using gists for image hosting, I guess, even though it's sad you can't easily preview without saving to disk or using my hack above) I still think the light-weight gist community oriented sharing is good for this kind of thing. Others happily forked the octocat SVG I similarly format converted a while ago from the github About page, and milligramme made this much spacier version.

I gather all my SVG play in a svg-cleanups repository on github, if anyone wants to get inspired the fork or follow way, and occasionally tweet about it. If you find this kind of exercise as much fun, I love hearing about it; here, on Twitter, github, or elsewhere. I believe it's good teaching and learning for the web as a whole, too. Any logos, trademarks and the like above are property of their respective owners.

I SVG:ified and played a little further with the logo material from the recently published Github about page, and then tonight I figured it would be fun to visualize the elegant process by which a raw SVG image is built up, piece by piece, by rather basic building blocks. With just a little bit of javascript magic to help you, here is how you piece together your own github schwag from scratch (works like a charm in Chrome, Firefox 4, and presumably any other modern browser that can handle inline SVG images):

If all you see is a button and the description of each step, that just means your browser doesn't natively handle inline SVG, which of course is a bit of a shame. Another reason I was curious to try this is for seeing how inline SVG:s fare in feed readers. (Google Reader seems to fail.)

Nicer source code for the images than in the page (Blogger insisted on filling all the whitespace with html junk) in these gists: github-logo.svg, octocat.svg. gist.github.com currently doesn't serve .svg files as image/svg, so you'll have to save them locally first to see them rendered.

Source code for the step-by-step drawing is in this gist; MIT licensed, if you want to fork away, adopt, adapt or whatnot. Have fun! I did. :-)

The other night I came across this cool Tree of Life page, featuring some pdfs and images of the family relationship of all life on Earth. Great stuff. Among them, this simplified rendition divided into about a hundred sub-families, and their relations:


You see our really ancient common heritage starting at 0 radians, progressing through evolution towards the really highly evolved creatures at two pi radians; birds, crocodiles, turtles and (you are here!) mammals (but in reverse order; sorry -- us mammals are not the last cry in evolution in all ways conceivable :-).

I liked it, but it felt wrong that it was trapped in a pdf; this kind of thing should really be a Scalable Vector Graphics image (SVG, henceforth) with cut-and-pastable text, and both readable and hackable right in the page source, for people like you and me that like to poke around in things.

So I made an exercise turning it into a somewhat nice SVG, to see both how small I could make it, without much effort, and where browsers are at in terms of rendering an inline SVG, these days. I haven't actually tested yet, so it'll be a fun surprise for me too, upon publishing this post. And if your browser doesn't render it, you still had the rasterized version above, or the source pdf (35008 bytes long).

Oh, and for the curious, there's a public git repository of all the changes on github, one step at a time, from the first version (where it's helpful to have a friend that has Adobe Illustrator, for instance, to do an initial machine translation of the pdf to a workable yet messy SVG). For reference, this page does not embed the minimized end result, which weighed in at 14852 bytes (or 6038, gzipped to an svgz).

(I consider those cheating, as the line data itself has been compressed somewhat beyond the point where it's still hackable.)

If you want to play around with this kind of thing, and get familiar with hand-editing SVG files, I can whole-heartedly recommend Sam Ruby's great library of sub-kilobyte hand-made SVG:s. While I can't find a statement to attest to it at the moment, I believe they are all freely MIT licensed (I think I asked him in person at SVG Open 2009), encouraging you to learn from and play with them. It is a great resource if you want to start playing with this yourself and want to pick up on some of the tricks of the trade, since they, on average, contain pretty much 100% signal, 0% noise.

Oh, and the SVG specification when you are curious about something specific. If you want to learn a minimal subset only that can do almost everything, look at the <path d="turtle graphics here"/> attribute.

And here is the outcome of my own craftsmanship, for the browsers that get it:



Unfortunately Blogger intersperses it with <br> tags if I leave the new-lines in, so see github for a cleaner version. No luck with my current set of browsers, with at least this doctype and HTML version. It does degrade to showing the text content of all the families, though, which a PDF wouldn't.

I've been cooped up a lot between real life, work and a low energy budget for a while now, but think I'm getting a hankering for some ideas I'd like to develop or see developed, again. Here's a little off-the-top-of-my-head list of a few of them, small and large:

• Data SVGs: Craft a few examples of how to encode data in its original raw form in SVG graph(ic)s and have the SVG render them right via coordinate transforms. Forward goal: get Wikipedia to incorporate this principle in their guidelines for how to represent data in vector graphics. Erik Möller (Deputy Director at Wikimedia Foundation) and Brion Vibber (CTO) both found this a cool idea. I ought to at least blog it if I'm not going to be the main advocate rallying people around the idea.
• Migrate Kronos Utils (user script here), which I'm not maintaining or developing as much as I used to, and other ikariam related hackery I've done at some time or others, to github, so others that want to hack at it have an easier time forking it. I apparently started doing that, at some time or others, in an ikariam repository, and then promptly forgot about it. *pushes recent changes*
  
  So I guess this pretty much boils down to migrating my updates off of Google Code and onto githubg. And figuring out how to have my pushes and/or commits trigger a tweet to @ikariam_tools, which apparently people have already spotted and started following, despite its severe lack of content. :-) Does anyone remember how that is done? I seem to recall some setting somewhere for it at github, but wasn't successful finding it in all of a minute's scouting around.
  
  Oh, and figuring out how to have vc-mode in Emacs do git things.
• Run the jQuery test suite from a Greasemonkey script, to figure out how much breaks under the Firefox javascript sandbox. It'll be nice to have fine grained data on which parts that remain useable and which don't, so maybe someone would even care to fix the latter.
• Revive the live Exhibit web scraper thing I crafted some year ago and never got to the point of happiness with where I ever blogged about it. With recent development in Ext JS, it seems it could get a nice UI indeed, this time in a pop-open window, so I don't have the CSS invasion problem, and don't invade the DOM we're trying to scrape.
• Don't fold comments on pages we arrived at through a permalink with a fragment pointing to something in the foldable section (at that point, we know we foremost wanted to read that specific comment, and not the article, so don't tuck it away). Edit: Done!

Taking down that specification in text instead of code seems indicative I'm not really in a coding mood today and ought to go have lunch. See you around!

In light of the rather successful outcome of my first SVG challenge (not called such at the time), I present another:

Challenge: craft an SVG with transform/viewbox/clipping settings to map WGS84 (that's latitude/longitude, as real numbers between -90.0/+90.0 and -180.0/+180.0 respectively) coordinates to the Mercator projection (used by Google Maps et al), making the image (conceptually) a client side WMS layer or map canvas object you can draw on via javascript using latitude/longitude coordinates, on top of (for instance) Google Maps.

The outcome of such a feat would be a boom in what you can (tractably) achieve, using only client side tools, in the geomapping department, or map mashups, in broader terms. Feel free to use the Google Maps API, if it helps in the number crunching department. (I have a feeling the linear algebra could and should be pulled off with just well engineered transform matrices, though.)

Unsurprisingly, I was not alone about wanting really pretty web stats graphs like the ones Scott at RAD.E8 design crafted (featured image), but in SVG form, as I proposed two weeks ago.

As it happened, within only the span of a few days, Jeff Schiller had taken on the challenge and made good progress towards those pretty SVGs. Being a somewhat seasoned SVG hacker, he even opted to introduce interactivity to the graph too, scripting it to show not only a static snapshot of a day's stats, but rather the entire history of his blog's visitors.



SVG, like HTML and presumably many other W3C standards to come too, ties in very neatly with ecmascript; embedding code is just as easy as javascript in HTML in the web world. Arguably even somewhat easier, as there is less legacy pre-DOM days baggage to bother about, SVG not having been with us since the dawn of the web.

Anyway, Schiller had already given the matter some thought previously, so I presume he was really waiting for the right inspiration to get going, and from what I gathered of his comments on the post, he was going to leave it there, as it was.

Wanting to see how far off the SVG front (in released browsers) is from being able to cope with making something as pretty as the originals, I picked up the ball and played some more with the code.

As it turns out, we are pretty close; it's really just some filters left, to add gaussian blur shadows for text and pies, perhaps some <textPath> to bend the text around the edge of the circle perimeter, and of course much, much better font rendering. Except that, we are more or less already there. I actually thought it was still farther off than that, but the good browser developer people have been busy.

Of course, picking the right font is also of utmost importance, but as fonts go, I am very unseasoned myself, so I have not even tried here. Having said font on the client side is also an issue I don't think SVG addresses yet, but I presume some decent set of fallback font specifications might render more or less as intended too.

The data featured in my graph is actually what my traffic looks like, since I started tracking this blog with Google Analytics, formerly (and still, by some) known as the Urchin tracker. It was a bit of work bending out the data from the view and massaging it to sum up <1% slices into bigger chunks, summing up sibling minor versions and the occasional really exotic browser into categories, but most of it could hopefully be automated, given some work. I have not dared experiment too much yet, as I don't want to trip a lock-down in sector four.

I'm not saying that applies to all Google sites yet, nor that it doesn't, but as I haven't dived particularly deep into the fine print of the Analytics terms of service I have so far opted to be cautious.

The really great thing not yet mentioned in this story, is the file sizes of these pretty things. The PNG thumbnails I opted to put in this post (as there is still quirks and issues to circumvent when inlining SVG images into page content, Jeff reports) each weigh in around 40 kilobytes, or 70 for Jeff's dual graph. My SVG and its companion external javascript file weigh in at two plus seven kilobytes, or together about a fourth of the size of the thumbnail, and they scale very nicely to any size, not just the 200 pixels high versions seen here. Jeff's version (presently) is a hundred kilobytes, but also sports not the data for one, but for a hundred and seventy graphs you can instantly switch among, at the click of a mouse button in the left graph, or arrowing back and forth via the keyboard.

For comparison, two kilobytes is roughly the size of the tiny flag images at the top right of my blog for machine translation to other languages (very forcefully frowned upon by my girlfriend, by the way, translator by trade) -- so not only can we expect to see much prettier graphics once SVG imagery becomes mainstream on the web, but we will also get much speedier delivery of them. And more bandwidth to spare for the video blogs to swallow it all up again.

Good times ahead, people.