Picture Perfect
Last week, the World Wide Web Consortium issued Scalable Vector Graphics (SVG) 1.0 as a Recommendation. SVG, as its name implies, is an XML application for describing two-dimensional graphics in the form of vector-based objects. As well as allowing normal 2D drawings, SVG is scriptable, enabling user interaction, and it incorporates animation capabilities from SMIL.
Along with W3C XML Schema, SVG is one of the most important technologies to emerge from the W3C this year. It's certainly been long in the making -- SVG's first public Working Draft was published over two and a half years ago. Although many have been impatient for the final recommendation, this lengthy period of maturation has produced benefits in terms of the quality of SVG's specification and the number of supporting implementations.
It's No Banana
The text of the SVG Recommendation makes for an impressive read. It starts with a useful Concepts section that explains the key points and motivations behind SVG. The specification itself is beautifully formatted, comprehensively hyperlinked, and filled with examples. In addition, it is also very well indexed and useful as a reference, both for SVG processor implementers and those wishing to create SVG diagrams in XML.
Accompanying the recommendation is a test suite, allowing developers of SVG implementations to verify their code against the expected renderings of SVG documents. Although W3C XML Schema has recently gained a test suite after going to recommendation status, to have one available through the development of a specification and at publication of the recommendation is an excellent move. It has also enabled the W3C to publish implementation conformance information for the various available SVG renderers.
|
Related Reading XML in a Nutshell |
Another encouraging feature of SVG is that it has had significant implementation experience during its development, which appears to have been highly beneficial to the Working Group. This has resulted in a commercial vendor, Adobe, with software support for the specification already in its third public release cycle.
Breaking Out All Over
Setting aside the excellence of the specification itself, we must ask where SVG will succeed. After all, the best of technologies have been known to fail due to poor adoption.
On the Web, SVG's most immediate competitor is Flash, the only real established technology for vector-based illustration and animation. Microsoft's Internet Explorer has had support for its own predecessor to SVG, VML, for a while now, but this hasn't really achieved widespread deployment on web sites. It is clearly the W3C's hope that SVG will supplant Macromedia's Flash to a certain extent, bringing as it does the benefits of integration with the emerging XML infrastructure both in browsers and on the server side, and of course the open process of a W3C-fostered specification.
There are two obvious obstacles to this happening: browser support and authoring tools. Microsoft has just shipped IE6, which doesn't have SVG support (see Microsoft's Internet Explorer 6 and Standards). It will take at least a year before IE6 gets as strong a hold as IE5 currently does. So if even if IE6.5 or IE7 includes SVG, it looks like it will be a long time before SVG will be able to be taken for granted on PC browsers. The Mozilla browser is likely to have SVG support at some point in its development, but the prospects for Mozilla being a source of widespread SVG compatibility look worse than waiting for Internet Explorer, at least on Windows platforms. For now, SVG on the Web will have to rely on browser plugins. Adobe's plugin, while a wonderful development, weighs in at a hefty 3MB or so download. All told, the browser situation doesn't look that great.
Share your thoughts about the new SVG Recommendation in our forum. |
| Post your comments |
(If you don't think the battle on the Web is Flash against SVG, take another look. Despite Macromedia having a representative on the SVG Working Group, it has absolutely no reference to SVG on its web site, and it's just completed a deal with Microsoft to ship the Flash player as part of Windows XP. For its part, Adobe is partnering with RealNetworks to get its plugin distributed.)
Although there are some emerging authoring tools for SVG, there's quite a way to go to catch up with the place Flash has in the web designer's toolkit. The situation seems a bit healthier than for browsers though, as Adobe's offerings for SVG authoring get a head-start by piggy-backing on their existing web design and authoring tools.
However, I don't believe that SVG's initial victories will be on the traditional PC browser-based web. SVG presents too few advantages over existing technology to immediately supplant it. The scalability of the graphics buys little on the personal computer screen, where low resolution is the order of the day. If, however, you consider alternative devices, there is a whole spectrum of opportunity for SVG.
Also in <taglines/> |
The Web is increasingly no longer limited to the traditional PC. There's a significant emerging constituency of devices with limited display size: PDAs and cell phones. Few of these devices have similar specifications, and there's a need for display technology that allows the designer control, yet enables them to create an interface suited to the viewing device. SVG, especially with its integration with Cascading Style Sheets (CSS), is ideally suited to exist in this niche.
Indeed, the mobile and PDA use cases have been identified by the SVG Working Group, which proposed two profiles of SVG, Basic and Tiny, as part of SVG 1.1/2.0.
At the other end of the scale, we see the Web used increasingly for the distribution of technical documentation. Material, such as engineering drawings, needs to be reproduced to the highest fidelity, both on-screen and in print. SVG, which, unlike bitmaps, does not degrade at high resolution, is ideally suited to this application.
As display technology continues to improve, it is likely that quite a number of users will be staring at 200 to 300dpi monitors in a few years' time, creating new opportunities for graphics formats such as SVG that adapt well to different resolutions while keeping file size low.
So, although getting anything not blessed by Internet Explorer into widespread use seems difficult, the growing diversity in browsing devices provides opportunities for technologies like SVG to shine.
All Mixed Up
As readers of this site are no doubt aware, the simple fact that SVG is expressed as an XML application brings it strong benefits, and in turn enables other XML applications to enjoy its functionality. Like any well-dressed W3C technology, SVG has its own namespace. This means that, at least in theory and hopefully soon in practice, SVG can be inserted inline into XHTML documents (for a demonstration of this, check out the X-Smiles browser). XSL Formatting Object processors, such as Apache FOP, already support the use of SVG in order to provide graphic capabilties inside documents formatted for print.
The Working Groups developing SVG and SMIL (Synchronized Multimedia Integration Language) have both espoused subsetting as a way of developing their specifications. Recognizing that not all of the features of a technology may be needed or implementable in certain settings, future specifications will support well-defined subsets. This will, for instance, allow cellphone manufacturers to support exactly the same flavor of reduced-functionality SVG.
|
Related links: An Introduction to Scalable Vector Graphics |
And it needn't stop there. There's no reason that if you're developing an application that needs a way to express, say, rectangles, you shouldn't just bring in SVG. We now have an interoperable XML vocabulary for talking about figures in two dimensions.
Happy Ending
As an addition to the family of web technologies, SVG is a welcome arrival.It emerges at a time of new opportunity and challenge, as new devices and user communities proliferate. The W3C SVG Working Group has done a fantastic job with the development of the specification, and it's set high standards that other groups would do well to aim for.
Share your thoughts about the new SVG Recommendation in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Titles Only | Newest First |
- good developments; more commercial use needed
2001-09-19 14:00:21 Adam Clayton [Reply]
First let me get this out the door. I'm a Flash developer. I extremely like the product; and I'm in favor of open standards.
While continuing my work and visiting various Flash sites on the web since the Flash SDK was released last year, I have seen and read about SO MANY different companies and their resulting products that cater to different needs of the web developer. Charts, executable players that interact with the user system, chat progs, low-bandwidth video, XML apps, etc. Now I'm not making a call for everyone to pick up Flash and develop. But rather make a case how development tools MAKE more widespread adoption of a technology possible.
I have hope that SVG could turn into something useful. But trying to make SVG compete with Flash in the immediate run, you have a snowballs chance in hell. I say this because Flash's current scripting language is getting pretty advanced and out there, and can make Flash work with databases, XML, other languages, and things I can't quite explain. The advancement track is steadily increasing and there's an increasing army of designers willing to learn.
I commend Adobe for working on SVG exportable products, it is only for the benefit of developers. But Adobe, like Macromedia are companies that cater to the developer, esp to the graphic designer. We want the tools that will make our work easy, efficient, and fast to make. If you get some serious development tools for SMIL animation, I'd be curious and experiment.
Instead, working SVG into specific areas (??, Adobe with Real ventures) could give it an auxiliary position in its uses. Handheld devices, and other applications. That way many designers who do use Adobe Illustrator (or any SVG export prog) can export SVG for diff. purposes.
We may not know what the future will hold. But XML itself in addition to open-source will help developers from different areas make apps that can work together, despite differences.
And this is the outcome I'd like to see, not some Flash uber Alles. Interoperability is the main goal. A unified standard is a nice goal, but unfortuantely sometimes not a realistic one.
Adam Clayton
Los Angeles, CA
- Adobe comments
2001-09-13 10:20:19 Michael Bierman [Reply]
This is a very good article, but there are a few things worth mentioning.
"Adobe's plugin, while a wonderful development, weighs in at a hefty 3MB or so download. ..."
High bandwidth is becoming more and more common and so the size of a plug-in is becoming less of a concern. However, our 3.0 beta offers a significant size reduction. At just over 2Mb, it is almost 30% smaller than our 2.0 release.
"There are two obvious obstacles to this (SVG adoption) happening: browser support and authoring tools."
As for the necessity for Microsoft or Netscape to support SVG, I do not believe that it is essential for them to support SVG for it to take off. Adobe Acrobat Reader, RealNetworks' RealPlayer, Macromedia Flash, and Apple's QuickTime are examples of technologies that have done quite well without being native to any browser. I expect SVG to be no different in this regard.
Aside from the substantial distribution that we will garner from the Real distribution mentioned in the article, Adobe has been distributing Adobe SVG Viewer with our products for almost a year and a half. I know that we are already well over 35 million distributed.
There is a lot to be said for adoption, but a lot more to be said for consistency between platforms AND adoption. To have real success, all implementations (including the major browser vendors and tools vendors) must implement SVG consistently. If HTML and JavaScript are any indicator, the results may not always be positive for Developers. Adobe plans to continue supporting the new Recommendation as we have for the last few years. While we are not yet 100% compliant, we will continue to strive to meet the bar set by the Recommendation. (Boy it feels good to drop the words "Draft," "Candidate," or "Proposed"!). We will also continue our efforts to include the platforms that our customers demand as we have demonstrated most recently in adding Windows ME, XP, and MacOSX. (for a complete list, see our SVG Web site (http://www.adobe.com/svg)
We are currently evaluating other platforms and will add them when our resources permit. (Our resources are not, unfortunately infinite.)
As for authoring tools, Adobe has been shipping SVG authoring tools for over a year now. There are short SVG tutorials for Adobe Illustrator and Adobe GoLive at: http://www.adobe.com/svg/indepth/pdfs/illusag.pdf and http://www.adobe.com/svg/indepth/pdfs/goliveag.pdf
This will help people learn some of the many things our tools already provide in the way of SVG authoring. I think Adobe is already providing a very nice tools suite for the new SVG Specification. We are not alone in this regard. There are over a hundred authoring tools and servers that produce SVG already available.
With the help of substantial industry partners like IBM, Sun, HP, Canon, Corel, ILOG, JASC, BitFlash, (see http://www.w3.org/2001/09/svg1-testimonial.html) Adobe looks forward to SVG becoming as commonplace as HTML.
...............................
Michael Bierman
Senior Product Manager, SVG (Scalable Vector Graphics)
mbierman@adobe.com http://www.adobe.com/svg
Adobe Systems - everywhere you lookTM
- SVG is the future / No mention of BATIK?
2001-09-12 18:21:41 Max Dunn [Reply]
SVG may take some time to replace legacy proprietary formats like .swf, vml, etc., but it has *many* advantages and will ultimately prevail. See the detailed, objective comparison at http://www.carto.net/papers/svg/comparison_flash_svg.html
Funny, this article doesn't mention (or maybe I missed it) the Batik project? http://xml.apache.org/batik/
One of the great things with SVG was that the Batik and Adobe implementations were both solid and each implemented the majority of the spec. One got the feeling that the Adobe SVG team and the Batik team were working together to help each other conform to the spec: something unheard of back in the days of the browser wars, when Microsoft and Netscape would resort to proprietary extensions.
Hopefully companies such as Macromedia and Microsoft will learn from this effort and begin to truly support this robust XML standard.
Microsoft has done quite well with XSLT (finally) but their support of XML should not be so selective: SVG is a robust standard that represents the ideal standards-based replacement for VML. Hopefully it is a good sign that at least VML development has not been moving forward.
If Macromedia fails to support SVG they are making a huge mistake.
Over time standards will win out: XML is extremely powerful when used to describe vector graphics, and I believe the spread of SVG will be faster than you predict.
Max
http://www.svgfaq.com/
