SVG: A Sure Bet
by Paul PrescodJuly 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.
|
Related Reading 
|
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 | Titles Only | 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.
- Svg can not be used as an interchange format
2003-07-19 13:35:22 Paul Prescod [Reply]
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.
Please give an example.
- Svg can not be used as an interchange format
2003-07-19 20:30:25 Robin Debreuil [Reply]
??? Well, there is more than one format in the world because each one does unique things suited to its particular task. So look at the specialty of any format, and you will find many things.
Anyway, here are some examples - note: svg can do, or be made to do, some of these at run time. That doesn't make it suited to being an interchange format - for that it has to store these concepts, and in fact differing interpretations of these concepts, in a standard accessible way. By standard I mean consistent, not W3C...
For two things I thought it should support, swapping depths of displayed symbols, and solid fill defs (they can't be defined as tags, yet gradients must be). For things that are beyond the scope of it (which are all hard interop areas): contours, vector distortions, shape blends (leaving a copy), extrusions (there are many ways these are done), variable width strokes, unusual warp fills, envelopes, different plugin formats... Basically pick a graphics/anim/xx program and go through the menus, you can find lots.
Really for interchange you can go the 'meta format' route, where you make a superset of the technologies you are going to support, and/or just go the compiler route.
And before you say - I know you can add your own custom tags to svg. You can add custom tags, or custom code to every graphics/anim format I can think of. That doesn't make them all suitable for an interchange format...
PS: This is OT here, but I read your (very interesting) article on soap, linked off your personal website:
http://mail.python.org/pipermail/xml-sig/2002-February/007183.html
..and I couldn't help drawing parallels to my thinking on svg. I guess you don't agree? I think svg would do well to come up with a one sentence definition of what it is for, and try to be great at that. "The PNG of vector graphics" would have been a great one, but it is too late for something that simple I'm afraid.
Cheers,
Robin
- Svg can not be used as an interchange format
2003-07-20 11:41:26 Paul Prescod [Reply]
Of course any interchange format is going to lose some details of the native formats. It is quite rare to find one that does not. And yet we still make heavy use of them. When you cut and paste from one application to another you usually go through RTF or ASCII text which loses things. But people still cut and paste. If you want to integrate graphics from GIS software with graphics from a charting package, SVG will preserve everything that you could reasonably expect it to preserve. As the article said:
"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."
But I will defer to the experts: "SVG has emerged as the new high fidelity vector graphic standard for the Web. Dozens of applications have developed or announced their intent to support the SVG format. This made SVG a natural candidate as the Visio team evaluated alternatives for exchange of Vector graphics with other applications going forward."
And:
"Over many releases, the Visio team had built or acquired import and export 'filters' for a large array of foreign graphic formats. Many of these were proprietary formats of competing products. In Visio 2002 release, the number of formats supported for import, export or both had reached 27 formats, 12 of which were proprietary formats of other products --- some of which had already announced they would be supporting SVG. The Visio team decided to deprecate support for a number of older formats and to add a single new format that would be supported by a wide array of other products --- SVG."
Richard See,
Lead Program Manager ? Advanced Technology Teams,
Microsoft Office Visio, Microsoft Corp.
http://www.svgopen.org/2003/papers/SVG_Scenarios_using_Microsoft_Office_Visio_2003/#S2.2
You asked whether I see some of the same issues with SVG that I do with SOAP. I think that SVG could and should be modularized more. The Tiny and Basic profiles are a good start but just a start. Yes, I think that the SVG community has to wrestle more with issues of profiling, subsetting, customization and interoperability, but I have a lot more faith in their common understanding of their problem domain than I do for SOAP.
- Svg can not be used as an interchange format
2003-07-20 14:03:56 Robin Debreuil [Reply]
Hey Paul,
>> Of course any interchange format is going to lose some details of the native formats.
It will lose whatever the spec allows it to lose, which is often zero, but at least not an arbitrary amount like 'what is supported by a third format'.
>> When you cut and paste from one application to another you usually go through RTF or ASCII text which loses things. But people still cut and paste.
Cutting unicode text as ascii would result in loss that would never be acceptable. All modern OS's can handle this, and most older ones will too. If your container only supports ascii, then it will have to be converted down, but you would never store it on the clipboard as ascii alone. That is why the clipboard can store data in multiple formats, and auto convert as well. Svg is generic like ascii, not all encompassing like unicode. That is a good analogy of why it can't be used as an interchange format for anything but simple cases where you don't mind loss.
That would be fine, except it is a runtime format. So your data is stored across tags, entities, css, javascript, it might have to be transformed by xslt or script before being viewable, you might have to load bitmaps externally, your data might change half way through, and now rcc etc etc. This makes simple conversions like unicode>ascii pretty much impossible, because your data isn't stored in a consistent manner. That is the big reason it makes a lousy interchange format.
>> Visio, the wonders, limitations are features, etc etc
The visio quote has nothing to do with interchange - they are dropping support for formats, not making them easier to use. They are adding one. So if you had an older deprecated format, you now have to convert it to one of the supported ones - svg or one of the remaining formats. Is that what you meant by "solve the interoperability problems" - have a polite way of not supporting interoperability anymore?
>> You asked whether I see some of the same issues with SVG that I do with SOAP. I think that SVG could and should be modularized more. The Tiny and Basic profiles are a good start but just a start. Yes, I think that the SVG community has to wrestle more with issues of profiling, subsetting, customization and interoperability, but I have a lot more faith in their common understanding of their problem domain than I do for SOAP.
Ok, fair enough. Could you define the problem domain of SVG for me though, or point me somewhere that can? Maybe I would have a clearer view of why it is structured like it is if I knew the problem it was trying to solve. Right now I have a lot of 'fish or fowl' moments when trying to incorporate it into programs, or even my workflow...
Cheers,
Robin
- Svg can not be used as an interchange format
2003-07-20 22:08:00 Paul Prescod [Reply]
> Paul > Of course any interchange format is going to lose some details of the native formats.
> Robin > It will lose whatever the spec allows it to lose, which is often zero, but at least not an arbitrary amount like 'what is supported by a third format'.
I'm having trouble understanding you. Whenever you have Model A and Model C and interchange through Model B you lose anything that A and C support that is not supported by B. But the alternative is to build A-Z * A-Z translators which is to say 676 translators. This never happens. Just to keep some sanity in the system you must necessarily choose some hub formats. The only question is whether the hub formats are open standards or not, and whether they are well-designed for the purpose or not.
As an example, I did a Google search for "graphing software". I found OriginPro. What does it output GIF? Until recently that was patent encumbered and certainly not scalable. Now look at this long list of output formats supported by GraphViz:
http://www.research.att.com/~erg/graphviz/info/output.html
Which scalable vector format should I use for import into Keynote for the Mac? I'd like to believe that by 2005 there would be an obvious answer to that question but right now I don't think that there is. (amazingly, I had trouble with bitmaps and PowerPoint just last week!)
Now look at OpenOffice Draw. What does it output? A bunch of bitmap formats and WMF. Oops. Most Mac programs (like Keynote) do not support WMF.
Now I want to put the corporate logo into my presentation (or Visio file). What is the marketing department going to email me? Likely either a bitmap or an Illustrator file that is useless on my computer.
> Cutting unicode text as ascii would result in loss
> that would never be acceptable.
That's just not true. Some tools only claim to support ASCII and if their user base is happy with that they get what they pay for. The application needs to indicate that it is losing characters and let the user choose another strategy if that is a problem. But more to the point, there are applications where Unicode is a lossy interchange format. That doesn't mean that Unicode is a LOUSY interchange format just that it is not in and of itself sufficient for all purposes. Where it is not good enough you augment it or use something else altogether.
> All modern OS's can handle this, and most older ones will > too. If your container only supports ascii, then it will have > to be converted down, but you would never store it on
> the clipboard as ascii alone. That is why the clipboard
> can store data in multiple formats, and auto convert as
> well.
Great. So if you are cutting from Illustrator to Word would it not make sense that the clipboard formats would be Illustrator (for perfect fidelity), SVG (to at least get scalability) and PNG (to at least get graphics)?
> Svg is generic like ascii, not all encompassing like
> unicode.
I don't see how "generic" and "all encompassing" are opposites. Furthermore, I don't see ASCII and Unicode as being opposites but rather living on different points on a spectrum. Some hate Unicode because it is too lossy. Others feel that in trying not to lose much it became too complicated (i.e. not lossy enough). Most people just figure they should use it when it fits and use something else when it doesn't.
> That is a good analogy of why it can't be used as an
> interchange format for anything but simple cases where
> you don't mind loss.
I don't see how "simple cases" have anything to do with it. You either can afford to lose what you lose by going through the interchange format (whether it is SVG, Unicode, PNG or ASCII) or you cannot. If you can, you use it and benefit from the fact that you have a way to get your data from point A to point C. If you do not, you had better hope that your point A and point C speak the same language.
> That would be fine, except it is a runtime format. So your
> data is stored across tags, entities, css, javascript, it
> might have to be transformed by xslt or script before
> being viewable, you might have to load bitmaps
> externally, your data might change half way through,
> and now rcc etc etc.
You've conflated a bunch of issues. "Storing data across tags" is never a problem. The other features could be a problem if your exporting program uses them when they are not appropriate. For a simple graphic, Illustrator is not likely to put in a bunch of script. IIRC, the Visio guys said that they worked hard not to use script and used only a tiny bit for doing multi-ended links. So you would lose multi-ended links if you import Visio SVG into something that doesn't suport script. This is a concrete deficiency that can be solved by appropriate standardization (i.e. XLink). By the way, SVG that depends upon XSLT is not SVG.
This makes simple conversions like unicode>ascii pretty much impossible, because your data isn't stored in a consistent manner. That is the big reason it makes a lousy interchange format.
If you think that Unicode doesn't have similar issues you should look into "combining characters". Even XML itself has similar issues. The usual solution is to define normalization forms (as both Unicode and XML have). This is likely to happen in the SVG world when interoperability problems arise. After all, SVG-Tiny, SVG-Basic and SVG-Print are all profiles defined for certain kinds of interoperability.
At this point it is probably more productive for us to wait and see. The Visio group has committed to using SVG for interoperability. The OpenOffice group has also. I think we will see that "in the small" we will see greater interchange capabilities between these programs thanks to this agreement. I also think that in the large we will see this effect multiplied across most applications, especially if Microsoft can be convinced to come on board. I guess you disagree and I'm going to have to agree to disagree.
> Ok, fair enough. Could you define the problem domain of > SVG for me though, or point me somewhere that can?
SVG is destined to be a Web format for vector graphics and a platform for Web-based graphical applications. But deploying standards on the Web takes a long time. In the meantime, subsets or variants of it will be used in a variety of domains like interchange between graphical apps, MMS messaging on cell phones, Intranet-applications, page layout and smart graphics applications. These variants were not the focus of the specification and are thus not all as clearly defined as the full specification (though some of them are).
SVG would have been defined differently if interchange was the only goal but there is a vacuum to be filled there and industry leaders like Microsoft (through Visio), Adobe (through various SVG exports) and Sun (through OpenOffice) are going to try to fill it through SVG. I think that they will find SVG is not a perfectly suited standard (what standard is perfect!) but that it will still be substantially better than the vacuum (very similar to the situations with IP and XML, too other "better than the vacuum" standards). I expect that one or more "interchange" subsets will be defined either implicitly (as they are today) or explicitly (as has been happening more recently) over the next couple of years.
- Svg can not be used as an interchange format
- Svg can not be used as an interchange format
- Svg can not be used as an interchange format
- Svg can not be used as an interchange format
- Svg can not be used as an interchange format
- 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.
- Missing the point
2003-07-17 18:03:57 Paul Prescod [Reply]
Tony says: "Flash however, is an entire platform in which you develop Rich Media Applications and Presentations"
Well, my presentation is available in SVG here:
http://www.blastradius.com/svgopen2003/
And SVG can embed animations, sound and video. That sounds like Rich Media Applications. So SVG can do Rich Media Applications and Presentations. You might want to look into SMIL.
Tony says: "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."
The article says: "Many SVG importers, exporters, and converters are already available. Users increasingly expect every graphics manipulation or visualization program to support SVG import and export." It also says: "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."
Tony says: "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"
Is Flash going to be integrated into Linux desktops? Is Flash going to be a part of the 3GPP standards? Is there a project to integrate SVG into X-Windows.
Tony says: "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."
Tony: "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."
If Macromedia produced a standards-based media platform I would be overjoyed. I don't care if it is called the 'Flash Player' as long as it consumes a subset of SVG, SMIL and Javascript comparable in size to the competitive SVG implementations. If you want to treat that as "Flash wins" that's fine. In my opinion, that would be everybody winning.
But to be just a little childish: what could more vividely prove my point than Macromedia adopting Flash? Standards can go places that proprietary languages cannot. Macromedia can support SVG and be on an equal ground with everyone else. Adobe cannot create a Flash viewer and be on equal ground with Macromedia. Thus, one of those scenarios is feasible and the other is not. That's why SVG will "win" in the sense of being much more ubiquitous than Flash.
- Missing the point
2003-07-19 18:21:48 x emplify [Reply]
Paul wrote: "Well, my presentation is available in SVG here:
http://www.blastradius.com/svgopen2003/
"
Unfortunately I could not view this using either the Corel viewer in Mozilla 1.4 in Windows XP or using the Java open-source Batik Squiggle SVG viewer.
I found the following errors:
1) At line 14973: equality (==) mistyped as assignment (=)
My fix, change from:
while (gpage = doc.getElementById("Page_"+p)) {
to:
while (gpage == doc.getElementById("Page_"+p)) {
2) At line 5370, col 167: incomplete path element, and path element not allowed within tspan element
My fix, change from:
<path d="M180.343,153.481c0,27
to:
<!--<path d="M180.343,153.481c0,27-->
At this point the file would still not work in the the viewers due to more scripting related problems.
When I came across SVG three years ago, I too was very excited by the possiblities that it offered. I applaud Paul's efforts to promote SVG. However my inability to view this file highlights one of the problems SVG faces: generators and viewers that do not follow the SVG specification.
It seems that the SVG generator Paul used to produce his presentation produced non well-formed XML, invalid SVG and erroneous EcmaScript. Presumably some SVG viewer allows the file to be viewed dispite the mistakes, leading to the false belief that it is conformant SVG.
It is up to SVG developers to demand that implementors respect the SVG specfication, otherwise all the promise of interoperability is for nothing. In the mean time those producing SVG for the web should check their files for cross viewer compatibility.
- Missing the point
2003-07-22 17:42:14 Paul Prescod [Reply]
1) At line 14973: equality (==) mistyped as assignment (=)
Actually this is legal ECMAscript.
At line 5370, col 167: incomplete path element
There is no path element there. There is some literal character data using the ampersand greater-than character but no XML parser should treat that as an element and no SVG viewer should either. Whichever viewer you were using that does this is making a mistake.
For now, the Adobe implementation is quite a bit ahead of the others in implementing advanced features of the spec.
- Missing the point
2003-07-22 20:13:15 x emplify [Reply]
Apologies for the mistakes in my analysis. In the Mozilla browser status bar, the Corel Viewer suggested that the = instead of == maybe a mistake. Doing view SVG source from the Corel Viewer in Mozilla gave me the XML with the <path replaced by the
Still, there is a null pointer exception in the Batik Squiggle viewer that is preventing the file from being viewed. Not sure if this is a spec violation on the part of the file, or a lack of something implemented in Batik.
Regardless I would still suggest that SVG developers use a subset of the SVG specification that can be viewed in all major SVG viewers. I would also like generation tools that have an option to produce cross-viewer compatible SVG.
For over a year I have been using Mozilla because it beats IE on features hands down. Also using Mozilla means I can use the same browser on both Windows at work and my Linux desktop at home. Until I can view the majority of SVG files on the Web in the latest release of Mozilla, SVG is a dead Web format for me. I would imagine that there are many Linux users that feel the same way.
I hope that the newly formed Mozilla Foundation places more emphasis on the development of native support for SVG in the near future.
- Missing the point
2003-07-28 20:48:59 Stuart Begg [Reply]
FYI: I am able to view the referenced SVG presentations using Mozilla 1.4 on Mac OS X 10.2.6, with the Adobe SVG Plug-in (v3.0). I have not tried any of the other plug-ins you mention.
- Missing the point
- Missing the point
- Missing the point
2003-07-20 12:49:49 Paul Prescod [Reply]
Thanks for the report. I've forwarded it to the makers of the software. SVG developers should definately test with at least Adobe SVG and Batik.
- Missing the point
- Missing the point
- Missing the point
- 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.
- State the current situation not just the possible future...
2003-07-21 11:46:57 Rob Williamson [Reply]
Two points to add to this long string....
Point 1: Clarifying an Small Misconception
I just need to clarify something regarding building SVG applications using the Corel Smart Graphics Studio. You do not, in fact, need a Corel Server to deploy a data driven SVG application. We have a component called, "Process Builder" that allows developers to visually build run-time connections with data and logic without having to write ASP or JSP code (or actionscript for that matter). If you want to build these processes quickly and deploy them on a server that includes some added functions (like image serving, or CGM-SVG conversion) then you need a server.
However, the output of the product is open standard XSLT, SVG, and ECMA that you are free to deploy on the application server of your choice to the viewer of your choice. Our environment does not use any custom extenstions not usable by other viewers or authoring tools.
Again, this speaks to the value of SVG and the underlaying technologies....choice! As long as you are careful to not use proprietary extenstions then you are able to view it and use it in any tool in the 'content' delivery workflow.
Point 2: An observation on this thread
The real opportunity that Corel is seeing is not in making SVG as the be all and end all of XML and W3C browser technology that will replace the desktop as we know it. While this would be fantastic, if the entire SVG community budgets were all added up probably wouldn't be 1/10th of the R&D budget of Microsoft so extending the technology in this direction seems a little aggressive in this early phase of the technology. Exciting, to be sure....but aggressive.
However, what SVG is today is a powerful and low cost enterprise tool for accessing XML data being exposed through Web Services (or ODBC, or HTTP, etc). All enterprises want is:
1) an assurance that it solves their needs - which are rarely all that complex
2) that it will interoperate with other vendors seamlessly - without proprietary extenstions or compiled code
That's it....very simple. That is why I am so pleased with the potential of the vendors in this community and the sense of sharing that came out of the SVG open. Now we just need to make sure we don't fall prematurely into any pitfalls resulting in 'proprietarizing' SVG during *any* step in the content flow, from server side databases to client-side interfaces.
- State the current situation not just the possible future...
2003-07-17 18:11:03 Paul Prescod [Reply]
Ethan says: "Get back to me when it does more than create zoomable maps"
SVG already does animation, video, rendering of arbitrary XML, restyling and is fully scriptable and programmable. It is not even close to CGM.
Ethan says: "YOU STILL NEED TO DOWNLOAD A COMPANY's PLUG-IN TO VIEW SVG."
This is true, for now, if you do not already have the SVG viewer (which you will probably get as a side effect of downloading Acrobat once ASV6 ships). But SVG is being directly implemented in at least one browser: Mozilla. I can't predict if or when Microsoft will follow suit but we know that their Visio group is interested in SVG.
Ethan says: "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."
The amazing thing about the response to the article is that I really meant to be clear that SVG is not ready to take on Flash yet: " It is already clear that SVG will own those markets long before it gets close to replacing Flash and PDF in their core markets"..."Note again how SVG can win without fighting Flash or PDF."
- Mozilla "support" for SVG (State the current situation not just the possible future...)
2003-07-18 08:42:12 Damian Cugley [Reply]
Mozilla has, sadly, with the best possible intentions, put SVG support back several years.
First, changes to the plug-in API made Mozilla incompatible with Adobe's SVG viewer 3.
Second, the built-in SVG support does not handle a large subset of SVG, is missing many features.
It does not help that the Mozilla plan for showing SVG in an HTML document is that the SVG code be mixed in with the HTML document, as opposed to living in a separate resource linked to with an 'object' or 'img' element. There is no way to write a document that will work with both these approaches.
Mozilla is my regular web browser, but when I want to run SVG demos, I have to fire up Internet Explorer to do it. Sad.
- Mozilla "support" for SVG (State the current situation not just the possible future...)
2003-07-19 11:27:00 Paul Prescod [Reply]
First, changes to the plug-in API made Mozilla incompatible with Adobe's SVG viewer 3.
This has surely done more to hurt Mozilla than SVG. But anyhow, ASV6 will be released soon and that annoying period will be behind us.
Second, the built-in SVG support does not handle a large subset of SVG, is missing many features.
Standard-build Mozilla's do not have any SVG support and probably will not until the development has reached a more mature point. In the meantime, the plugin suffices.
It does not help that the Mozilla plan for showing SVG in an HTML document is that the SVG code be mixed in with the HTML document, as opposed to living in a separate resource linked to with an 'object' or 'img' element. There is no way to write a document that will work with both these approaches.
I expect that Mozilla will be able to display standalone SVG resources or OBJECT-embedded resources in addition to SVG mixed with HTML. But until the Mozilla implementation is mature it does not make much sense for Mozilla to prevent the Adobe implementation from handling OBJECT tags. Nevertheless, mixed namespace documents are undoubtably the future we should be working towards. That's what XML was designed to support and newer SVG features move more and more in that direction. It isn't an issue of either/or. We need both inline and out-of-line SVG.
- Mozilla "support" for SVG (State the current situation not just the possible future...)
- Mozilla "support" for SVG (State the current situation not just the possible future...)
- State the current situation not just the possible future...
- 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.
- argument
2003-07-17 18:22:04 Paul Prescod [Reply]
Rasmussen says: "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"
Yes, a Flash expert could easily generate Flash from ChessGML and an SVG expert could easily generate SVG from ChessGML. But what would an unbiased ChessGML programmer likely choose? One is a well-documented, open standard with no licensing requirements whatsoever. One is XML (as ChessGML is). One uses the same DOM that HTML and XML does. One format has a variety of competitive client implementations from .NET to Java to Symbian to C++/COM.
Rasmussen says: " the usage of svg as the output of some process involving transformation/consumption of another format is not really a domain."
Why not? It isn't an industry but it is a problem domain.
Rasmussen says: "If you have examples of other domains to offer I would appreciate it."
Well, the cartography industry has clearly made its choice. But then you might claim that that is just conversion from another format too. As I said in the article, any real domain is likely to already have a more specialized format. SVG is the interchange format.
It doesn't matter to me whether you define these as domains or not. The point is that SVG is filling in the gaps left by existing standards. When it completes the process of filling in those gaps it will replace the main domains of those standards just by virtue of its ubiquity. That's my thesis and I think it will play out over the next five years.
- argument
- 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
- Anyone can create Flash files
2003-07-18 07:15:02 Paul Prescod [Reply]
So I admitted I was wrong about Adobe. I'm willing to learn. What Microsoft tools read and write SWF? We know that they have announced a product that reads and writes SVG.
- Anyone can create Flash files
2003-07-17 18:35:37 Paul Prescod [Reply]
You are right. I am wrong. I thought that it was necessary to use Macromedia's Flash Writer to get Flash files out of Illustrator but now I know that Illustrator also has native support. I am sorry for misrepresenting the situation.
I did not claim that Macromedia was the only company that can generate Flash files. I did claim that any company that does generate Flash files is putting some control of their destiny in Macromedia's hands. If I were Adobe I would vastly prefer to put my faith in the W3C where they have representatives and some degree of control (along with the rest of the community) rather than depending on the goodwill of Macromedia. I suspect that is why they are pouring so much effort into SVG.
And by the way, SVG is licensed in a way that allows competition in all aspects of authoring and delivery but the Flash license is specifically worded to sheild Macromedia from competition. "Pursuant to the terms and conditions of this License, you are granted a nonexclusive license to use the Specification for the sole purposes of developing Products that output SWF." What if I wanted to use the specification to develop a product that did not output SWF...e.g. a competitive Flash reader?
- Anyone can create Flash files
2003-07-19 09:51:04 cole batten [Reply]
you:
" What if I wanted to use the specification to develop a product that did not output SWF...e.g. a competitive Flash reader?"
me:
"there are. one comes to mind http://www.swfxxl.com/ . the developer of which spoke at flash forward sf this year and called the normal flash player (but apologized in advance first) 'stupid' when it comes to fullscreen. thats why swfxxl exists. those wacky germans."
you:
"If I were Adobe I would vastly prefer to put my faith in the W3C where they have representatives and some degree of control (along with the rest of the community) rather than depending on the goodwill of Macromedia. I suspect that is why they are pouring so much effort into SVG."
me:
"does effort in this case equal $$$ to the w3c? also is the 'svg plugin', 'svg player, 'svg support' going to be a huge file size too like it is for the pc/mac/*nix? is that why the w3c likes that too? svg does have its place indeed. as icons supported by the os's gui."
- Anyone can create Flash files
2003-07-19 10:34:58 Paul Prescod [Reply]
I asked: "What if I wanted to use the specification to develop a product that did not output SWF...e.g. a competitive Flash reader?"
Cole responded with an example: "swfxx".
But that doesn't answer my question. Am I supposed to presume that because a bunch of "wacky Germans" have either negotiated a special license with Adobe or violated the official Adobe license that I am also free to do so? Perhaps Adobe will allow me to succeed as long as I take no market share away from their plugin and then slap a lawsuit on me when I do. If you work for a corporation with corporate counsel, ask him if the fact that a German company is doing something against the license proves that it is safe for your company to do so.
You ask: "does effort in this case equal $$$ to the w3c?
Of course Adobe plays its W3C membership fees as all other W3C members do. But some of the people influencing the specification are invited experts who do not pay any fees.
also is the 'svg plugin', 'svg player, 'svg support' going to be a huge file size too like it is for the pc/mac/*nix?
On a very ordinary internet connection I downloaded the SVG plugin in less than a minute. But the vast majority of people who have the SVG plugin got it when they downloaded Acrobat Reader and surely did not notice the extra time.
is that why the w3c likes that too?
The W3C likes it because it is an open standard controlled by a community of implementors and users.
svg does have its place indeed. as icons supported by the os's gui
The hundreds of people at the SVG conference successfully using it for mission-critical business data would beg to differ with you. (e.g. the US Federal Reserve). Oh and by the way, a Nokia representative confirmed that they are working on an SVG implementation for their cell phones.
- woah there.
2003-07-19 12:22:05 cole batten [Reply]
Ok so the full version (recommended download from adobe) of acrobat reader
for pc is 15.4MB and the smaller version is 8.7MB. Even larger for osx.
'On a very ordinary internet connection I downloaded the SVG plugin in less
than a minute.'
That's pretty sweet that you can download a minimum of 2.5MB in less than a
minute on a 'very ordinary internet connection'.
'But the vast majority of people who have the SVG plugin got it when they
downloaded Acrobat Reader and surely did not notice the extra time.'
I'm sure your right. They are already downloading 15MB or more so who cares!
I want acrotray to run all the time! Sure!
'Oh and by the way, a Nokia representative confirmed that they are working
on an SVG implementation for their cell phones.'
Ok so that's cool but on the Nokia 9210i and 9290 flash is already
supported. Less than 500k too.
- woah there.
2003-07-19 14:30:38 Paul Prescod [Reply]
Ok so the full version (recommended download from adobe) of acrobat reader for pc is 15.4MB and the smaller version is 8.7MB. Even larger for osx.
It is a demonstrable fact that people don't mind downloading the Acrobat reader and that is several times larger than the SVG Viewer. A competitive technology could be 500 bytes and if nobody cares nobody cares. My observation is that nobody cares: PDF is quite successful.
That's pretty sweet that you can download a minimum of 2.5MB in less than a
minute on a 'very ordinary internet connection'.
What can I say. I'm using a standard cable modem at home. These are measured in megabits per second. I'm also routing over Wi-fi which can only add latency.
Ok so that's cool but on the Nokia 9210i and 9290 flash is already supported. Less than 500k too.
The 9210 and 9290 are not phones. They are connected PDAs. Nokia is implementing SVG on _phones_. In particular, on the smartphones with the cameras on them. Probably not the 6600 but I would guess the next phone after that (the Nokia guy wasn't allowed to pre-announce which phone). And it isn't going to be a downloadable. It is built into the operating system and browser that comes with the phone. By the way, 500K is huge for a phone. SVG has multiple conformance levels (SVG Tiny, Basic, etc.) so it will go much smaller than that when necessary (but of course you lose features like opacity and scripting).
- woah there.
2003-07-19 17:30:18 cole batten [Reply]
oh and also:
http://www.macromedia.com/software/contribute/productinfo/flashpaper/
- woah there.
2003-07-20 12:55:41 Paul Prescod [Reply]
Flashpaper is the Flash equivalent of SVG's SVGMaker. What does it have to do with putting one or the other _inside_ of printers? It is just another Macromedia product that generates Flash. I don't see the relevance.
- woah there.
- woah there.
2003-07-19 16:20:42 cole batten [Reply]
i'll post more later but for now mr. nielsen has some words:
http://www.useit.com/alertbox/20030714.html
- woah there.
2003-07-20 12:57:20 Paul Prescod [Reply]
I'm not going to get into an argument about the virtues of PDF. I didn't say anything good or bad about PDF. It is popular and many people download the Acrobat reader. The SVG viewer will probably be bundled with it as it has been in the past. If these are both true then many people will have the SVG viewer. That's the only thing about PDF that is of interest to me as an SVG advocate.
- woah there.
- woah there.
- woah there.
- woah there.
- Anyone can create Flash files
- Anyone can create Flash files
2003-07-17 20:00:02 Jason Cunilffe [Reply]
Here's an intreresting toolkit I just heard about which reflects the hybrid needs and environment of vector grahics users and developers
"""Kinesis Software announces the release of it's latest product: KineticFusion, a great advance in rich graphical content management. KineticFusion is the perfect fusion of new technologies for the Web. For the first time, SWF files, the native format for Macromedia® Flash™ can be fully represented in a new XML vocabulary, Rich Vector Markup Language, or RVML. Our processing engine can decompile SWF to RVML and compile RVML back into native SWF format. All resources, whether ActionScript, sound, video, or images can be extracted and inserted, SWF files can be viewed and manipulated using external development tools, versioned, stored, or translated to SVG allowing users to author SVG applications using any Flash™ authoring environment.
Written in Java, KineticFusion allows you to use pure XML technologies to create dynamic interactive animations viewable on any browser that support the Flash™ plugin. Flash™ authoring tools can be used to create interfaces that can then be translated to SVG.
The KineticFusion product and available documentation are made available for free download under a Freeware license."""
http://www.kinesissoftware.com/index.html
- Anyone can create Flash files
2003-07-18 08:08:04 Ahmet Zorlu [Reply]
Just tested KineticFusion and it works great. I could compile my code only projects without using MM's compiler, I could extract data from swf and edit it (no fla involved). IMHO, this software will make it possible to convert SVG (or any XML vocabulary) to SWF and vice-versa (via XSLT).
Thank you for letting us know,
Ahmet Zorlu
- Anyone can create Flash files
- Anyone can create Flash files
- Anyone can create Flash files
