Decades ago, back before HTML, WYSIWYG word processors, even before I started using TeX, I had the joy of creating documents using something called TROFF (pronounced Tee-Roff, with the emphasis on the Tee). It produced reasonably nice looking documents and it wasn't too hard to use for simple text.In fact, man pages were generally written for it's close cousin, NROFF, which was used for documents that were limited to fixed width fonts,as in a console terminal or a printing on the most common types of printers at the time, but I digress.
When writing academic papers, one typically needs to display more than straight text. Things like tables, equations, graphs and diagrams were called for, so Troff had the ability to include other objects, which were generated by other programs, like Tbl and Eqn.In many ways, it was not that different from what we see in HTML. There would be a special segment in the Troff file, demarcated by some tags (e.g. .TS to be begin a table, .TE to end), then the program in question would process the code inthose tags to generate the appropriate output (say a postscript file or similar). I won't bore you (any further :-) with the details, but there are some examples to be found through wikipedia.
To be honest, when I sat down to write this, I didn't remember all of these details about Eqn and Tbl, but I did remember Pic. In part I remembered because of the cool origin story (written by Brian Kernighanin a few days using this new fangled "parser generator", yacc) but mostly I remember it because it was so darn useful.
I think I may have had xfig at the time, or it might have been some other gui picture editor, but I found the precision and simplicity of Pic made it much easier to use for simple diagrams of the type needed for writing academic papers. I didn't have to worry about lining things up or resizing or anything; if the numbers matched it was good. If I wanted to tweak things a bit, simple search and replace worked well, or I had the whole of vi functionality to rearrange, duplicate or resize things quickly and easily.
But as I previously indicated, I haven't used Pic for years. After TeX replaced Troff, I used picTex for a while, but eventually that too was replaced by the more mundane tools required in a corporate environment. So, you can imagine my excitement when I realized, a few years back, that while I couldn't easily use Tex, I could use HTML without raising eyebrows, but even better, while I couldn't use Pic, I could use SVG.
SVG (Scalable Vector Graphics) is nominally an image format which, rather than being pixel based (like bitmaps, gif, png, jpg and a host of other formats) is based on vectors. Insted of being described by which pixels are what color, the picture is described by shapes; lines, circles, rectangles and other mathematical abstractions. The advantage to this is that a shape can be scaled without losing anything in the resolution. A circle in a jpeg file is really a collection of pixels painted a particular color. If you zoom in on the edge of the circle, at some point you'll see jagged edges, and then colored blocks representing individual pixels. Zoom in on the edge of an SVG circle and you'll always see a smooth curve, though like the earths surface it will get flatter the bigger it gets. You won't see big blocky rectangles (it's turtles all the way down :-) But one of the things I find fascinating about SVG isn't just it's scalability, or it's mathematical modeling, it's that it's human readable. I don't know of many other image formats about which I can say that (I have tried). And of course, being human readable, it's also human writable.
While the current SVG standard is not quite as sleek as HTML5, (there's still a bit of boilerplating to keep track of, and it's a little more picky) it can be used to program pictures in ways not too different from the Pic diagrams of old. It's form is similar to HTML, with relatively intuitive open and close tags containing options and data. In fact, when it is embedded in an HTML file, it can be used with CSS to ensure stylistic consistency.
Creating an svg tag in your document is pretty easy:
<!doctype html> <html> <body> <svg> <circle cx=50 cy=50 r=45 /> </svg> </body> </html>
The limitations of this blog don't allow arbitrary HTML code (nor .html or .svg attachments), so you'll have to copy and paste the code into an html file to see what I'm talking about, but if all goes well you should see a big black circle, with a center at )50,50) and a radius of 45. Now, I'm playing a little fast and loose here, technically you should quote the attributes (cx="50", &c.) and decclare xmlns and those kind of niceties, but I think the above works in most modern browsers.
Of course, you can do all the expected things like change the fill, stroke and transparency. There are lots of other shapes; regular shapes like rectangles and elipses, and arbirary shapes and lines described by paths and different types of curves and text elements. There are a lot of more complicated twists as well, like transformations, gradients and even filters. Now, all this isn't quite the same as Pic, which was designed to make diagrams easily. Pic had features that SVG doesn't (like well defined connection points on a shape, you coould connect the north end of one shape to the south end of another automatically), but you definitely couldn't create a gaussian blur filter. Also, if you're not like me and prefer to draw pictures using an actual graphical editor, don't despair; there are a lot of options. Inkscape comes to mind, as it specializes in SVG (in fact it's native format is a slightly modified form of SVG).
And of course there are some caveats. While SVG support is pretty good in Desktop browsers, it's still iffy on many mobile platforms (discovered that the hard way). Even on the Desktop there can be a noticeable performance hit when using some SVG features (especially certain filters). I tried to use a custom SVG as the background for a presentation recently, and discovered that it degraded performance to the extent that my transitions were awkward and jumpy rather than smooth. With great sorrow, I converted my svg to a png and the performance problems went away. It may not be a panacea, but it's still really cool, so I'll talk about it some more next week.