SVG: A Sure Bet
July 16, 2003
This article is based on Paul Prescod's keynote address at SVG Open 2003
If you mention Scalable Vector Graphics language (SVG) in a crowd of web developers they will immediately gravitate to the question of whether it can "beat" Flash. Recently SVG Print has focused attention on the question of whether SVG can compete with PDF and Postscript. These are exciting possibilities: it would be great to unify these domains under a standardized, XML-based syntax. But it is ultimately quite limiting to define SVG by its success in replacing these existing technologies. SVG is much more than a Flash and PDF-killer.
The fact is that Flash, PDF, and other proprietary formats leave vast swathes of the vector graphics market untouched. They have left so many domains open for SVG because of the inherent limitations of proprietary (in the sense of corporate-controlled) binary formats. It is already clear that SVG will own those markets long before it gets close to replacing Flash and PDF in their core markets. In fact SVG is already a runaway success according to a much more important benchmark: it allows people to solve problems that were previously intractable.
The world of vector graphics is currently quite fragmented. There are a variety of competing APIs and vector graphic file formats, some proprietary, others domain-specific, and many both. If there had been a dominant one, the Web would have used it and SVG would never have been invented. This situation is analogous to the environment that existed before the rise of the Internet Protocol (IP). Before IP became ubiquitous, companies like Novell, Banyan, Apple, Microsoft and IBM had their own specialized protocols.
They all had various strengths and weaknesses, and they are all still used in some capacity today. But IP was so generic that it swept through like a weed, filling every gap left by the established protocols (e.g. long distance file transfer) and then gradually replacing them even in their strongholds (e.g. LAN print servers). Among its strengths, IP was designed to be the neutral zone between the variety of proprietary protocols. If you needed to share information across networks using proprietary protocols, it was much easier for both ends to implement an IP adapter than for each end-point to implement a dozen different protocol bridges.
Because IP was not owned by any particular company, each vendor could implement it without transferring control over its corporate direction to a competitor. The implications for vector graphics should be obvious.
SVG is a logical pivot point for people trying to tame the jungle of proprietary graphic formats and programs. SVG is the neutral ground where multimedia format combatants can declare a truce and try to solve the interoperability problems that plague their customers.
Today Adobe software cannot natively write Flash code because Macromedia is a competitor. And Corel is not likely to encourage people to use the Adobe illustrator file format. But SVG is a standard controlled primarily by the standards community. It is well documented, widely supported, easy to work with, and legally unencumbered. Many SVG importers, exporters, and converters are already available. Users increasingly expect every graphics manipulation or visualization program to support SVG import and export.
SVG will also become the interchange syntax for all sorts of industry-specific or corporation-specific data visualization systems, from maps of oil fields to architectural designs to molecular models. It will not replace the native XML data vocabularies for these things, but it will allow them to be rendered to a single display format so that disparate types of image can be integrated into unified graphical applications delivered through web browsers.
The trend toward this is already obvious. Do you want to view a chess transcript without installing a ChessGML viewer? You can do that with SVG. Do you want to visualize the output of a geospatial analysis program? You can do that with SVG. Do you want to visualize different aspects of the London underground? SVG. Want to generate graphics in C#, tweak them in Python and view them in Java's Swing? SVG.
SVG is the logical middle ground between all of these disparate domains. And, in fact, some newer domains are adopting SVG not just for interchange but as the core visualization or vector graphics standard. For example, SVG is becoming the standard way to deliver animations to phones and other small devices and the only vector syntax used for scalable desktop icons.
If you want to invent a whole new data visualization product category, building on SVG make sense. Why fiddle with licenses and SDKs from Macromedia or Adobe when you can download megabytes of high-quality open source SVG toolkits? Why develop a plugin for browser deployment when you can deploy to Adobe's viewer and get compatibility with most browsers on most operating systems for free?
As exciting as SVG is for these new applications, it will have major payoffs even for very traditional web pages. Today most web pages are composed in large part of vectors that are being delivered to the user as relatively bulky bitmap graphics. Consider the Google web page. It is famous for being sparse and fast to load. But even that page could be made faster with vector graphics.
The Google page consists of three pictures and an HTML document. With inline SVG, it could be a single XHTML/SVG document. This would download in a single network transaction instead of three. Client-side code could manipulate and transform the graphics and text together.
After you do the search, today's Google takes you to another page. The same images appear on the next page but they are at a different size. Because bitmaps scale poorly, they are delivered as two completely new graphics. Even though the bigger version is cached, the smaller version is downloaded from scratch. In the future, the image could be reused by reference and scaled to the right size, even if it had been included as inline markup in the Google main page. Google likes to add holiday greetings and localization to their images. SVG would allow this to be done using layers and overlays rather than entirely new graphics. Once again, this is cache efficient, which improves performance.
If SVG could improve the efficiency of Google this much, imagine what it could do for more complex, shape-based layouts like slate.com or cnn.com. SVG could noticeably improve the performance of the whole Web. But better performance is just the beginning. Things get really exciting when you consider the much richer Web that SVG enables.
Today Google can render a variety of formats into HTML. It can translate PDF and Microsoft PowerPoint into HTML. This is a good thing because HTML is more standard, more efficient, and more web-integrated than these proprietary formats. But the cost is high. HTML discards so much formatting information that sometimes the HTML rendition is useless. What if Google teamed up with one of the companies (MatterCast, BitFlas, SchemaSoft) that specialize in rendering proprietary formats into SVG? An SVG view of the Google cache would be a very compelling application and would further distance Google from its competitors.
Note again how SVG can win without fighting Flash or PDF. Vendors have disclosed no strategy to integrate Flash or PDF inline within HTML or XML markup seamlessly. These formats are constrained to plugins dependent on binary files and in fact a close reading of the Flash license would seem to preclude Google from even attempting the project without negotiation with Macromedia.
Notice the progression described above. First SVG becomes popular as an interchange syntax between domains and tools, and then as a native format for some domains and applications, and then as an integral part of the Web. What's beyond the Web? It is possible that one day SVG will take over the average user's entire desktop. Look around any computer screen. It is full of lines, arcs, and other vector graphic shapes.
Icons are vector graphics. As screen resolutions improve, yesterday's icons always look too small or too stretched on newer computers. But vector graphics scale up naturally. Some screen savers are animated vector graphics. Why not use standard SVG animations as screen savers?
But those are just the beginning. Virtually everything on your screen is rendered to the operating system graphics infrastructure as a series of vectors. Windows, buttons and menus are just collections of lines, curves and text. The problem is that every operating system GUI uses a different model for drawing these things. Windows uses something called GDI. OS X uses something called Quartz. Recent versions of X-Windows have XRender.
But maybe one day (several years in the future), SVG could be the native display layer of the operating system or even the hardware. Consider the virtues of using a single rendering model all the way from the human-editable markup down to the hardware, across monitors, and printers. Performance would be better. The various layers of rendering code would get simpler. Applications would use the same rendering API on all platforms.
This last point is probably reason enough for Microsoft to oppose it. For this reason and others, the idea of SVG as a native OS or hardware rendering API is the most speculative of my speculations. It would require much faster SVG implementations and a commitment to interoperability from operating system vendors. Both of these will take time to materialize.
But skepticism aside, there are some interesting rumors floating around. The Linux folks are certainly experimenting with SVG from the desktop all of the way down into the X-Windows windowing system. Apple used something very close to SVG for their recently released presentation software. Once again, this is further evidence that SVG has the potential to go places that Flash will not.
On the Macintosh something called Display PDF provides a vector display function, but it has not gained much traction in the Linux world and in fact has been losing traction on Unix for years. It seems wise of the Linux world to avoid putting its future in the hands of a single commercial vendor.
SVG is an open, patent-free specification understood by thousands of developers. It is natural that it will influence the design of lower levels of desktop operating system infrastructure. Perhaps one day it will become tightly integrated into the desktop or hardware itself.
SVG's openness and generality are key advantages quite distinct from its many technical virtues. Like the Internet Protocol, we should expect it to find its first successes in highly technical niches. But also like that protocol it will eventually become so ubiquitous as to be invisible. Like everything worth having this will take time and effort. But it will be a huge step forward for graphical computing in particular and standards-based computing in general.