SVG: Where Are We Now?

SVG's long gestation resulted in a specification that had some solid and diverse support from the moment it was released. This article aims at providing an overview of available SVG tools, including highlights of what's cooking in the short term in the SVG world. This article focuses on the most interesting, advanced, and tested active projects.

How can I view SVG Today?

Probably the first thing you'll want to know about SVG is how you or anyone else can view SVG contents. Today, there are two main kinds of SVG viewing tool: standalone SVG viewers and SVG-enabled browsers.

Viewers

The most advanced and widely-deployed SVG implementation today is the Adobe SVG Viewer. Adobe has put a lot of effort into SVG, ranging from co-writing the specification to providing SVG tools to the community from the early days. Currently in version 3, the plug-in is available on Windows and Macintosh platforms and works in all major browsers. The new version supports almost all of the SVG specification and includes advanced SVG DOM support, great scripting capabilities with the inclusion of an ECMAScript engine, and complete animation support.

Adobe also included a Real Player plug-in, allowing SVG content to be displayed alongside multimedia content, and it's worth noticing that RealONE's SMIL 2.0 support and Adobe's Viewer SVG support allow for some quite advanced compositions (e.g., semi-transparent SVG shapes over a video clip). This new version also comes with a Microsoft binary behavior enabling SVG inline content in Microsoft Internet Explorer version 5 and above. Performance-wise, it is comparable to the Macromedia Flash Player for animations and interactivity.

The other main standalone SVG viewer available is the Java-based and open source Batik project. Part of the Apache XML project, Batik 1.1 supports all static features of the SVG 1.0 specification and is committed to adding support for the dynamic features of SVG in the near future. Batik is actually more than a viewer: it really is a toolkit, providing an SVG-to-raster converter, server-side generation through DOM and APIs, a font converter, and a pretty printer. Because of those very features, it is very convenient to use Batik in a Java-based web publication framework. Batik is available on any Java platform and has been incorporated most noticeably in Apache FOP and ILOG JViews.

Browsers

Since SVG is XML, you might well be after a browser that will support SVG natively and inline with namespaces. If this is the case, then you are in luck, since three open source implementations are around. First off, Alex Fritze has been working on adding SVG support to Mozilla. This special build (not yet part of the Mozilla tree) is built on top of existing Mozilla XML, CSS, and DOM capabilities, and the project has been progressing at a rather fast pace. Today, the SVG-enabled Mozilla supports a good deal of the SVG specification, allows for a useful scripting facility, and is available for Windows, Macintosh, and Linux. Alex is working towards supporting a larger part of the specification -- hopefully this SVG support will be included in the Mozilla codebase by version 1.0.

W3C's Amaya offers an interesting subset implementation of SVG as part of its XML support (XHTML, MathML, RDF, and so on). While current SVG support may seem a little lightweight as is, Amaya is not just a browser, as its other main design goal is to provide an authoring tool that complies with and provides proof-of-concept for W3C standards. Using Amaya you can edit multi-XML-namespaced documents in a WYSIWYG manner. In fact, Amaya is the only tool out there that allows for SVG content generation as part of an XML document, WYSIWYG-style. Amaya is likely to extend their SVG support to full specification support shortly and then follow next-generation SVG advances.

Another effort to include native SVG support in a browser is the X-Smiles project. A Java open source project, X-Smiles started off as a glue between several XML standalone applications (CSIRO SVG Viewer, Apache FOP, Xerces, Xalan) and is gradually growing to include implementations of additional XML functionality (XForms and SMIL).

While right now a standalone application like the Adobe SVG Viewer is most advanced in both specification compliance and user penetration, there seems to be a logical trend towards integrating SVG where it truly belongs. Having SVG implemented deep down in an XML browser is the way forward to achieving one of the goals of XML: document interoperability.

How Can I Create SVG Today?

Now that you have an overview of how to view SVG documents, you might want to create some. There are two main ways to do so: hand-coding or using an SVG-enabled graphics package. Both have their advantages and disadvantages.

SVG-enabled editors

Hand-coding SVG is not as crazy as it sounds. The SVG specification is readable, especially if you are XML-aware. Obviously the filters chapter is a little difficult, but editing a simple SVG graphic with gradients, opacity effects, and the like is pretty straightforward. Hand-coding SVG has its advantages in that you can have a very neat control of your graphic's structure. While any text editor will do the trick for editing SVG, the popular XML-Spy 4.1 package offers excellent native support for SVG. Its syntax highlighting is very clear, elements and attributes completion is very handy, and XML-Spy also offers validation of SVG content against the SVG DTD (or a schema, when it becomes available). Another neat feature is that you can create SVG from any XML file with an XSLT transformation and display the result in browser view right in the editor. Popular editors like TextPad and vim offer SVG syntax highlighting. Adobe also offers SVG support in their GoLive product, which can be advantageous if you are already using this tool.

SVG-enabled graphics packages

One exciting feature of SVG is that it finally allows design artists to deliver rich graphics content on the Web (and in a language that also manages to suit programmers). As one cannot expect graphic designers to read through the SVG specification and start hacking around SVG by hand, most big names of the graphics industry are offering SVG support in their products, some even placing SVG at the very core.

Historically, Corel was probably the first large vendor to support SVG, offering an export plug-in to its Draw! program. They have since sustained these efforts, up to current version 10 which also supports partial import of SVG documents.

Jasc has also been following SVG developments closely. Its WebDraw product (formerly Trajectory Pro), now in Preview Release 5, has been built around SVG and uses it as its sole native format. WebDraw is close to the classic Illustrator-like vector graphics package, except it offers a three-view interface. The first is the WYSIWYG view where you can directly draw graphics objects with the drawing toolbar, change their properties, import raster images etc. This view does not yet support any way to add DOM scripting functionalities and has rather limited support for animation but robust support for static SVG features. The second view is a text-editor view, with nice syntax highlighting, where you can edit changes by hand if you wish. It is extremely useful when adding DOM scripting to your SVG graphics as well as animation elements. The third view is the browser view (usually using Adobe's SVG Viewer) where the content you have been editing in the first two views is rendered as a final document and where scripting and animations are applied. The true beauty of it is that all three views are synchronized at all times, allowing transparent editing and viewing in hand-coding and WYSIWYG modes. The 1.0 release of WebDraw should offer complete support for the SVG specification, including filters and animation. Preview releases have been available for free public testing on Jasc's site.

As with its viewer, Adobe is supporting SVG throughout its graphics product line. The first outcome of this commitment was the Illustrator 8 SVG export plug-in. Until now Illustrator has always been the major Adobe SVG-enabled tool, quite naturally since it was the best place to match SVG's static features. Illustrator 10 is a very advanced SVG tool. Illustrator supports SVG as a native format, seamlessly reading and writing SVG and SVGZ (gzipped SVG), symbols functionality saving to SVG <symbol> and <use> output, an interactivity panel to add event listeners and corresponding actions to objects, and most impressively the application of filters as native SVG filters. In fact, one can even import a custom filter from an external SVG file and apply it to an Illustrator document straight away. There is one drawback in Illustrator 10; it does not know anything about basic shapes: rectangles, circles, polygons are exported as SVG <path> elements, losing an interesting part of the semantics of an SVG document. Adobe also recently released version 2.0 of its InDesign product, a Quark XPress competitor, which seems to offer extensive SVG and XML capabilities both in import and export, probably worth checking out. We can also look forward to the birth of LiveMotion 2.0, Adobe's vector animation tool soon. The new version promises to offer support for SVG's dynamic features equivalent to Illustrator's support of static features.

It is also noting the existence of SVG export in popular software for the print (Quark XPress 5) and the 3D (Swift3D) industries.

While most of these products are Windows-only or Windows/MacOS-only, several SVG-related packages are available for Linux. Firstly, Amaya supports a subset of SVG in its WYSIWYG edition mode. In the vector graphics editing tool area, Sodipodi is an interesting project, using SVG as its native format. While Linux SVG-enabled products will no doubt increase in maturity over time, designers will have to concentrate on Windows and Mac these days for robust SVG use.

Conclusion

I hope this overview of SVG tools currently available gives you a good idea of what tool you need and what you can expect of SVG in today's products. I think the state of SVG's support in the industry is astonishing since its still in its early stages. It is also interesting to take into account the speed at which progress has been and is still being made. At this pace, this article will need a complete overhaul in six months.