Volume Number: 16 (2000)
Issue Number: 2
Column Tag: Emerging Technologies

Scalabe Vector Graphics: An Introduction for Programmers

by Kas Thomas

Learn how this important new web document standard will impact web design and (quite possibly) OS X imaging

The World Wide Web is primarily a visual medium, and the primary unit of information display on the web today is the page - the web page. But despite rapid progress in offline document technology, the web page continues to be based on an archaic imaging model. The HTML (Hyper-Text Markup Language) display technology upon which 99% of the world's web pages are built was never designed to accommodate 48-bit color, realtime animation, on-the-fly antialiasing, infinite zooming, vector art, embedded Type 1 fonts and professional typography, pixel-accurate positioning of page elements, or any of the other DTP-inspired features modern computer users have come to depend upon in their daily work. In order to make high-end display features like these possible in HTML, nothing short of a complete rewrite of the HTML document model would be needed.

Fortunately, that rewrite has just been completed by the World Wide Web Consortium (W3C) and is now ready to enter service. The formal standard is called Scalable Vector Graphics (SVG) and can be found online at <http://www.w3.org/TR/SVG>.

Far more than just a graphics standard, SVG is a full XML grammar (with a public Document Type Definition) and an associated XML namespace, meaning that SVG can encapsulate not only images or text, but standalone documents. You can embed SVG files inside HTML pages using the traditional <EMBED> tag; or you can write whole web pages as freestanding '.svg' files (providing your server is set up to serve such files with a MIME type of 'image/svg'). Any well-formed XML file can embed SVG, and (conversely) any SVG file can embed well-formed XML - including SVG itself.

In the coming weeks and months, you're going to be seeing and hearing a lot more about SVG. In fact, SVG has even been mentioned as a possible basis for a future QuickTime Image Importer (something that, if it happens, will probably happen in the next 12 months); and in a talk given at WWDC last Fall, Apple's Peter Graffagnino (Director of Graphics and Imaging Software) hinted that developers targeting OS X might want to consider providing native SVG support in graphics programs.

Given the increasingly significant role SVG is likely to play not only in web graphics but in desktop graphics, now might be a good time to become better acquainted with this exciting technology. In this article, we'll look at SVG first as a document standard, with a view to understanding how its pieces fit together for maximum cross-platform interoperability. We'll have time to say a word or two about forthcoming tools for working with SVG; then we'll take a look at raw SVG code and try our hand at some JavaScript animation effects in SVG. We've got a large amount to cover in a short space, so let's hit the ground running.

In a strict markup-language sense, SVG is any XML document that adheres to the document type definition at <http://www.w3.org/Graphics/SVG/SVG-19990812.dtd> (or equivalent more recent version) and conforms to the rules set out in the standard at <http://www.w3.org/TR/SVG>. But SVG is more than just a tagset and a grammar for associating styles and attributes with graphics primitives. It's a philosophy for how text and graphics information ought to be encapsulated, manipulated via code, and rendered to output devices at runtime.

In a way, Scalable Vector Graphics is a rather peculiar moniker, with a redundant ring to it, kind of like "Peelable Yellow Bananas." After all, vector graphics are by nature scalable (i.e., capable of being enlarged or reduced indefinitely without resolution loss); you wouldn't think that point needed reinforcement. But maybe it does. We're all so accustomed to seeing GIF and JPEG files in fixed resolution on our browser screens that the thought of web graphics being infinitely zoomable (much less rotatable or draggable) hardly seems natural.

Vector graphics lend themselves to rescaling because they are not predrawn at any set size, as JPEG, TIFF, GIF, and other bitmapped images are. Instead, vector art is rasterized at the last possible minute, on the user's machine, using the maximum appropriate pixels-per-inch resolution for the output device in question, even including supersampling to achieve antialiasing. It's this peculiar characteristic of "late pixel binding" that gives vector graphics its versatility and power. When you virtualize your art elements - dealing with them in the abstract, drawing them only at the last minute ("just in time") - you can set up your render pipeline to perform any number of coordinate-space manipulations, alpha-channel operations, opacity ramps, blends, masks, clips, warps, morphs, overlays, etc., in any combination, without the slightest bit of resolution loss, because you haven't drawn anything yet. Once all the vector-space manipulations are complete and the user has chosen an output resolution, monitor mode, zoom factor, and so on and so forth, rasterization can begin. Then the image gets drawn - at the highest level of perfection attainable.

PostScript aficianados will recognize the concepts described here as inheriting directly from pioneering work done by Warnock and Geschke in 1984. The same concepts underlie PDF (as well as Adobe Illustrator and Macromedia Flash). But rather than using the postfix notation of PostScript, SVG uses ordinary markup-language tags to encapsulate drawing information, so that, for example, to draw a red-filled circle of radius 25 at an x-y position of [100,100] on the screen, one need simply do:

<circle cx="100" cy="100" r="25" style="fill:red" />

In the circle tag, the cx and cy attributes give the centerpoint coordinates of the circle in the current coordinate space (which by default has its origin at the top left corner of the browser window or current viewport, with 'y' increasing in the downward direction), 'r' gives the radius (in pixels, unless another unit system has been defined), and the style attribute specifies how the circle should be drawn.

The various built-in SVG geometric primitives and their associated tags and attributes are shown in Table 1.

You'll notice that whenever a parameter value is called for, it is given between quotation marks. (Also note that the ending tag is a forward slash followed by a greater-than symbol.) In general, the arguments and parameters to a drawing element aren't called arguments and parameters, but attributes and values. The attribute is the thing on the left side of the equal sign (such as cx), while the value is whatever is between quotation marks on the right side.

Lest you get the idea that SVG is simply a vector-graphics engine, bear in mind that you can embed bitmapped graphics inline in an SVG file using almost the same syntax you would use for putting GIF or JPEG images in an HTML file. An example of the syntax is:

<image x="10" y="50" width"100px" height="100px" xlink:href="mypic.png"></image>

The 'x' and 'y' attributes refer to the position where the top left corner of the bitmapped image should appear. The 'width' and 'height' attributes describe the dimensions of the destination viewport for the image (in this case, in pixels). You'll notice that the URL is referenced with an 'xlink:href' tag instead of the more familiar 'href' notation. This is the XML way of denoting a link to an external URL. All links - even to anchors within the host document itself - are treated this way in an SVG file.

The image file in this example is a PNG file: an image in the Portable Network Graphics format. This is one of two bitmap formats SVG supports, the other being JPEG. What about GIF? As it happens, there is no support for GIF. That doesn't mean that shipping software products that support SVG won't incorporate GIF support; some no doubt will. The formal SVG specification doesn't require GIF support, however. The reason for this has to do with patent rights. The Graphics Interchange Format (developed originally by CompuServe) uses Liv-Zempel-Welch compression as the default compression method. It turns out that this compression method is covered by a patent that Terry Welch took out in the mid-1980s on behalf of his employer at the time, Digital Equipment Corp. Through a series of corporate acquisitions, the patent ended up with Unisys, which in recent years has been sending its minions around to make sure users of the LZW algorithm pay royalties on it. This was enough to convince the W3C to abandon GIF support in SVG. Even though the Welch patent expires in 2003, there will - for now - be no formal requirement for GIF support in SVG.

In a greater sense, it doesn't matter, because PNG, which was developed specifically to replace GIF, is a big win for all concerned. Its feature set (which includes sophisticated lossless compression, alpha transparency, interlacing for progressive download viewing, onboard gamma adjustment, advanced checksum and corruption-detection techniques, and much more) goes well beyond GIF's capabilities, and since the source code is freely available, consistent implementation of the feature set is virtually guaranteed. (For more information on PNG, see <http://www.cdrom.com/pub/png>.)

If you're worried about not being able to offer advertisers on your site the ability to use animated GIFs, relax. There's something much better in store: namely, animated SVG. (We'll get to that in a minute.)

SVG's greatest visual impact on the World Wide Web, paradoxically, may very well come in terms of text. With SVG, a page containing mostly text (and let's face it, most web pages are primarily text) can be professionally typeset, drawing (if you'll pardon the pun) on Type 1 fonts in any size, style, color, or leading. Also, just as with PDF, fonts don't need to be present on the user's machine in order for a page to be imaged properly. Externally linked font resources can be supplied, and - if need be - the browsing application can retrieve needed resources from the appropriate URL(s) in real time.

What it means is that web pages, if written in SVG, could end up looking a lot more like magazine pages and a lot less like TTY emulation, with text that is zoomable (and properly antialiased) yet doesn't reflow every time the window is resized.

In SVG, text takes two forms: its ASCII (or Unicode) encoded form, and its stroked/filled form. The encoded form is always present inside the file, where it can be traversed by search engines. But most of the time, we're really talking about the graphical representation of text: fill color, stroke color, size, opacity, character width, and so on. Remember that in SVG, as in PostScript and PDF, everything that gets painted to the screen (except for inline PNG or JPEG graphics) consists of stroked and/or filled paths. That includes font characters, which are just closed bézier-curve paths.

Specifying text in an SVG file is almost as easy as specifying text in an HTML file. For each text element, you simply do something like this:

<text x="72" y="144" style="fill:black;
	font-family:Helvetica;font-size:18">This is 18-point Helvetica.</text>

The text in this block - which says "This is 18-point Helvetica." - will be drawn one inch (72 pixels) from the left side of the viewport and two inches (144 pixels) down from the top. The style attribute contains property:value pairs for fill color (black), typeface (Helvetica), and type size (18 points). Note that text blocks must be terminated with a </text> closure.

As you can see, this is not a terribly difficult syntax to master. The only part that may cause some consternation is the fact that each line of text you put on a page has to have a specified starting position. Text doesn't wrap automatically. . This is either a blessing or a curse depending on your outlook. For most users, most of the time, line-wrap won't be a problem, because most users will rely on commercial authoring apps (such as Adobe GoLive, which will feature full SVG support) to produce line-wrapped SVG text automatically. Even Adobe Illustrator (which has an SVG export plug-in) does a fair job of justifying large blocks of text. It's only at the (low) level of hand-crafting your own SVG files in a text editor that you have to "sweat" things like line breaks, tabs, and interline spacing (leading).

SVG supports inline, embedded, and/or external stylesheets under CSS2 (the standard for Cascading Style Sheets), and also allows font embedding, which means a couple of things. First, if you're comfortable already with CSS stylesheet conventions vis-á-vis HTML 4.0, you'll feel right at home with SVG, because you'll use the same syntax to define styles and selectors in SVG, placing style sections between <style></style> tags. Secondly, the font-embedding capability means you won't have to worry about whether your user has, say, Antique Olive Bold on his system; you can provide external links to font resources, and the viewing application, if it can't find the needed resources on the host machine, will automatically retrieve the fonts it needs via http. (Don't worry about licensing issues where genuine Adobe fonts are concerned: the various Adobe apps that support SVG will export font subsets automatically, and Adobe has taken a liberal posture on the use of its Type 1 fonts for web purposes.) In general, many of the same rules that apply to PDF files will apply to SVG. Namely: To save bandwidth, you shouldn't go too crazy with font usage; always subset rather than embed the whole font; and you can safely assume that all users will have access to the base-14 printer fonts (Helvetica, Times, and Courier families, plus Symbol and Zapf Dingbats).

In terms of structure, an SVG file follows some fairly simple organizational rules. At a bare minimum, an SVG file will be made up of a header section followed by the "contents" of the document set between a pair of <svg></svg> tags. Two fairly typical optional components are CSS stylesheets (which we just discussed) and embedded JavaScript. Stylesheets are embedded using <style></style> tags, while scripts are embedded using <script></script> tags. (Sound familiar?) The ordering is not important. You can have the graphics content first, followed by stylesheet info, followed by JavaScript functions, or any ordering of those components that suits your taste and work habits. For parsing, it doesn't matter.

The header portion of an SVG file looks a lot like the header portion of any XML file, except that the DTD reference points to a Document Type Definition (on the web) that pertains sepcifically the Scalable Vector Graphics file, as you'd expect:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 12August 1999//EN" "http://www.w3.org/Graphics/SVG/SVG-19990812.dtd">
<svg xml:space="preserve" width="4000" height="3000">

The reference to "iso-8859-1" in the first line is an indication that the SVG file in question is in ASCII format. (International Standards Organization standard No. 8859-1 is, in fact, the American Standard Code for Information Interchange.) If you were to infer from this that text encodings other than ASCII are possible, you would be correct. SVG is a thoroughly modern standard, able to support Unicode and (potentially) other encodings besides ASCII. This means, for example, that it is possible for users of CJK (Chinese, Japanese, and Korean) fontsets to create SVG files in their native encodings. So if Western cultures decide not to embrace SVG, it's still possible that other cultures will decide to run circles around us with it.

The second line, beginning with !DOCTYPE, gives SVG version info (the version info in line one applies to XML) and tells where the Document Type Definition for SVG can be found on the web. In theory, this provides a mechanism whereby browsers and viewing applications can be self-updating, retrieving the latest SVG grammar and syntax rules on an as-needed basis should they happen to be revised.

The third header line identifies the rest of the file as constituting the SVG contents. The xml:space="preserve" notation gives the viewing application some idea of how to handle whitespace characters (such as tabs ), namely by treating them as individual spaces rather than, say, collapsing adjoining whitespaces into a single space. The width and height numbers tell how big a drawing canvas (virtual drawing space) to allot to the SVG contents, in default user-space units (i.e., pixels). In this case, rather generous dimensions apply. What happens if the screen dimensions are only 640 by 480? Nothing. The image's "live viewing area" will simply constitute a 640x480 peephole into a total canvas area of 4000 by 3000. Anything that won't fit into the monitor space simply gets cropped at the edges. But you can still scroll or hand-move the image as necessary to see other "off the edge" portions of the image. Also, most SVG viewing applications support zooming, so that if the image is actually 1200 by 900 pixels in size, but the monitor is only 640 by 480, zooming out by a two-to-one factor will bring the entire image into view.

With everything we've said thus far, we're ready, finally, to show the complete code for a standalone SVG file (see Listing 1). The image that this file produces is depicted in Figure 1.

Listing 1: Logo.svg

Logo.svg

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 12August 1999//EN" "http://www.w3.org/Graphics/SVG/SVG-19990812.dtd">
<svg xml:space="preserve" width="1000" height="1000" >

<style type="text/css">
.redfill{fill:#FF0000;}
.whitewords{font-family:Times-Bold;font-size:36;fill:#FFFFFF;}
.circDuSoleil{fill:#FFFF22;stroke-width:4;stroke:#0000FF;}
</style>

<circle cx="200" cy="100" r="40" class="circDuSoleil" />

<g id="topLayer" 
  transform="scale(1.2 1) translate(70 40) rotate(10)">
<rect class="redfill" x="10" y="0" width="288" height="40" />
<text class="whitewords" x="20" y="30" >Powered by SVG.</text>
</g>

</svg>

The code is straightforward. We already discussed the meaning of the header lines. Within the <style></style> block, we have three CSS style selectors, named redfill, whitewords, and circDuSoleil. If you're accustomed to CSS style syntax, you should have no trouble deciphering the contents of these styles.

The first graphic element is a circle centered on x=200 and y=100, with radius 40 user-space units (pixels, by default). We have used the class keyword to specify a style from our style segment. The "circDuSoleil" style, in this case, is made up of a yellow fill color, a stroke width specification of 4.0 user units; and a stroke color of blue (hexadecimal #0000FF).

Notice, incidentally, that the graphic elements draw in the order in which they are specified in the source file. Since we specified the circle first, it draws "behind" all other objects.

Next, we come to a <g></g> block. The grouping tags (that's what 'g' stands for) enclose, in this case, two graphic objects: a rect and a text block. Before talking about the attributes given in the first <g> tag, let's quickly look at the graphic objects themselves. The rectangle is given a style of "redfill" using the class keyword. (Notice that this specification can occur at any place inside the graphic object. Here, it's at the beginning, before the geometric attributes.) The remaining attributes specify the rectangle's top-left-corner position and overall dimensions. The text block, on the other hand, is given the "whitewords" style (white fill color, so the words will stand out against a red background) and a starting position, onscreen, of <20,30>. The text will be in 36-point Times Bold, because that's what was specified in the "whitewords" style.

Now let's go back to the opening <g> tag. Inside that tag, we assign a name identifier to the group-as-a-whole ("topLayer") and specify some transforms to operate on the group. First there's a scaling transform, which has the effect of scaling everything in the 'x' dimension by 120%, while the 'y' dimension is left at 100%. The translate operation moves the whole block 70 units to the right and 40 units down. Finally, there is a rotate operation, which rotates the whole graphic ten degrees clockwise. (Note that the transforms are carried out in the order written.) We could also have specified a PostScript-style 6-digit matrix, with "matrix(1 0 0 1 0 0)," or whatever. (You wouldn't normally use the identity matrix!) In this kind of matrix, the first and fourth numbers are scaling multipliers in 'x' and 'y'; the fifth and sixth numbers are translation specifiers; and the second and third numbers are used for shearing. (They represent the tangent of the shear angle for each axis, respectively.) For rotation, one has to premultiply the first four numbers by the cosine, sine, negated sine, and cosine (respectively) of the desired rotation angle. Consult any book on PostScript for more details.

One of the most exciting aspects of SVG is that it hands JavaScript programmers something they've long been waiting for: a graphics engine with the power to produce scripted animations. Every component of an SVG document fills a spot in a DOM parsetree, and every nook and cranny of the containment hierarchy is reachable via JavaScript. That means you can manipulate pretty much every aspect of an SVG image file via scripting. What's more, your code can be located either in the HTML page that the SVG image is embedded in, or in the SVG file itself, or in an external file at a faraway URL. The choice is yours.

It's easier to show an example of scripted SVG than to explain how it works, so let's go ahead and try our hands at a bit of SVG animation. Listing 2 shows the code from Listing 1, modified such that the circle object now moves back and forth horizontally, in sinusoidal fashion, at the rate of approximately one round trip every 7 seconds.

Listing 2: LogoAnimated.svg

LogoAnimated.svg

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 12August 1999//EN" "http://www.w3.org/Graphics/SVG/SVG-19990812.dtd">
<svg xml:space="preserve" 
  width="1000" height="1000" 
  onload="startup(event)">

<style type="text/css">
.redfill{fill:#FF0000;}
.whitewords{font-family:Times-Bold;font-size:36;fill:#FFFFFF;}
.circDuSoleil{fill:#FFFF22;stroke-width:4;stroke:#0000FF;}
</style>

<circle id="circ" cx="200" cy="100" r="40" class="circDuSoleil" />

<g id="topLayer" transform="scale(1.2 1) translate(70 40) rotate(10)">
<rect class="redfill" x="10" y="0" width="288" height="40" />
<text class="whitewords" x="20" y="30" >Powered by SVG.</text>
</g>

<script language="javascript">

var gDoc;
var gCirc;
var gCount=1;

function startup(event) { 
	gDoc = getSVGDocument(event.getTarget()); 
	gCirc = gDoc.getElementById('circ');
	setInterval("BeginMoving();",1000/20);
}

function getSVGDocument(node) {
  // given any node of the tree, this will 
  // get us the SVGDocument node. But we
  // must be careful: doc root node's owner is null!
  if( node.getNodeType() != 9 ) // if not DOCUMENT_NODE
    return node.getOwnerDocument();
  return node;
}

function BeginMoving() { 
 	gCount += 0.044; 

 	gCirc.setAttribute('cx',
    240+120*Math.sin(gCount) ); 
}
</script>

</svg>

The first half of Listing 2 is the same as Listing 1: We have the same graphic objects, using the same CSS styles as before. The only change to the first few lines of code is in the first <svg> tag, where we've inserted a call to an onload event handler, a custom function called startup(). If you look down about halfway through the code listing, you'll see the start of our JavaScript block. As in HTML, scripts in SVG must be enclosed in <script></script> tags. Within those tags, we've defined three functions and three global variables. The startup() function executes as soon as the page is loaded. It initializes two global variables, gDoc and gCirc, with references to the Document object (for the SVG document) and the "circ" graphic element within the document. The reference to gDoc is obtained via a call to our getSVGDocument() function, which uses API calls to obtain the doc reference.

To get a reference to the circle object, we call the Document object's getElementById() function, which lets us get an object reference by using the object's name identifier. (Recall that we named our circle 'circ', in anticipation of this moment.)

The final action that takes place in the startup() function is to call JavaScript's setInterval() function, which gets our animation started. The first argument to this function is always a string literal that, when evaluated, tells JavaScript what code to execute during repeated calls to the animation. The second argument tells the interpreter how long to wait between calls to the first argument. This parameter should be in milliseconds. Since I wanted to try for 20 frames of animation per second (which is not overly optimistic for a small, simple animation such as this one), I gave a value of '1000/20' (one thousand milliseconds divided by 20).

The code that gets periodically executed by setInterval() should be quick to execute. Accordingly, our BeginMoving() function is relatively short and to the point. In the first line, we increment a counter variable. In the second line, we call the circle object's setAttribute() function and reset the 'x' coordinate of the circle's centerpoint to be 240, plus or minus 120 times the sine of the counter variable. That means the circle will oscillate horizontally about x=240, moving a maximum of 120 user units in either direction. (Notice that I don't say "pixels in either direction," because it's possible the user may zoom in or out on this animation while it's running, in which case the total travel of the circle most certainly will not be plus-or-minus 120 pixels.)

On my 250MHz G3 PowerMac with PrecisionView 17-inch monitor, the animation looks surprisingly smooth in Netscape 4.5, using the pre-release beta SVG plug-in that I've been fortunate enough to be testing these last few months. (Free plug-ins will soon be available for all major browser types, if they haven't been announced already.) Bear in mind, the circle is drawn behind the text and red rectangle. Yet the animation doesn't look "flickery."

This is, of course, a relatively trivial example of scripted animation in SVG. With a little imagination, it's not hard to think of some pretty far-reaching uses for SVG animation. One could, for example, easily set up physics simulations, finite-element analyses, or, in an extreme emergency, a "Hammer the monkey and win $20" banner ad.

Conclusion

Web developers have been waiting years for DTP features (like high-end typesetting, with font embedding) to arrive on the WWW, just as JavaScript programmers have been waiting aeons to be able to draw vector graphics to the screen. With SVG, all these features - and more - are finally here, and well within the programming ability of most web-page developers. High-end graphic arts tools will soon be supporting SVG en masse, but in my experience, you don't really need anything more than a "bare bones" text editor (if you'll pardon the expression) for all but the most challenging of SVG layouts. It's quite feasible to write raw SVG by hand. I do it almost every day.

To get the latest news on SVG, be sure to visit <http://www.svgcentral.com> as well as the Adobe site <http://www.adobe.com>. And bear in mind that the more people who adopt SVG as a web authoring medium, the likelier it is that Apple will produce an SVG Image Importer for QuickTime (along with other forms of support for SVG). The close relationship between SVG, PDF, and PostScript makes this a potentially important technology not only in the context of Quartz and OS X, but for web developers in general. As I like to say, Something Very Good is about to happen. What you've just seen here is only the beginning.

Kas Thomas <kt@svgcentral.com> is writing books on PDF and SVG and is the perpetrator of <http://www.acroforms.com> as well as <http://www.svgcentral.com>.

Note: The difference between a polyline and a polygon is that the polygon is automatically closed (and thus fillable).