True, but SVG's saving grace is that it's designed to be used embedded in HTML (or in XHTML back then). But it doesn't make a lot of sense otherwise. Eg. take SVG2's switch to represent drawing order in a z-index-like property, as opposed to SVG's original "painter model" where drawing order is determined by document order. Basically, SVG doesn't make any use of distinguished markup features such as element content (text elements being the only exception) and document order.
Usage of XML in business data and non-text document formats OTOH is an accident IMHO, but is still the most robust format for data exchange and archival in long-term commitment scenarios we've come up with so far, and I don't see that changing anytime soon because there aren't that many open standards being developed anymore.
Does SVG offer any advantages over, say, EMF/WMF? I know a strong advantage of WMF is that the file format translates 1:1 into GDI calls, which makes it very fast - but I don't see EMF files rendered with anti-aliasing or complex gradients. What about PDF or PostScript?
SVG would actually be great if it wasn't such a feature creep. Filters, masks, scripts and animations are supported only by some renderers, often inconsistenly. This does not seem to stop SVG generators producing documents using these features, often unnecessarily.
Good SVG can even be human-readable and -editable. I've actually fixed simple broken SVGs with vim and a pocket calculator.
PostScript is great but as a binary format not very modern, where text-based formats seem preferred. I had to look up WMF and dumping calls to Microsoft API as an 'open' standards does not sound too exciting, either.
You are right on both counts! I seem to have mixed it with PDF.
Sadly, programming is coming to SVG as well with more and more renderers supporting JavaScript. Which might be great for some use cases, but again even further disperses the field of possible generator/feature/renderer combinations that might (will) fail.
Oh dear god no. Trying to parse EMF+ is a bit of a nightmare, and it’s not just 1:1 GDI calls, there are dual EMF/EMF+ files, it’s stack based (I suppose not so bad), with klydge after kludge (especially around text)... we use it because we have to.
Simplicity of implementation. GDI's drawing primitives exist in practically all other drawing APIs so translating it to Cairo, OpenGL, or Direct2D should be trivial.
