What comes after XML?

SVG might be the application everyone's been waiting for

Summary
Are Powerpoint's days numbered? Author Uche Ogbuji introduces Scalable Vector Graphics (SVG) and demonstrates how to use Sun's new presentation toolkit for sharper slide presentations. (3,900 words)

ith the huge success of XML, a lot of speculation has arisen as to which XML-related technology was the real killer app waiting in the wings. As many experts will point out, XML is just syntax. Tim Bray, one of the fathers of XML, loves to note that XML is boring. The true magic of XML lies not in the basic syntax but in the many attendant standards that emerge as syntactical issues become effectively commoditized.

So what's the XML killer app? I'd say there have been four major contenders for that title, each of which has received a lot of hype: XSLT, RDF, XLink, and SVG. Scalable Vector Graphics (SVG) is probably the least known of those technologies, but it may be the one most likely to make a splash in the world beyond data geeks. SVG is a 2-D vector graphics format entirely encoded in XML. It's a candidate recommendation of the W3C, which means it's pretty close to final, or recommendation, status.

Some readers might be violently wagging their heads. In a previous Sunworld article, I gave an example of how bloated a sample purchase order became when converted from EDI to XML (over 10 times). XML formats tend to be more verbose. Why on earth would anyone use XML in such a typically byte-frugal area as graphical format?

It turns out that the W3C SVG Working Group (WG) has put a heroic effort into making SVG 100 percent XML, fully functional for vector graphics, and still compact. In fact, SVG representations of a given graphic are often only a modest increase over their equivalent in other vector formats and are typically much smaller than raster formats for images suited to vector display. Given its compactness and ease of processing, it might at first seem to be an apples-to-oranges comparison, but some have wondered whether SVG could or should supplant Java's Swing GUI.

Enough hype. Let me show you SVG so you can form your own opinion.

Introduction to SVG
SVG's feature set includes nested transformations, clipping paths, alpha masks, raster filter effects, template objects and extensibility (it's XML, right?). SVG also supports animation, zooming and panning views, a wide variety of graphic primitives, grouping, scripting, hyperlinks, structured metadata, a specialized Document Object Model (DOM), and easy embedding in other XML documents. SVG supersedes PGML and VML, two earlier XML-based vector formats that spawned the political battles that fueled SVG's development.

Listing 1 is a small SVG sample illustrating the use of several SVG features.

Listing 1

<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000802//EN" 
 "http://www.w3.org/TR/2000/CR-SVG-20000802/DTD/svg-20000802.dtd"
>
<svg width="10cm" height="10cm" viewBox="0 0 800 800">
  <desc>SVG Sample for Unix Insider Article</desc>

  <style type="text/css">
    .Lagos { fill: white; stroke: green; stroke-width: 30 }
    .ViaAppia { fill: none; stroke: black; stroke-width: 10 }
    .OrthoLogos { font-size: 32; font-family: helvetica }
  </style>

  <ellipse transform="translate(500 200)" rx="250" ry="100"
           style="fill: brown; stroke: yellow; stroke-width: 10"/>

  <polygon transform="translate(100 200) rotate(45)"
           class="Lagos"
           points="350,75 379,161 469,161 397,215 423,301 350,250 277,
                   301 303,215 231,161 321,161"/>

  <text class="OrthoLogos" x="400" y="400">TO KALON</text>

  <path class="ViaAppia" d="M500,600 C500,500 650,500 650,600
                            S800,700 800,600"/>
</svg>

Note that I put together the listing by hand (with help in some areas because I'm not a gold-medal geometrist). I've included generous amounts of white space to give the listing a friendlier look. In most cases, SVG will be generated either by artists using tools, such as Adobe Illustrator, or by software-generating automated images, such as maps from raw data. In either case, the resulting SVG will likely be condensed to save space and not be very readable. Of course, that is the beauty of the XML basis: if you do get one of those dense files, you can use just about any DOM library to read and print it. You can even edit the SVG source directly, using one of the many specialized XML editors.

The example includes the optional but highly encouraged XML declaration and uses the SVG Document Type Definition (DTD) given in the spec. Both can be eliminated for space, but remember that if you omit the document type, it can't be validated by the XML parser. Next comes the svg element: the mandatory root element. The height and width attributes are self-explanatory. The viewBox attribute means that after logical rendering according to the natural size of each object, the entire image will be stretched (or shrunk) to take up a particular size, in this case 800 by 800 pixels. Like most vector graphics systems, SVG supports a flexible set of coordinate systems and measurement units.

The desc provides a description or title for the image, and it is highly recommended by the spec.

The following element illustrates one of the huge advantages SVG reaps by building on the wide variety of Web and XML technologies. Many stylistic features of graphics objects can be customized using Cascading Style Sheets (CSS) and other stylistic systems. Building on that established technology facilitates learning, implementing, and using SVG, and improves its integration into current presentation systems. As usual for CSS, one can place style attributes directly on the target element, or one can define named global styles (with cascading features available for fine-grained control).

In this example, I define three named styles in the style element. Note the departure from XML to CSS syntax in the element's body. That presents an obstacle to SVG manipulation with XML tools. Using CSS is one of the trade-offs the SVG group had to make between XML format, compactness, and technology reuse. We shall soon see even more startling compromises between those goals.

Next, we have our first graphics primitive: an ellipse. The rx and ry attributes establish the ellipse's bounding box, and you can see a style defined for the ellipse: it will be drawn in yellow with a pen 10 pixels wide and then filled in with brown. Finally, the entire object has a transform applied, moving it 500 pixels right and 200 pixels down.

Then we define a polygon. The points attribute defines the points that connect the straight lines of each segment of the polygon. Here is another place where the CSS WG made the controversial but understandable decision to cram a lot of structured data into a single attribute, which is usually a poor practice. Breaking each point into a separate attribute wouldn't work because they must be in sequence, and XML attributes have no defined sequence. Using subelements would have meant tremendous bloat, both in SVG files and in the DOM representation created by SV manipulation tools.

The polygon, like the rest of the objects I create, uses a class attribute to adopt one of the named styles. The polygon uses a slightly more involved transform that moves and rotates it 45 degrees around the center of the entire image.

Then there's an example of text rendering. The text element again uses a named style specifying font face and point size. The x and y attributes indicate the origin of the bounding box of the rendered text.

Finally, there's a path, a free-form curve. That curve can be specified in multiple connected segments, each using a mix of techniques from straight lines to bezier curves. If you look very closely, you'll see that the right end of the path is clipped a bit by the overall image boundary (in the svg element).

Figure 1 is an example of that, using CSIRO's SVG viewer. I used CSIRO's Java-based viewer because it gave me the least trouble in Linux. I also tried IBM's SVGViewer from their Alphaworks project but found it buggy and lacking several SVG features. I wrestled with GNOME's CVS repository for a while, that being the only way to get Ralph Levien's SVG Viewer, Gill. Unfortunately, GNOME seems to have suffered a CVS meltdown for a few days: I couldn't get in through anonymous CVS or through any of its online repository tools (bonsai or LXR). That's too bad because I saw a demo of Gill last year, and it promised to be the fastest SVG viewer on Linux. Rendering my image changes using CSIRO was a trying experience: it usually took five seconds or so to render my very simple file on a PII 366. Windows users are luckier: Adobe's SVG viewer is quite fast and very complete.

Figure 1. Click on thumbnail to view full image (26 KB)

Your first presentation
Sun's SVG Slide Toolkit is a resource for authoring presentations. It allows users to write their presentations in a very simple XML-based format and generate a slick presentation, using SVG. SVG potentially gives presentations the same capabilities as Microsoft Powerpoint: style, images, animations, multimedia. Sun's toolkit provides basic functions as is, and uses the power of XSLT to allow the user to extend the presentation with all of SVG's abilities.

Listing 2 demonstrates the basic features of Sun's presentation source format.

Listing 2

<?xml version='1.0'?>
<!DOCTYPE slideshow SYSTEM "slides.dtd">
<slideshow> 

<title>Introduction to SVG</title>

<metadata>
  <speaker>Uche Ogbuji</speaker>
    <jobTitle>Principal Consultant</jobTitle>
  <organization>Fourthought Inc.</organization>
  <presentationDate>2000-09-25</presentationDate>
  <presentationLocation>Boulder, CO</presentationLocation>
  <occasion>Front Range XML Keiretsu</occasion>
</metadata>

<slideset> 

  <title>Background and Motivation</title>

    <slide id="I.1">
        <title>Why Yet Another Graphics Format?</title>

        <item>Leveraging the existing XML technology base</item>
        <item>Integrating graphics into the semantic Web</item>
        <speakerNote>Talk about RDF, XLink, XSLT, DOM, etc.</speakerNote>
        <item>Giving browsers access to image <emphasis>internals</emphasis></item>
        <item>Supporting the next generation of browsers</item>
    </slide>

</slideset> 

<slideset> 

    <title>The ABCs of SVG</title>

    <slide id="II.1">
        <title>SVG Features</title>

        <heading>Basic Features</heading>
        <bulletlist>
            <item>Coordinate spaces and transforms</item>
            <item>Graphics primitives: ellipses, polygons, polylines, curves, etc.</item>
            <item>Stylesheets: CSS, XSL, etc.</item>
        </bulletlist>

        <heading>Advanced Features</heading>
        <bulletlist>
            <item>Raster filter effects</item>
            <item>Alpha masking</item>
            <item>Animation</item>
            <item>Zooming and Panning</item>
            <item>Scripting and extensibility</item>
        </bulletlist>

    </slide>

    <slide id="II.2">
        <title>SVG Sample Source</title>

        <preformatted>
<![CDATA[
<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000802//EN" 
 "http://www.w3.org/TR/2000/CR-SVG-20000802/DTD/svg-20000802.dtd"
>
<svg width="400" height="600">
  <desc>SVG Sample for Presentation</desc>

  <style type="text/css">
    .Lagos { fill: white; stroke: green; stroke-width: 16 }
    .ViaAppia { fill: none; stroke: black; stroke-width: 8 }
    .OrthoLogos { font-size: 32; font-family: helvetica; fill:white }
  </style>

  <ellipse transform="translate(100 75)" rx="50" ry="100"
           style="fill: brown; stroke: yellow; stroke-width: 3"/>

  <polygon transform="translate(200 -250) rotate(45)"
           class="Lagos"
           points="350,75 379,161 469,161 397,215 423,301 350,250 277,
                   301 303,215 231,161 321,161"/>

  <text class="OrthoLogos" x="0" y="250">TO KALON</text>

  <path class="ViaAppia" d="M100,200 C100,100 250,100 250,200
                            S400,300 400,200"/>
</svg>
]]<
        </preformatted>

    </slide>

    <slide id="II.3">
        <title>SVG Sample Output</title>
        <graphic file="sample.svg" height="400" width="600"/>
    </slide>

</slideset> 

<slideset> 

  <title>The SVG Community</title>

    <slide id="III.1">
        <title>Some SVG Resources</title>

        <item><link href="http://www.w3.org/Graphics/SVG">The W3C's SVG Page</link></item>
        <item><link href="http://dmoz.org/Computers/Data_Formats/Graphics/Vector/SVG/">OpenDirectory SVG Links</link></item>
        <item><link href="http://www.sun.com/xml/developers/svg-slidetoolkit/">How to make slides like these</link></item>
    </slide>

    <slide id="III.2">
        <title>Quote Them on it</title>

        <para>"Over twenty organizations, including Sun Microsystems, Adobe, Apple, IBM, and Kodak, have been involved in defining SVG."<emphasis role="note"> -- Vincent J. Hardy, Sun</emphasis></para>

        <para>"I have been working with computer graphics for
over 25 years and spilt an immense amount of blood on the floor at
midnight. With SVG I can now do almost anything I want [except for 3-D, in
which I also have a molecular interest]. And I suspect that I can stick
with it for the foreseeable future." <emphasis role="note">-- Peter Murray-Rust, XML-DEV Founder</emphasis></para>
        <para>"I envision a day where we have XHTML Webpages with SVG as the chrome of our interfaces -- defining the buttons, the layers, the coloring, and the grid -- where we can actually use a language that's XML-based rather than these separate GIF files that can take so long to download. That's certainly one vision; that vision not just extending on the Web, on a monitor, but wireless onto my PalmPilot or to print and other output as well." <emphasis role="note">-- Steve Mulder, Razorfish</emphasis></para>

    </slide>

</slideset> 

</slideshow>

Note that a full doctype is specified, once again optional. The slides.dtd is provided by Sun to define the slide format it uses. Unfortunately, that is the only documentation users have to go by, so I illustrate the most important elements in my example above. Sun also provides a sample presentation source file.

The slideshow element represents the entire presentation, which is generated as a single (sometimes quite large) SVG file. It starts with an optional title for the entire presentation, and follows with an optional metadata element providing information about the speaker and occasion of the presentation. The core of the presentation is in one or more slideset children, each of which represents a subsection of the presentation.

Each slideset has its own title and set of slide elements, each of which is a single panel. Note that Sun's SVG presentations are designed to take up 1024 by 768 pixels. That can be changed, but only with significant effort. The slide element allows the user to specify the traditional bullet items, images, and links, with a range of style options available for highlights and formatting. Each slide has an ID that can be used as an internal reference in the presentation; I'll use it as a guide as we take a closer look at our example.

Slide I.1 shows the basics. It has a slide title and a series of plain items. It also has a speaker's note not rendered into the final SVG. The third item illustrates emphasis, which is rendered as a color change.

Slide II.1 demonstrates headings and places items within a bullet list, which renders each item with a leading graphic. There are also flat lists and numbered lists.

Slide II.2 renders SVG source code into the presentation. It's our earlier example, modified to fit into the generated presentation. As you can see, I've moved the graphics around, resized some things, and changed the text style to print in white so that it shows up against the default black background of the presentation. The source code is enclosed, naturally, in a CDATA section so it can be rendered verbatim. It is placed in a preformatted tag, supposedly to leave the formatting as is.

That supposedly points to one of the biggest problem areas in Sun's toolkit: poor support for block-level structures. Block-level structures are those that can encompass several physical display lines and are formatted accordingly. Many presentation elements, including preformatted, only make sense as block-level elements, and are indeed indicated as such in Sun's DTD. Yet the toolkit uses in-line styling to render such elements, so they're displayed in one long line.

A work-around for now, one that Sun uses in its own presentation example, is enclosing each line of the desired output in a separate formatting tag. So, for instance, each line in the SVG listing in slide II.2 would be enclosed in its own preformatted tag. However, that is not only tedious but antithetical to the most fundamental ideas behind XML and reusable style.

The right answer is to fix the stylesheet. Unfortunately, I found after some fiddling that the straightforward fix didn't seem to have the expected effect, and it might just be that Sun was dealing with problems in Adobe's SVG viewer (the recommended one, and the only one I found capable of handling the resulting presentations).

Slide II.3 renders the actual SVG image into the presentation. The graphic element establishes a specialized link that instructs the SVG viewer to display the graphic in-line. Other graphic formats such as PNG and JPEG can be used as well.

Slide III.1 shows some quotes in paragraph form. Attributions are highlighted with emphasis. Note the role attribute on the emphasis element. That is used to specify different types of emphasis. Sun's toolkit doesn't yet render different types of emphasis differently, and the valid role attributes in the given DTD are rather limited. That is probably an area Sun is still working on.

Also note that the contents of the paraelement suffer from the block-level element problem I mentioned earlier, and they are unfortunately rendered in a single line. In all three of the quotes, the line goes off the edge of the presentation area and, because Adobe's viewer lacks scroll bars, information is lost. The work-around (hacking the quotes into multiple paraelements) is too horrid to contemplate, and hopefully that bug will be addressed soon.

Figure 2 illustrates what the presentation looks like while on slide II.3, the one that incorporates the sample SVG image. Next I'll explain how I got from Listing 2 to Figure 2.

Figure 2. Click on thumbnail to view full image (36 KB)

Working the machinery
Now for the fun part: making this stuff happen on your computer. Several hoops and gotchas exist for now, so I'll try to walk you through it all. As SVG adoption spreads and the technology matures, I fully expect the process for SVG presentation (and the millions of other SVG application opportunities) to become much smoother.

First, get the software you need. Links for all downloads are given in the Resources section. Sun's SVG Slide Toolkit came as svgslidetool.zip. You need a fully compliant XSLT 1.0 processor to work the toolkit and, believe me, the SVG toolkit is a very thorough test of XSLT 1.0 compliance. Sun tested using XT and Saxon. I used 4Suite, which I codevelop (version 0.9.1 or greater is required). Finally, you need an SVG viewer to see the resulting presentation. Sun recommends Adobe's SVG viewer, which is fine except for one thing: it only runs on Windows. I tried IBM's SVGView, CSIRO's SVG toolkit, and Ralph Levien's Gill, none of which even came close to properly rendering the SVG Sun's toolkit emits. I don't suppose there's much chance of a Unix port from Adobe.

For now, install Adobe's SVG viewer on the Windows box on which you'll be viewing the presentation. Then install 4Suite (or other XSLT processor of choice) on the box you'll be using. Unzip svgslidetool. It has several files in the created SVGslides directory and more in SVGslides/images. It also has an all-but-useless README.html. Start with our example presentation.

Listing 2 has an image link, sample.svg. You can make this file by copying from Listing 3.

Listing 3

<?xml version="1.0"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000802//EN" "http://www.w3.org/TR/2000/CR-SVG-20000802/DTD/svg-20000802.dtd" > <svg width="400" height="600"> <desc>SVG Sample for Presentation</desc>

<style type="text/css"> .Lagos { fill: white; stroke: green; stroke-width: 16 } .ViaAppia { fill: none; stroke: black; stroke-width: 8 } .OrthoLogos { font-size: 32; font-family: helvetica; fill:white } </style>

<ellipse transform="translate(100 75)" rx="50" ry="100" style="fill: brown; stroke: yellow; stroke-width: 3"/>

<polygon transform="translate(200 -250) rotate(45)" class="Lagos" points="350,75 379,161 469,161 397,215 423,301 350,250 277, 301 303,215 231,161 321,161"/>

<text class="OrthoLogos" x="0" y="250">TO KALON</text>

<path class="ViaAppia" d="M100,200 C100,100 250,100 250,200 S400,300 400,200"/> </svg>

Copy Listing 2 to a file called listing2.xml. Then copy Listing 3 to sample.svg. You can place those two files right into the SVGslides directory, or you can copy SVGslides/slides.dtd, SVGslides/svgslides.xsl, SVGslides/svgslides_custom.xsl to the same directory as listing1.xml or whatever presentation you happen to be building.

Now use the XSLT processor to apply the toolkit:

[uogbuji@borgia SVGslides]$ 4xslt listing2.xml svgslides.xsl > test.svg

That runs the 4XSLT processor with listing2.xml as sources and svgslides.xsl as stylesheet. The output is redirected to test.svg, which has the entire presentation in SVG form.

To display that in Adobe's SVG viewer, copy the generated test.svg and slides.css into a directory on the Windows machine and use Netscape Navigator or Internet Explorer to browse the svg file. That should launch Adobe's viewer if it has been properly installed.

These are the files needed for building the presentation files:

• The source file
• SVG images referenced by the source file
• svgslides.xsl
• svgslides_custom.xsl
• slides.dtd (if your XSLT processor will try to validate)

These are the files needed for viewing the presentation files:

• The generated SVG presentation file
• slides.css
• Non-SVG images referenced by the source file

The above dependency lists are the main detail to remember when using Sun's toolkit. If you omit any while building the presentation, you'll get errors from your XSLT engine. If you omit any referenced SVG images, they will be silently ignored. If you omit any files while building the presentation, Adobe's SVG viewer will hang with a message in the status bar saying Retrieving Referenced Files...

Note that in the examples that come with Sun's SVG toolkit, all the referenced images are placed in an images directory. Be careful that the relative directory structure remains the same from building to viewing if you do things that way. I found it easier just to keep all the needed files in the same directory.

One final note: Sun touts its SVG slide toolkit as being customizable. I think that is an overstatement. True, you can tweak most presentation appearance and behavior facilities by modifying SVGslides/svgslides_custom.xsl, but that is such a complex beast that you might as well write your own stylesheet from scratch. Customization is one area where Sun might make a real difference in making the toolkit a Powerpoint killer.

Conclusion
SVG is a marvelous technology. It must be mentioned that its proponents (myself included) should be careful not to turn it into the overhyped technology of the week. Its main revolutionary claim is to take a well-trodden problem space (vector graphics) and craft a solution that works with the rest of the XML universe. That sounds simple, but many sharks lurk in those waters, and the SVG WG did a tremendous job.

Sun's SVG Slide Toolkit is a neat application of SVG's XML integration. It uses XML, SVG, XSLT, CSS, and XLink to turn very simple slide specifications into slick-looking slides that gain potential extensibility and power from SVG. Potential is the key word. The toolkit is a usable solution, but glitches and complex use and deployment mean that the user experience is much less friendly than the standard established by traditional presentation programs. That is not in itself a bad thing: the toolkit is definitely aimed at power users. But to make power users happy, it will have to make customization a straightforward task.

Because SVG viewers are still emerging, even the modest goal of providing sophisticated slides to Unix users isn't met because only Adobe's SVG viewer for Windows can handle the output.

However, Sun's toolkit is still useful for basic presentations and is a nice learning tool for SVG. It also packs a significant wow factor as a demonstration of XML. I definitely recommend you give it a try for your next presentation if you have an extra hour to experiment.