This has been a bad month for the Scalable Vector Graphics movement Because of a developing family medical crisis, I've had to step down from chairing the SVG Open 2006 conference, a decision which, combined with other issues that the conference has had, led to the mutual decision by the SVG Open board to cancel the conference this year and hold it in 2007. This decision was hard to make, given the importance that this conference has for many people and not a few companies, but it is also a reflection of larger factors that have seriously buffeted the standard over the course of the last year.
Adobe this week made an announcement that was, while not unexpected, yet another blow - they were choosing to stop supporting the Adobe SVG Viewer in any fashion, to make it unable for download by the end of the year and to effectively dismantle the last vestiges of SVG outside of the fairly secondary roles that that standard plays in Adobe products in favor of their own FLEX language, acquired from Macromedia during the merger last year.
Thanks for taking the time to write this, Kurt; I've learnt an incredible amount from this state-of-play roundup.
If you are ever to see adoption of the outside-the-vendor XML languages, you have to learn to think outside the W3C endorsement and into the XML-as-allied languages environment.
SVG refused to sit down with X3D determine the requirements for a 2D layer in 3D. SVG arrogantly asserted it could become a 3D language when it is inherently not designed for real-time 3D. Today there is a 2D layer running in some of the X3D browsers which are still slowly but surely gaining market acceptance, and doing so after XML.COM's editor also arrogantly refused an article from a major X3D veteran, Tony Parisi, claiming that the space should be dedicated solely to X3D.
You shot your own feet off by assuming you had the upper hand when all you had was a mound of sand above a hurricane surf. Such opportunities erode fast, Kurt. As I said then, I say now: to survive past emergence, a new species has to find its natural allies and propagate through them. Every place SVG could find fungible soil, it should have planted a seed.
We get too embroiled in the politics and forget that the most important survival characteristic is running code and rough consensus. Nothing about that has changed.
Ooops. "That the space should be dedicated solely to SVG". And that 2D layer is not SVG. That train pulled away from the station without SVG because SVG couldn't be bothered. As for O'Reilly's editor's decision, that was just dumb. Oddly enough, when people go looking for an X3D tutorial via Google, one of the most popular is one I wrote for XML.COM when Ed Dumbhill helmed it.
Who learns? The ones that keep an honest accounting for their own mistakes.
I like that Firefox 2.0 beta 2, has svg:Textpath ability... I'm hoping a few people start doing SVG coded blogs. Things could get very interesting then.
"SVG refused to sit down with X3D determine the requirements for a 2D layer in 3D. SVG arrogantly asserted it could become a 3D language when it is inherently not designed for real-time 3D. "
Wherever you got that information from is a terrible source. It's completely wrong. SVG was never intended to be a 3D language. Never, ever, ever. As for being used as a 2D texture in a 3D canvas, then it is as good as or better than any raster format (after all, it is resolution independant). The fact that many people have implemented real-time SVG viewers using 3D libraries proves this.
"Meanwhile, work has effectively stopped on the Mozilla Firefox SVG implementation, at least until after the release of Firefox 2.0, and while it is certainly hoped that the program will be continued the rumors at this point are somewhat grim, with the very real possibility that SVG is considered to be disliked politically by certain factions within the organization in favor of the WHATWG Canvas specification."
This is untrue; Mozilla SVG development has continued unstopped since Firefox 1.5 has been released, and the current code has numerous improvements, bug fixes, and new features. You can experiment with this codebase by downloading a trunk nightly build from Mozilla.
However this code will not ship as an official release until Firefox 3.0, as Firefox 2.0's layout engine comes from the same development branch as Firefox 1.5. Firefox 2.0's SVG support differs from 1.5's in the addition of <textPath> and a number of low-risk, high-benefit bug fixes (query bugzilla for fixed1.8.1 & SVG, and see the attachment list of bug 339220).
There are certainly those who dislike the SVG standard, but the objections are usually technical in nature rather than a political preference for the <html:canvas> specification. I think most realize that both the SVG and <html:canvas> approaches are valid for their appropriate problem domains.
"Adobe ... to make it unable for download by the end of the year"
Kurt, Adobe will stop the downloads as of Jan 2008, not Jan 2007. We still have a year to get something else in that vacuum. Good to find you back blogging, I haven't seen anything at understandingxml.com for quite some time. I guess this is your new home?
"Wherefore" means "why."
Wow! This has certainly struck a chord or three. In response, let me address the following:
1) Dan. Thanks!!
2) SVG and X3D. Len and Dean, yes, SVG has little to do with three dimensional systems, but there is enough overlap at the point where 3D involves surface characteristics that the issues do come up. There are a number of issues involving filters in particular that do touch upon the realm of 3D, and I've long felt that the lack of anisomorphic matrices, while understandable from an efficiency standpoint, has long been a limitation of the language.
More to the point, I think that a constructive dialog between the 2D and 3D camps would have been useful in the development of both specifications, and from my (albeit distant) standpoint, I didn't see a lot of cross communication between the two. Given the increasing importance of both 2.5D and 3D effects on the desktop, this lack of communication may prove problematic in the future.
3) Tim - Fantastic! I had heard from a few sources that there was some discord within the Mozilla team concerning the future of SVG, and was actually hoping to hear from you or someone else as to whether in fact that was true. I've been concentrating on the Firefox 2.0 build because I have an application I'm developing on it and the amount of cleanup necessary to go from nightly build to 2.0 is distracting enough I do so only when necessary, but if you are correct in saying there is considerable progress being made, I will definitely check it out.
I have a lot of hope for the Mozilla SVG implementation - I think it will make or break the standard in a way that no other development can, and if in fact it is in fact still on track I can only cheer about that.
4) Jeff - Thanks for the clarification - I had seen January 2007 in the report I was looking at, and wondered at the abruptness of it. I shall make a change to that forthwith.
5) Devon - You've given me a very disturbing idea ... he he he he.
6) Jeremy - Um ... yeah (feeling sheepish). You're right. Wherefore does in fact mean why. Okay ... it's still a cool title (feeling very sheepish)...
Real-time vector 3D systems use 2D layers for a variety of tasks, HUDs being one. It wasn't a terrible source, Dean. It was arrogant. The editor of this page was one (not Kurt; Kurt has always been helpful and technically excellent).
Survival in a world of competitive force is hard, but thriving is about reproduction so the felicity of allies is all important. It is easy to mistake the top of the long tail for the most powerful end, but often, it is the slowest, transient and mediocre. What is important is to establish sustainability not authority. Languages that keep on keeping on after the press and the pundits depart have a very strong survival core even if they aren't reproducing at the phenomenal rate of an entity introduced into a vacuum (if HTML had serious competitors at the time, it would have died stillborn and TimBL would still be a CERN network engineer).
There are two technical issues for a markup language of any kind that affect its sustainability:
1. The rate at which the syntax productions (say namespace) are adopted into other languages (say aggregate).
2. The interoperability of the object model by which they are implemented.
These are related but separable and both can be exploited to amplify or retard the rate of the language's reproduction, thus its survival chances in a competitive ecosystem. If you have to choose between authority (the source) and sustainability (the survival of the resource), choose the means that sustain.
"Real-time vector 3D systems use 2D layers for a variety of tasks, HUDs being one. It wasn't a terrible source, Dean. It was arrogant."
I'm still very puzzled. I can't remember ever getting any detailed set of requirements from anyone in the 3D community. I can't even remember any vague requirements being mentioned. I'm not sure how we can be arrogant when there was no communication.
It would have been an interesting discussion if X3D had participated in the SVG process. 3D on the Web was, and still is, an obscure use case compared to the majority of Web graphics. If there is still a way to enable SVG use in X3D then I'd be happy to help. Maybe you could describe the problem?
"I've long felt that the lack of anisomorphic matrices, while understandable from an efficiency standpoint, has long been a limitation of the language"
I'm not familiar with the term "anisomorphic", so I'll assume you mean "non-affine transformations". Agreed! I was planning to make a small Bard's Tale clone in SVG (not the best application, I know, but still would have been cool!) until I discovered that I couldn't do the wall graphics with SVG because of this limitation (without severely distorting things and getting a "fish-bowl" effect). At the moment, SVG truly is restricted to 2D unless you're talking about simple 3D wire-frame approaches with straight lines...
"3D on the Web was, and still is, an obscure use case compared to the majority of Web graphics."
Really? Still repeating the same dumb self-serving and self-immolating position? Ok, let's do a quick search.
There is nothing obscure about it. You weren't listening.
The problem is the X3D spec writers had to move on because their market was heating up.
Anisomorphic is (mostly) equivalent to non-affine transformations, yes. Admittedly, I understand the rationale - non-affine transformations require a 4x4 matrix, rather than the SVG 3x3 matrix, thus in theory being optimized for processing, but given that even baseline systems now have GPUs that have hardware enabled 4x4 transformation pipelines the benefit seems somewhat more marginal.
Thanks, Tim, for answering. When I got to the part that SVG in Mozilla might be dead, I almost emailed you a panicky cry for help! ^^ I'm glad that you and your SVG efforts in Mozilla are still healthy. And I still think that it has the potential to be the "critical mass" app that brings attention to SVG. I think one small but indicative datum is that more people are making sure that their HTTP servers send the SVG mime-type.
Kurt, cheer up. You sound as if giving the death knell for SVG. Those of us working on SVG apps (for me, Inkscape) honestly think quite differently. There is a feeling that SVG is rapidly approaching the watershed beyond which people will realize what a handy format it is. Maybe the W3C has its problems, but the idea itself is starting to do quite well.
And Adobe's viewer? Even though it is one of the best renderers available, it has always been a thorn in the side of people wanting to further the standard. Why? Because so many web sites display their SVG with an EMBED or an OBJECT tag, rather than the proper IMG tag in HTML or SVG tag in an XHTML document. Only recently have browsers begun to display SVG either way, but it is still a pain. Who knows? Maybe Adobe leaving the field will be an opportunity for someone to fill the gap with a proper, full blown SVG engine with animation, scripting, and SMIL updates.
As an aside, although using the two unused columns of the last row of an affine transform would provide perspective, why break the design of 2d drawing to fit it into 3d? Isn't this a perfect occasion to use mixed XML namespaces? Affine transforms are closed, making them clean and elegant. Rather than mixing and muddling rendering models, why not layer them cleanly?
Thanks. It has been a frustrating couple of weeks when I wrote this, though I think most of the points are still valid. However, as Dickens wrote, "It was the best of times, it was the worst of times."
I have long held that the Adobe viewer was a mixed blessing for the SVG community - it showed what was possible with the language, but it also encouraged a number of bad habits (ignoring the need for namespaces for instance) and the on again, off again stance of its development tended to keep people from adopting alternatives.
I had breakfast recently with a colleague of mine involved in traffic control systems who has been following SVG very closely, and I found that, after some thought, there were a number of areas where I think SVG is looking up. Inkscape (and related projects like Scribus) continues to gain credibility as the application becomes more refined and polished. I'm encouraged by the way that people are now talking with one another in the industry - and how core technologies for implementing this standard are increasingly becoming adopted by wider and wider audiences.
My argument on the non-affine transformations is only partially in support of 3D, though that's the obvious use case for it. It has more to do with processor support on 3D chips - SVG rendered using 3D ops in hardware obviously will solve many of the major performance issues that have plagued most implementations of it that I've seen, and indeed I've seen a couple that actually do go that route to good effect. Such chips have become largely standard issue on most desktop devices and are increasingly common in embedded systems. A 4x4 tensor can also be optimized for pipeline flows in a way that's more awkward for a 3x3, which means that while a 3x3 will be somewhat faster to compute normally, the difference between processing is not 16/9 but probably close to 11/9. In other words, for a comparatively small degradation on low end devices using software computation, where high performance transformations (for animation, as an example) are relatively uncommon, you gain a sizeable advantage on desktops and higher end PDAs that do have 3D chips.
I think that while SVG and X3D do not need to be muddied, there are places where quasi-3D effects (such as the lighting filter) are already in place in the SVG standard. Admittedly, filters (both raster and vector) are generally extant only at the very outer edge of most SVG use cases, but this is again a chicken and egg problem - people do not use them because they are slow and awkward, and because many implementations do not even support them.
This is, by the way, another area where 3D chips shine. Most 3D capable systems have a very rich and sophisticated filter pipeline, to the extent that it seems silly to do these filters in software when perfectly good ones exist in hardware that are 1000 times faster.
Okay - beating a dead horse here ... I worry that SVG is making the same mistakes that the WAP group made six years ago, assuming a too low benchmark in some areas and too high in others, then finding that they had obsoleted themselves out of the market.
By the way, I did want to say that I think Inkscape is one of the true success stories of SVG - I use it daily (and have since the time that it and Sodipodi were still joined at the hip) and I believe that it sets a high but achievable bar for other SVG aplications out there. I see SVG becoming the de facto open source 2D graphical standard, though I also see stormclouds emerging on the open source front, but that's a discussion for another day. Keep up the good work, and I'll try to be a little more upbeat in my next SVG post ;-)
Maybe this is a dumb point.
HTML, as best I can tell, is, at its simplest,
content and formatting
Word Processing (such as Word or WordPerfect) is as well.
And so is, as best I can tell, basic RSS / XML code.
From what I've seen, getting SVG, viewable on the web
does not appear to be simple or straightforward.
Something as simple as
along the same lines of
I know that images and svg are not the same and that may
be an understatement. Nonetheless, perhaps for SVG to grow
in popularity and use, simple, comprehensible implementation
would seem to be key.
To the extent that browsers implement accessible implementation
procedures for incorporating svg into web pages svg may have
a promising and extended lifespan. If I have to learn XML or
XHTML and jump through complex hoops to get svg to work, I,
and perhaps others will probably be far less likely to implement it
over JPG, PNG, GIF, PDF, or SWF formats which require far less
code for access.
It doesn't seem to lend itself well, that I can tell, to text
based HTML coding. Perhaps more recent wysiwyg HTML editors
are more amenable to working with SVGs.
There are folks here far smarter than I am, but that appears to
be part of the problem, at least from where I sit.
Paper, pen, and a basic grasp of one's native language for the
most part has been all that has been necessary for communication.
HTML, XHTML, PERL, CGI, PYTHON, SQL, Actionscript, COBOL, UNIX,
Linux if these were required prerequisites for communication for
all their abilities and power, I fear, the vast majority of
people would still be illiterate.
I value the web for much of what it can do and, in many ways for
the simplicity by which it is accomplished. And I am frustrated
by the alphabet soup of the many different methods by which content
can be created for the web, each of which it seems requires an
understanding of some complex programming method each with its
respective advantages and disadvantages, standard and nonstandard
If this be intolerable ignorance on my part, please educate me.
SVG is conceptually no more complicated than HTML, but it differs from HTML in much the way that graphical PostScript differs from RTF. I find it useful to think of SVG having a very definite structure, one which really isn't that different in the main from HTML:
<g> (*One or more*)
<use> or primitives (*One or more*)
Indeed, about the only thing that you lack in comparison to an HTML document is the notion of a body per se, though in practice I usually place a group tag around everything else to serve in that capacity.
I think you do need to appreciate that graphics are not structured page layout - RTF, Doc format, etc. Postscript files are quite complex, as are Flash files - its just that in neither case are you ever likely to actually see these formats at the byte level, whereas you can see the structure of an SVG document.
Doctor Who takes three prizes at the National Television Awards in a repeat of its success last year...
Doctor Who takes three prizes at the National Television Awards in a repeat of its success last year...
Colombia's vice president is "baffled" by Kate Moss's success following cocaine allegations...
Colombia's vice president is "baffled" by Kate Moss's success following cocaine allegations...
Wherefore means why, not where.
Someone pointed me to your writeup here, thanks Kurt!
I agree with Mike Moore, it's way too hard to simply make your SVG appear reliably in a couple of the key browsers, i.e. FF and IE+ASV. In-line SVG would be preferred, this EMBED & plug-in garbage is a huge negative. Like another writer corrected you, luckily FF has got a strong, plug-in-free SVG in it.
Your point about binding is important, and that would be great if we had it. But my needs are much more fundamental. Don't need binding, don't need 3-D, don't need animation, for our types of problem-statements.
Thanks again Kurt!
great article about SVG, i found it throught http://www.svg.org