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.
|
Related Reading 
SVG Essentials |
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.
Historical Analogy
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 Switzerland
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?
SVG and the Web
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.
Desktop SVG
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.
Conclusion
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.
Do you agree with Prescod's forecast? Share your opinions on SVG in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Full Threads | Newest First |
- Svg can not be used as an interchange format
2003-07-19 12:26:47 Robin Debreuil [Reply]
"SVG is the neutral ground where multimedia format combatants can declare a truce and try to solve the interoperability problems that plague their customers. "
"SVG will also become the interchange syntax for all sorts of industry-specific or corporation-specific data visualization systems"
Svg makes a lousy interchange format for a number of reasons. First there are *many* things you can do in other formats that aren't supported by svg, how not. But more basically because it is a runtime format, not a storage format. Have you ever tried using it as an interm format between two+ graphics/multimedia formats? It really isn't practical for that type of thing, unless you are talking just simple vector data with solid fills. For that though, the world has no interoporability problems.
- Good points
2003-07-18 01:48:51 Daniel Zambonini [Reply]
I've recently spent a few days providing some SVG consultancy, and during those days SVG allowed us to produce accessible, extensible, accurate reports - which could also be easily embedded in PDF (through XSL-FO and Fop).
With regards to competition from Flash, and other vector based software (e.g. creating Graphs in Excel), we produced a 'business case' list of points for SVG, which may provide a useful appendix to this article:
Reduced cost. All the technologies used in the creation of SVG images (XML, XSLT, XSL-FO, SVG) are open, and available in free implementations, greatly reducing software license costs.
Open no lock-in. SVG is based on open industry standards; therefore there is no dependency on any particular creating/viewing/editing packages or proprietary software. Most industry leaders in this area (Macromedia, Adobe, etc.) support SVG within their software.
Flexible style. SVG provides unparalleled flexibility any reports/graphs can be generated in any style. Through the support for CSS, styles can also be quickly changed and updated.
Use any data. Reports can be generated from any XML input; not just restricting input data to particular software formats. Input (data) can therefore originate from spreadsheets, databases, office applications, (X)HTML tables, and any application or data that provides XML capabilities.
High quality. SVG images are scalable/vector based images retain quality at any scale (from billboard sized posters to leaflets).
Easily converted. SVG can be easily re-purposed for multiple outputs (e.g. PDF, HTML web pages, other graphic types such as JPG or PNG) due to its XML format.
Automation & further reduced cost. Automated report creation is simple. Using MS Office, or other reporting applications, human interaction is required to create the reports; therefore there is associated time/cost (human resources) each time data is changed or added. SVG reports can be automated each time data is changed or added a process can automatically create new reports, without the need for human intervention or an application open on the desktop.
Re-usable templates. Each SVG report template (an XSL file that creates SVG from input XML data) can be used to create reports for different kinds of input data, and can be easily shared and adapted.
Accessibility built-in. SVG has been designed with accessibility in mind; shapes and groups can be assigned titles and descriptions, which are available to text-readers.
Copy/Paste/Search enabled. Text within an SVG image can be copied, pasted and searched.
Animation. Shapes and objects within SVG images can be animated and synchronised, providing additional visualisation and presentation opportunities.
Scripting/Interactivity. Through industry standard ECMAscript, SVG can interact with mouse events (moving, clicking, sliding), key presses, and user form input, providing interactive reporting capabilities.
Thanks,
Dan
- SVG - Here to stay
2003-07-18 00:13:13 Amar Kumar [Reply]
Hi,
First of thanks for a nice article.
This is the first time I have read about SVG. From the article what I have got is that this standard is going to make things easier for everyone.
I guess that we would be seeing more of it in times to come.
- Missing the point
2003-07-17 08:32:42 Tony MacDonell [Reply]
The thing that really bothers me is the innate misunderstanding people have of the roles of these technologies.
SVG will never be able to achive some of the functionality that flash files contain because the reality of the situation is this:
"SVG is a transmission format for descriptions of vector information"
Flash however, is an entire platform in which you develop Rich Media Applications and Presentations
I have created hundreds of commercial projects with Flash for the web and for the desktop, and for the pocket PC, and for cell phones, and for playstation, so the point about going where Flash can't go is rubbish.
The thing that this article fails to point out is where SVG really will succeed. Being a standard transmission medium for vector graphics information from one application to another.
That is something Flash will never do, you are right there, but you are wrong in thinking that Flash is a competitor to SVG.
actionscript-toolbox.com posted source on Rendering SVG in the Flash Player. And it is likely that in the future the Flash Player will support it natively, because the Flash Player is the most widely adopted vector graphics renderer out there.
It makes me laugh when I think that in the next couple years, all of these SVG people that have been bitching at Flash, saying SVG is a Flash Killer, could suddenly find themselves using the Flash Player as their main display plug-in.
Flash will eat SVG. By that I do not mean that it will kill it. It will simply absorb SVG as another feature of the Flash Player. The two technologies will be complimentary.
And if this happens, it could potentially be the best things that ever happened to SVG.
If you can't beat em, join em.
- State the current situation not just the possible future...
2003-07-17 06:40:03 ethan estes [Reply]
I have a real problem with your views on reality of the ease of use of xml. First off I deal with a ton of IsoDraw files and have worked with web cgm. My experience with SVG is very similar-"Get back to me when it does more than create zoomable maps."
The technology is slow in the browser-Adobe's reader specifically. BTW: YOU STILL NEED TO DOWNLOAD A COMPANY's PLUG-IN TO VIEW SVG. You still need a graphics app of some sort to make them like illustrator (for anything complex and useful.) Corel has some software out but it is similar to isoDraw in that you have to buy their server etc. They are not cheap either. You need these apps to build things like Wiring diagrams-the real ones not the simplified versions floating around the web that are so easy to make.
Your markets are fragmented-multiple versions for different markets ie SVG Tiny. This technology is really only good for an audience who excepts all it's limitations and playback performance issues because the see the promise of it.
It does have promise but you need to be a little more honest on it's current state to the people in the trenches working with this stuff. I watch the format all the time and not once has it been a viable format to move intelligent graphic data around in our workflows.
And again you have a long way to go to get to the usability of flash files.
- SVG Icons
2003-07-17 05:00:04 Simon Proctor [Reply]
One point to mention, the newest versions of both the Gnome and KDE desktops can now display SVG icons. Which is nice.
- argument
2003-07-17 04:09:35 bryan rasmussen [Reply]
the chessgml example in your argument is of course predicated on using more technologies than just svg. a flash person, which I am not, could just as easily argue that they could build a chessgml consumer for flash.
when you say "They have left so many domains open for SVG because of the inherent limitations of proprietary (in the sense of corporate-controlled) binary formats" the only real indications of such domains I get from you is the domain of a common interchange format and the domain of desktop display; the usage of svg as the output of some process involving transformation/consumption of another format is not really a domain. If you have examples of other domains to offer I would appreciate it.
Also what Mike said about Adobe writing swf.
- Anyone can create Flash files
2003-07-16 20:49:57 Mike Chambers [Reply]
>Today Adobe software cannot natively write Flash code because Macromedia is a competitor.
???
Adobe makes a number of products that creates Flash files. Including LiveMotion and Illustrator.
In fact, there are quite a few tools that output, or read Flash files.
SWFtools
http://www.swftools.com/
lists over 130.
mike chambers
mesh@macromedia.com
