J. King Log

SVG is curious technology. In simple terms it was designed to drawn various shapes, especially useful if one aims to draw a diagram or chart. Most of the basic shapes are trivial to "draw" by hand, writing the appropriate markup in a text editor rather than using a drawing program. These same basic shapes also have fairly intuitive presentational attributes that can alter the appearance of the shape in question, all of which can be written without too much difficulty. However, there are several subtle problems which end up making hand-authoring of SVG a largely intractable option:

First of all, while drawing shapes is trivial, positioning shapes on the canvas and aligning them relative to each other is at best tedious, mostly quite difficult, and often practically impossible. Because the different kinds of shapes in SVG are drawn in different ways, it's often difficult to tell what is exactly where. Circles are drawn using a centre point and a radius; rectangles are drawn using an upper-left corner and a width and height; text is drawn using a point for the first character's baseline; other shapes are usually drawn by specifying a series of absolute points.

All these disparate drawing methods mean that it's often difficult to tell just how much space a given component of your drawing is going to take up, or even where on the canvas it happens to be! Considerable mental gymnastics are required to keep track of all the numbers required to position just a handful of elements; the mathematics required for even a vaguely complex drawing are too much for me to even imagine.

To make matters worse, aligning text is made that much more difficult when font substitution takes place, or if by some chance a user-agent sets a minimum or maximum font size, or if the drawing's font style is otherwise changed in some way. The textArea element helps somewhat in this regard, but that's just more numbers to keep track of.

At this point one might be tempted to cry out "Just use an editor!" or (if one is feeling particularly helpful but also a touch irate) "Download Inkscape and shut up, you fucking whack-job!". Aye, I would feel quite tempted to utter such phrases myself if I had no concern for the byte-for-byte size of my SVG drawings. That's a whole other can of worms, though:

I've tried a handful of vector-drawing programs, from Adobe's heavy yet featureful Ilustrator, to the clunky yet focused Inkscape, to more obscure pieces of software that merely export SVG, locking my source drawings into proprietary formats. Without exception, the drawings they produce are fat, fragile monstrosities that mix and match different requirements, hindering interoperability. Indeed, a long-standing habit of Illustrator involved defining namespace URIs as character entities, which are often not parsed by XML processors. Some ditors also thoroughly enjoy silently embedding bitmap thumbnails of the drawing itself, or references to hidden or previously removed shapes or images. An SVG drawing produced by Inkscape, even when saved as "plain" SVG, can easily be twice the size of the same drawing produced by hand.

In the end, I think SVG needs facilities for positioning shapes using more than one method for each kind of shape. It would help if I could position a rectangle using a center point; easily draw a line using a single point, a direction and a length; or plot an arbitrary point solely for the purposes of giving it an ID.

Probably, though, I'll just have to put up with fat SVGs. Either that, or I'll have to spend the rest of my life writing a gargantuanly complex post-processor to clean SVGs up. I think we can all guess which route I will take.