Editor's Note -- Our aim with the O'Reilly Web DevCenter is to provide readers with balanced coverage of valuable Web technologies -- both open source and proprietary. More and more that line is blurring, such as with Adobe GoLive 6, a shrink-wrap application that incorporates open source tools such as Apache and PHP.
Recently we published an article, SWF Is Not Flash, that highlighted the virtues of Flash technology, a product of Macromedia. The XML community has responded with this thoughtful article about the strengths of SVG. We hope you enjoy, and we encourage you to participate in, this ongoing conversation about vector graphics.
Jacek Artymiak's article, SWF Is Not Flash, was an attempt to clear up some misconceptions about Flash and its file format, SWF. This article continues the discussion of formats for vector graphics on the Web, concentrating on SVG. I'll examine some of the questions people ask when deciding what graphics format to use, such as support in user agents, authoring tools, and integration with other standards.
Along the way, I'll expand on some points Jacek raised, taking the opportunity to explain aspects of SVG that may not have been clear. And just as Jacek admitted a bias to SWF, my involvement with the SVG Working Group will no doubt lead me to having a complementary position in favor of SVG.
Before we start, I want to take a higher-level look at the world of vector graphics on the Web. Over the past few years, there has been a demonstrated interest in vector graphics and animation on the Web. In 1999, the World Wide Web Consortium (W3C) started developing an open format called Scalable Vector Graphics (SVG). The SVG 1.0 Specification, which the W3C published in September 2001, offers the same graphics and animation functionality as Macromedia's SWF, as well as some additional features.
As an XML application, SVG 1.0 is more integrated with other Web technologies than SWF. The SVG 1.0 Recommendation has significant support from industry (Adobe, Apple, Canon, Corel, Hewlett-Packard, Macromedia, Microsoft, Kodak, Sun and many others contributed to the specification).
The SVG Working Group continues to promote SVG by developing new features at the request of the Web community, assisting developers through releasing test suites and developing profiles for mobile devices.
As SVG's popularity grows, you may face a choice between SVG and other formats, such as SWF. In the remainder of the article, I will go into more detail discussing some of the features of SVG as well as the current and projected state of authoring-tool and user-agent support.
I'm sometimes amazed at the level of positive feedback I see from developers starting to use SVG. Some of the reasons for this are described later, for example conformance and integration with other standards. And it's not just the developers that are impressed; industry players have also shown their support through participation in the creation of the standard, software development, and distributing SVG content. However, Jacek stated that SVG is still waiting to be generally accepted (as in being supported out of the box by all major browsers). I want to address this in three ways.
First, the SVG standard itself been accepted. The W3C membership voted to declare SVG a W3C Recommendation (the glowing testimonials from industry heavyweights are available, and the older ones are interesting reading as well).
To get this far it had to go through a complete implementation test (i.e., every feature in SVG had to be implemented in a viewer) and multiple calls for public feedback. When you have a collection of competitive companies creating a standard they agree on, making it open to everyone, and then racing each other to implement it in products, you have acceptance.
Second, people can and are viewing SVG content. There are a large number of different SVG viewer implementations. The most popular is the Adobe browser plug-in/ActiveX control. Adobe has released its viewer on all the versions of Windows that Microsoft supports (98, 2000, Millennium, and XP), Macintosh OS versions 8.5 to X, Linux, and Solaris. It runs in Internet Explorer, Netscape, Mozilla, Opera, and many other browsers.
As for other implementations, there is already a Mozilla project implementing SVG as part of the browser. As far as I know, this is the only popular vector format natively supported by a browser. Another very complete implementation is the Apache Batik project, which is open source. More information on the subject of viewer implementations can be found in Antoine Quint's article SVG: Where Are We Now?. Of course, that article is a Web year or two old by now. Things are constantly improving.
What about distribution? Adobe has publicly stated a distribution for the Adobe SVG viewer in excess of 150 million, and that is just one of the many SVG implementations around today. If you didn't already know, the Adobe SVG viewer is bundled with Adobe Acrobat Reader, and will be bundled with Real Player in the future.
Third, authoring tools are available. There are some great desktop tools for authoring and/or exporting SVG already available, including Adobe Illustrator, Jasc WebDraw, CorelDraw!, ILOG JViews; MayuraDraw -- the list of tools is growing. However, it is fair to say no one tool yet that matches the popularity of Macromedia Flash. Since this represents a huge opportunity for tools developers, and the standard is now well known, we're more likely to see a flood of SVG authoring tools from a variety of vendors. (As an aside, if Macromedia Flash exported SVG today, it could be one of the best SVG authoring tools in existence.
This is the area in which support for SVG needs to grow, but traditionally it is the area that takes the longest to grow. Also, don't forget that every text editor, such as Notepad, emacs or vi, is already an SVG authoring tool. You could also use the XML editor of your choice for editing SVG, ensuring your image is well-formed XML.
On the server side, the applications for generating SVG content are coming fast. Three examples are Adobe AlterCast, Apache Batik (free and open source), and Corel deepwhite.
What about the Web community? There is a growing SVG community out there. If you are looking for a well-informed forum for the discussion of SVG, I recommend the svg-developers list at Yahoo! Groups. There is also an SVG conference in July -- another sign of acceptance. The popularity of SVG is growing, and becomes stronger with every new implementation.
Jacek says that graphics need not be human readable. My take on this subject is quite simple -- being human readable is one of the best features of SVG. Why? Would today's Web be anywhere near as interesting if developers were not able to do a "View Source" on an HTML page and read the result?
Flash designer Joshua Davies of Praystation.com fame releases some of his source code and developers all over the world love it (the results are delivered as a non-human, readable binary format). Intentionally, every SVG graphic has its source visible and is human readable. Power to the developers through "View Source."
Not only does human readability have benefits for content creators and developers, it has enormous benefits to accessibility. Jacek asks: "Is staring at the SVG code going to make the message that the image is carrying easier to understand?" The answer is a resounding yes! The text within an SVG image is just that: text.
Anyone can read the text, where it is located, and how it will be rendered by simply looking at the source. An image described as four wheels, a body, some doors, and seats is probably a vehicle of some kind. Someone that has trouble seeing the image, for whatever reason, has a chance at finding the meaning by reading the source. Another example: user style sheets. Suppose users cannot view a graphic because they are color-blind. Since they can read the source, they can easily write a user style sheet to override the colors in the graphic.
By now everyone knows that XML can solve all the world's problems! Seriously, using XML to mark up graphics is just as much of a benefit as using it to mark up textual data. It's about semantics; a graphic, or the pieces within that graphic, can have as much semantic meaning as any other document.
Of course, marking the image up as a collection of graphical primitives (e.g. circle, line, rectangle) might not always add much, but it does add something. Structure with semantics helps accessibility, and as XML is the dominant structured format on the Web at the moment, you get a whole bunch of tools that can work with that structure for free.
Then, as SVG is XML, you have the option of easily adding much more semantic meaning. You can describe parts of the image using RDF, or any other XML metadata format. You can include XHTML descriptions for each part.
You can also add data in your own custom namespace to describe whatever you want, whether it's more metadata, details on how to return from the graphic to the original representation of the data, or data that can be used to transform one graphic into another. It's not "the end of the road" for the image, as Jacek put it. XML is good for graphics, because it helps ensure that rich content is not lost to the user. It's about not losing data to a proprietary black box; it's about information you can truly reuse and recycle.
So by using XML syntax, SVG graphics are always structured and can have more embedded semantics, which is a very good thing. And it's not just financial data, medical records, and the like that can benefit from the structure XML provides. Graphics such as maps, logos, user interfaces, animations and illustrations are all improved by structure and semantics.
With XML you also get integration -- now. You have the huge range of server-side XML tools to work with, as well as the fact that using XML for graphics fits into the current model of XML workflows. This way, you leverage all the other XML technologies and interoperate with them, including standards such as DOM and XSLT, and tools with XML libraries such as JSP, ASP, and PHP.
The power of this integration can be demonstrated with the simple example of a custom graphic such as a business card or post card. A developer can create an SVG template for the graphic and use server-side tools such as transformations to customize it to the end user's needs. Nearly every modern programming language has support for XML. If your data is in XML and your tool set works with XML, it makes sense that your graphical representation is XML.
Jacek said there is an advantage to having a uniform platform. SVG has one -- it's called the SVG specification. There are lots of SVG implementations, including viewers, editors, and server-side tools for content generation. All these implementations must conform to the specification, mostly because if they don't, developers will use an implementation that does conform.
Developers are tired of having to check an implementation's documentation to see how it diverges from the specification, and the SVG implementors have noticed this. Furthermore, we have a fully conformant SVG viewer in Apache Batik, which is available under an open-source license. Having such a freely available and complete open-source solution available helps the platform: it keeps the closed-source implementations honest, it gives them something to compare to (and even examine the source if their licensing terms allow), and it gives the developers ammunition for guaranteeing the uniform platform.
So I agree with Jacek, a uniform platform is a good thing to have, and I am glad we started with one in SVG.
Jacek calls SVG a bandwidth hog. I disagree, and for two reasons. Firstly, in many cases the declarative animation syntax used by SVG (e.g., move this shape from point A to point B, over 10 seconds, while fading from blue to red) is much more efficient than a frame-based approach (drawing multiple frames, each with the shape in a slightly different location with a slightly different color -- i.e., many static images shown one after the other).
This size advantage becomes more obvious the longer the animation. Of course, the size difference between the declarative and frame-based approach is also very dependent on the animation itself, but SVG animations make effective use of bandwidth. Again, I point to Antoine's excellent Sacré SVG! column for an example of an interactive SVG animation being smaller than the SWF equivalent, and that is for a very small animation.
Secondly, it is worth noting that the SVG Working Group specifically decided to use gzip compression as it does a fantastic job of compressing SVG files. We put our trust in compression experts! Every SVG viewer is required to support gzip-compressed SVG files. Not only that, gzip compression is included in many system libraries, meaning that it is not adding to implementation footprint. The size of SVG files was a major concern to the Working Group and we think we addressed it. I hope the misconception that SVG files are over-verbose does not stick.
About the time SVG became a W3C Recommendation, the Mobile Device community adopted SVG. Mobile industry companies such as Nokia, Ericsson, and Openwave joined the SVG Working Group. They needed a format for vector graphics on third-generation mobile phones. They wanted it to be an open, XML-based, modularized, profilable technology that would fit into their architectural plan, which included XHTML Basic, CSS, and SMIL. They chose SVG and you can see the results of the work in the Mobile SVG Profiles.
The mobile standards body 3GPP is defining the platform for the next generation of mobile phones in Europe and the U.S. They have chosen SVG Tiny as a required format for Multimedia Messaging (SVG Basic is recommended). I've already seen implementations of SVG on current generation U.S. mobile phones (even with a 75x25 black and white display), as well as Palm Pilots, PocketPC devices, other PDAs, electronic books, Japanese mobile phones (Sharp sells an SVG-capable phone in Japan), and in-car navigation systems.
I was once concerned that the completeness of SVG would lead to too much of a burden on implementors. I don't have that concern anymore, now that I've seen many interoperable implementations, from many vendors, on many devices. The recent modularization and profiling of SVG into SVG Basic and SVG Tiny can only help future implementors.
As this is a web development forum, I think it is important to outline how SVG fits into the overall architecture of the Web. Let's have a closer look:
XML syntax: I don't think there is a need to go over the benefits of being an XML document, although there are a few new points worth mentioning. As an XML syntax, SVG can be integrated with other XML documents, such as embedding SVG inline within an XHTML file, or combining SVG with MathML to create a graphical representation of a mathematical formula. Antoine's recent article shows how to extend SVG to support XForms, the replacement technology for HTML forms.
Web Services: SVG is the perfect fit for graphics in Web Services. This is about integration and interoperability with other XML technologies. Being XML, SVG diagrams or animations can be easily encapsulated in a SOAP message. Also, the interactivity and programmability of SVG means it can be used to build more complex graphical user interfaces to Web Services.
Stylability with CSS: SVG is stylable, using CSS in the same manner as HTML. You have style attributes, selectors such as "class", internal style sheets, referenced style sheets, and user style sheets. You may already know the mantra: separate structure/content from presentation. You also know the benefits to accessibility of this approach. This was built into SVG from the start.
Animation with SMIL: SVG uses the SMIL animation syntax. This is useful in a standalone SVG file, but also enables SVG documents to be embedded in a multimedia SMIL presentation, allowing the audio and video components to have overlaid vector graphic animations.
The DOM: Being XML, SVG has the complete XML DOM, including DOM Core and DOM Events. This means developers do not have to learn another programming interface to work with SVG, and they'll immediately find that the familiar DOM interfaces give complete control over the graphics within the SVG document. SVG also has its own extended DOM which provides a very complete graphical model for programmers, including convenience functions for common operations, such as matrix multiplication.
Everything else: Standards such as JPEG and PNG for raster images, transformation to and from SVG using XSLT, animation using SMIL, color management using ICC color profiles, and international text with Unicode. All built upon the well-proven and industry-accepted graphical principles used in Postscript, PDF, Java2D, and Mac OS X Quartz.
As you can see, SVG was designed to be an important component in the established and open Web architecture. Adopting open, truly standards-based solutions ensures that the pieces fit together in powerful, extensible, and economical ways. SVG, along with XHTML and CSS, will be part of the two-dimensional rendering engine of the Web.
SVG was not designed to replace any existing technology; it was designed to be the best solution for vector graphics on the Web. By producing SVG with regular public review, requirements for implementation experience of its features, and having the participation of organizations and companies leading the development of -- and sometimes competing with each other on -- graphics technologies, you could have bet on the positive outcome. I think SVG's time has already come.
SWF is an extremely popular, proprietary format that has been around for years, with an extremely popular authoring tool. SVG is a new, open XML format, generally acknowledged to be technically superior, which has not yet reached the same level of popularity. But with the enthusiasm shown by the people currently developing SVG content and the strong support from industry and Open Source developers, it shouldn't be long before SVG has the authoring tools and market share to be a dominant Web format.
Dean Jackson is a member of the SVG Working Group.
Return to the Web Development DevCenter.
Copyright © 2009 O'Reilly Media, Inc.