Hi, Bulia-
bulia byak wrote (on 7/15/10 2:16 AM):
My humble opinion is that, with the current official standard still not 100% supported in a lot of software (I'm not speaking only of Inkscape), adding more fancy features would be premature.
Actually, as I mention on the W3C SVG mailing list, we have a rare opportunity to bring the various implementers (authoring tools, browsers, and toolkits) up a notch, while such disruption is relatively minor in bad effects. Right now, implementers are engaged. How long will that persist?
I also think that SVG, as the graphic core, should only support things that are very difficult or impossible to do in upper layers, like filters or color management. Things like spiros or polygons (another thing they wanted to add that I was against) are best done via extensions, the way Inkscape does them. This way SVG renderers (as opposed to editors) are freed from the burden of implementing these algorithms.
No offense, but this is a very static-authoring-tool-centric view. For dynamic effects and animations, which are increasingly part of the SVG "renderer" experience, and for multiple-tool workflows, this model breaks down. For example, as a web developer, Inkscape is only of limited utility to me because the output is not very developer-friendly.
Obviously, Inkscape should feel free to experiment and extend SVG however you want, as you have been doing; this is a great way to find new features that benefit everyone. But when those changes are not reflected in the underlying format, the authoring and user experience drifts further and further apart, and intention is lost. Interoperability is far more important than the features of any given tool.
The SVG community and infrastructure is a large and complex ecosystem, of which Inkscape is a very valuable part... but only one part. For many use cases, this new path command would be really useful, and I don't think it harms Inkscape at all.
So, I'm interested to hear your specific technical objections to adding Catmull-Rom curves (or something similar) to SVG 2. They were very easy for me to implement, and would be fairly trivial for any renderer... much less of a burden than even the simplest filter.
Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs