Practical Usage

By now your eyes may be crossed from trying to read the SVG for some of the simple pictures we’ve been using. As you can see, these documents can get complicated pretty fast. Those of you in the basic text editor camp may want to consider using a tool that gives you more support for dealing with SVG. The best is an SVG-aware editor that keeps you from making grammar mistakes. Some of the XML editors can do this if you supply them with a DTD. SVG is really just an intermediate representation for the visual image you’re working on. The next step up is one of the SVG-aware graphics tools we mentioned at the beginning of the chapter: Adobe Illustrator, Jasc WebDraw, CorelDRAW, or the open source Sodipodi. If you have to work on the XML file level, at a minimum you should be using the SVG DTD to validate the documents and the Batik pretty-printer to help you sort out what’s what.

SVG is still in its early days, so there are some compatibility problems. You’d do well to cross-check your SVG documents by rendering them in as many SVG engines as you can. The major ones to try are the Adobe SVG plugin (probably the most widespread), Batik’s Squiggle, and the SVG-enabled builds of Mozilla.

You should use the <defs> and <symbol> elements to produce libraries of SVG symbols you can use. You can stick these libraries in XML external entities so they can be shared among multiple documents. In the same vein, use the fact that SVG is leveraging CSS to separate styling information from the SVG elements. By attaching classes to the elements and then defining the styling for the classes in an external stylesheet, you give yourself more flexibility when you need to modify style aspects of your document.

If you’re working in Java, then it’s definitely worth the effort to learn to use SVGGraphics2D. It allows you to think drawing and shapes while still producing SVG as the output. This relieves you of the burden of SVG syntax and property names.

Dynamic SVG is one of the most interesting areas in SVG. You should try to get as far as you can with the built-in animation elements before you switch over to scripting. At some point, though, you’ll need to do some scripting, because that’s how event-handling is done. Again, modularity is important—find ways to place your scripts and animations in external libraries so they can be reused. You should try to do much of your scripting in ECMAScript, because that’s the only scripting language you can expect to have available in every SVG implementation.

Try to resist the urge to drop down into Java to manipulate the document. It won’t be portable, so your application will only work in Squiggle or a JSVGCanvas-based application. Not only that, but it’s a lot more work to drop down into Java, and ECMAScript is good enough for many of the DOM tree manipulations you might want to do. If your SVG application needs to connect with non-DOM Java functionality, then we encourage you to see if you can access that functionality from Jython.