Vector graphics, once the sole domain of desktop publishing types, is now becoming increasingly more popular with Web designers and developers. They use vectors to pack their graphics and animations into small chunks of data using the famous Macromedia Flash authoring application. Combined with a bit of sound and creative coding, the popular "Flash movies" or "SWFs" have become the most widely used format for delivery of rich media -- the new name for the good old multimedia, but delivered over the Web instead of being distributed on the CD-ROM, as was typical in the days of HyperCard and Director.
Over the years, the Macromedia Flash (SWF) File Format, as it is officially called by Macromedia, has become the de facto standard for vector graphics on the Web. It has its weaknesses, but it will be very difficult for other file formats to overturn it.
One such contender is SVG, the official standard for vector graphics developed by the W3C. It has many strengths, such as XML semantics, support from the important standard's body, and growing support from software developers, large and small. But for all the current interest in SVG, we're still waiting for tools that match the functionality offered by Macromedia Flash MX. Also, the SWF file format has been tested in the wide, wild world of the Internet, while SVG is still waiting to be generally accepted (as in being supported out of the box by all major browsers).
Many supporters of SVG like to criticize SWF, because they consider it to be closed, unreadable to humans, and unfit for the enterprise. That's why it's high time to present a different view that will help the readers who are evaluating both technologies decide which one best fits their needs.
The following discussion is not meant to prove that Flash is a superior technology to SVG, but to clear up some misconceptions about Flash and SWF. Of course, being the author of an open source FreeMovie library, I am biased. However, I'm also working on an open source SVG library with similar design goals as FreeMovie, and I try to see the merits of both SVG and Flash.
Flash is often confused SWF. This is a mistake because they're not the same thing. In the broadest sense, Flash is a complete solution: the authoring environment, the content delivery format, and the plug-in that plays the content back. SWF is only a small part of that solution; it's the file format in which content created with the Flash authoring tool is distributed.
While SWF is not an open standard like SVG, Macromedia does make it available to the public, and many commercial and open source tools exist for generating and parsing SWF files.
The SWF specification does allow third parties to extend the basic functionality of the format through the mechanism of custom SWF tags. Macromedia doesn't require third parties to register their extensions. Whether these extensions will be recognized by Macromedia's own player is a different thing, but there is nothing to stop an enterprising developer or a team of developers from writing their own Flash player and incorporating the extended functionality into their own player.
Of course, that may not actually be beneficial to the Flash community as a whole, because there is a danger of splitting the market. On the other hand, if the alternative player was significantly better than Macromedia's own product, users would switch and the market as a whole would not be affected.
As crazy as it sounds, extensions could be used to define an SVG storage SWF tag, which could store an alternative encoding of the same movie so it can be played in either a Flash Player or SVG Viewer. This area still remains to be ventured into by the open source community. Any takers?
What Macromedia does keep under wraps is the Flash FLA project file format, but that hasn't stopped the development of competing products like Adobe LiveMotion, which uses its own project file format. Sure, it would be a good move for Macromedia to make the FLA format open so the designers could move their project files from one authoring environment to another. But they can already export movies created in LiveMotion as SWF and import them into Flash MX. It's not the same thing, but it is useable.
We probably shouldn't count on Macromedia publishing the FLA specification anytime soon. It just doesn't seem to be in their best interest as a business, because it's one of the ways that Macromedia can use to protect their share of the Flash authoring tools market.
Whether it's "right" or not is another matter. No matter how we view it, Macromedia has every right to choose what it wants to give away and what to keep secret. Its decision to publish the SWF specs shows that the company is willing to share some of its knowledge with others. And this is a good thing.
True, raw SWF is just as comprehensible as an .EXE file. To understand it, we have to use an SWF parser. But is that a problem? Graphics or animation are very different from text encased in HTML, and being able to view the raw code of an image does not make it any easier to understand, no matter what file format is used.
For all the benefits that XML brings to the table, we have to ask if the ability to display and access the XML structure of some image is so desired by the people who look at that image? Is staring at the SVG or SWF code going to make the message that the image is carrying easier to understand? Did the Dutch masters want us to admire the texture of the canvas they used, or the people they portrayed? That just doesn't make sense.
Besides, there already are parsers for SWF, and it's relatively easy to write an SWF to SVG converter. A pre-release SWF parser module for FreeMovie is doing that already and will be released on SourceForge in a couple of weeks.
SWF is often accused of not having a structure. Well, that's not true. It doesn't have an XML structure like SVG does, but it is quite easy to convert SWF vector graphics into a structured XML document, if necessary. It's true that the design of the SWF brings memories of the old IFF multimedia format (still doing well in some applications), but it works quite well.
Sure, being an XML application, SVG is immediately familiar to an enterprise user who's implementing XML throughout his or her organization. Therefore, SVG can be easily integrated into the whole system. There are many tools for generating and parsing XML, and they can be applied to SVG. But what's it good for in case of vector graphics? Aren't we trying to shoot mosquitoes with ICBMs (Intercontinental Ballistic Missiles)?
XML is a godsend for documents that already have some sort of a primitive structure, like medical records, financial reports, encyclopedias, dictionaries, customer databases, and so on. Such documents, when structured according to the syntax rules of one DTD can then be easily transformed into other formats and syntaxes. And this particular feature is very important for the enterprise clients, because adding structure to data makes it easier to manage and reuse in the future.
It makes sense to use XML to store financial data, because it is then much easier to convert it into a visual representation, and SVG, being an XML application, fits the equation quite nicely. But so could any other format that we can write XSLT or DSSSL transformation rules for, because once numeric data is transformed into some business chart, that's the end of the road for it.
We can't process that data any further, unless we want to convert it into another graphics file format. There's no way to turn images back into the source numeric data. And if it's not possible, then SWF and SVG are just as good as any other vector graphics file format. All that one can do with an SWF or SVG image is convert it into another file format, or extract some parts of it, just like it can be done with TIFF, GIF, JPEG, IFF, and other "multimedia" file formats. XML gives SVG an edge, but it is not essential.
It's possible to create customized SWF files and you don't necessarily need to use a commercial application like ColdFusion MX or the late Generator. There's enough free code on the Internet to help developers create their own SWF generators similar to Adobe AlterCast. This is, after all, yet another variation on the Web page templates theme, albeit more complex. The formats have changed, but the principles remain the same.
You can easily turn data described using XML syntax, or any other semantics for that matter, into SWF files on the server-side. Simply use libswf, Ming, FreeMovie, or even the freely available SWF C++ SDK from Macromedia. Granted, it does take time to learn how to work with SWF, but the same can be said about learning SVG.
Macromedia controls the Flash Player, and it's been a problem for those users who, quite rightly, claim that it stops an even wider acceptance of the Flash technology, especially on mobile devices and free operating systems. I think Macromedia is in a difficult situation here and has to tread very carefully. On one hand, publishing the source code for the Player would earn the company a lot of good karma and free up a lot of its resources as the open source community could take over the tasks of porting and improving the Flash Player plug-in.
But on the other hand, that would make it possible for competitors to embrace and extend the functionality of the Flash Player and unnecessarily divide the market. If worst came to worst, we'd be required to download dozens of different Flash plug-ins. I doubt anyone wants that to happen.
So far, the Macromedia's decision to control the development of the Flash Player in-house helped it achieve full compatibility across all officially supported platforms. This is not a bad thing to have if you are a Web designer who has a client demanding cross-platform compatibility.
Macromedia could provide help for groups of developers interested in porting Flash Player to platforms other than those officially supported by Macromedia. Last time I checked Macromedia did offer access to the source code of Flash Player, but reserves the right to choose who can see it. Sounds fair to me. Those who don't pass the threshold can still develop their own version of Flash Player using the officially available SWF specification, just like anyone can develop their own HTML browser.
Regardless of our choice of poison, SWF or SVG, we have to wait for mobile devices to have more power to support either SWF or SVG (even in its Mobile incarnation). Meanwhile the ugly cHTML and i-Mode will rule.
The problems with using either Flash or SVG on mobile devices are not due to particular weaknesses of these technologies, but because nobody's figured out yet how to automatically downgrade applications, discarding fluff and keeping the essential components and functionality. There's still a lot of research to be done in that area.
SWF can carry more data encoded using the same number of bytes than SVG. Compared to SWF, SVG is a bandwidth hog. It doesn't matter that much on the workstations connected to fat pipes, but it does matter for dial-up users or people located on the other side of the globe. It is also very important for mobile Web applications.
Flash has become popular among Web designers because it is a complete solution: a well-designed authoring application, a robust file format, and a widely distributed player.
Macromedia wasn't the first to try to popularize vector graphics (one of the first attempts must have been their own Director, Broderbund's Fantavision, or Motion Works' ADDMotion), and they won't be the last, but the Web design community has chosen Flash and that's a fact. Even the best technology in the world won't become popular if people don't like it.
And there's a lot to like about Flash: one platform to develop for, no need to worry about the Web-safe color palette, all components can be bundled into a single file, good authoring tools, support for forms, an XML parser, and a powerful programming language.
With Flash, anyone can create interactive applications, catalogs, and animations and distribute them online. There is no need to learn DHTML or any other underlying technology. Flash simply lets creative people focus on the creative part of the job, without worrying about the technology that makes it all possible.
A consistent look; a high degree of control over document layout; and ease of mixing sound, animation, and still bitmap or vector images with code, all make Flash a very interesting tool for designers who are disillusioned with DHTML, which simply does not deliver the promised goods. Why should designers be focusing on inventing ways to work around the incompatibilities between various DHTML implementations?
One of the reasons for Flash’s popularity is the fact that it provides what other standards cannot provide: an easy way for the designers to control the final look of the documents they publish on the Web. It is, in a way, the PDF of the interactive multimedia. Both formats are so popular because, for the end user, the efforts that go into achieving the desired results are minimal.
SVG is in many ways superior to Flash, but it has not achieved the critical mass, yet, mainly because it still waits for an authoring application to match Flash MX. Flash on the other hand, has the marketshare SVG needs, but could benefit from many solutions found in SVG. It is inevitable that they will borrow the best ideas from each other at some time in the future. And it will be beneficial to everyone.
Today, the enterprise user has a choice of SVG or Flash and neither is a bad one. I'd say that it's a draw between the two and only the future can tell which one wins.
Jacek Artymiak started his adventure with computers in 1986 with Sinclair ZX Spectrum. He's been using various commercial and Open Source Unix systems since 1991. Today, Jacek runs devGuide.net, writes and teaches about Open Source software and security, and tries to make things happen.
Return to the Web Development DevCenter.
Copyright © 2009 O'Reilly Media, Inc.