While scouring the web for SVG news on Friday from my various channels I came across an article which has a nice and short summary of vector graphics concepts and languages currently in the wild. However...
The article draws the rather bizarre conclusion that, because there are so many vector languages out there (PS, PDF, Flash, SVG, XAML) that we should invent "yet another vector graphics format" that would be simple to use. I believe the author comes to this surprising conclusion by way of determining that:
- PS is ancient, too complex and depends on external fonts
- PDF is not supported by many applications
- Flash is not an "open standard"
- SVG is needlessly complicated (can be combined with CSS) and verbose (uses the ubiquitous XML)
Of course I've drank a lot of SVG Kool-Aid in the last year, but I'd like to take on the author's SVG points:
SVG Is Complicated ... But Modular
While there is no denying that the SVG specification is complicated and contains too many features, there is nothing stopping implementers and developers from working with reasonable subsets.
SVG has a couple well-defined profiles that specify which group of features need to be implemented to support a given profile. The SVG Mobile Profile (Tiny and Basic) limit the functionality in a reasonable way.
In addition, SVG uses language constructs to allow developers to determine which individual features are supported by a particular implementation. Thus, if you want to use SVG filters in your code, simply write a <switch> element that chooses to use filters when they are supported and something less glamorous when they are not. While ideally I'd like all features to be supported today, at least I can theoretically proof my code to support all features and let the implementors catch up.
The fact that SVG authors attempted to integrate CSS support into the language is actually a good one, though it has led to grief within the SVG WG over incompatibilities between the two specs. And yes, both are very complicated specifications - this is generally because they need to be - but again, use what you want and ignore the rest. Just because SVG can integrate with CSS does not mean you must integrate with CSS.
SVG Is Text ... But Who Cares?
The second part of the SVG conclusion that the author draws is that XML is a poor basis for a vector graphics language because it is needlessly verbose.
Actually, when I first learned about SVG, I had very similar feelings. I, too, felt it didn't make sense for a language describing graphics to be in ridiculously verbose text XML. And the way drawing commands are included in the spec (the d attribute in the <path> element) indicates that the SVG WG attempted to be more efficient on this than in the rest of the spec. It felt (and still feels) like an odd mixture.
Anyway, it took me awhile to warm up to text. The bottom line: I got over it.
The usual benefits spouted when arguing for textual representation still apply: 1) you can whip up something in a text editor, you don't need a complicated development environment, 2) Testing something is as easy as saving your file and refreshing the browser, there is no mandatory compilation step, and 3) other people can easily learn from your work just by viewing its source, reading your comments, following your well-named entities and event handlers. These are very low barriers of entry for SVG. As HTML proved, a clean and open text format can actually help foster adoption and innovation.
And while I would agree that <path> elements are neither easy-to-read nor perfectly efficient, I would argue that verbosity was used where it counts the most: On identifying graphical objects, on determining overall structure of an image, on primitive types that are easily styled and often used, on scripting and event handling. Anything else can be delegated to a drawing application like InkScape.
But I would offer yet an additional benefit to having SVG in text: 4) You keep the concepts of graphics and compression separate.
We don't complain that software languages like C++ are in text even though they are used to express arbitrarily complex algorithms and functionality, because we know that intermediate software will take my high-level concepts and efficiently crunch them down. The same thing applies for SVG if you want it: SVG implementations support compressed SVG. If you are so concerned about efficient use of disk space/network bandwidth, you can compress your SVG code using gzip, the browsers will handle it!
Put another way, why should a graphics experts designing a language need to worry about verbosity and efficiency of space? That is not their area of expertise. Their job is to design a language that provides useful and intuitive graphical features to developers. Let other experts who design compilers and compression algorithms worry about efficiency. That way, if someone thinks up a new algorithm for gzip, SVG text automatically gets the benefits without having to change the actual language. In my opinion, there is a benefit to having these two concepts distinct.
Conclusion
I think the conclusion that was drawn in the article is a fairly odd one. The author suggests inventing a new, simpler language instead of using a logical subset of, or improving, an existing one. I think a new format is the absolute last thing we need. The waters are already muddy, let's stop tossing stones into the pond.
Of all the options on the table, the SVG specification is the only one that is truly open: No one company controls the specification. Anyone can contribute to the review process. Anyone can read the full documentation of the spec. Anyone can write a SVG viewer using the spec. Anyone can develop software to author SVG.
Ah, that's some refreshing Kool-aid!