On Thu, Jul 15, 2010 at 6:50 PM, Doug Schepers <schepers@...157...> wrote:
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 think you are biased towards those implementers who are engaged, simply because you see them :) How many more others are out there, who are not engaged at all, and for whom the sudden necessity to implement the Spiro algorithm will become an unpleasant surprise?
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.
I'm not against standardizing at all. I just think that putting everything into the same standard will make it even heavier (and it's already heavy enough) and slow down its acceptance even more (and it's not like it's suffering from overacceptance right now). Mean and lean things tend to win over huge committee-designed monstrosities. SGML lingered for decades, barely alive, but a much simplified XML took the world by storm.
Once again: the core must contain things which are absolutely essential to graphics and which would be hard to do outside of the core. Spiros are none of that at the moment.
That doesn't mean you can't standardize Spiros. Assuming for a moment that they are a solid and 100% stable feature (which is not quite true, the equations easily diverge into nasty infinities; but I admit I know nothing about the Catmull-Rom curves which might be better in this respect), and you want to place a W3C stamp of approval on them, I would welcome that - but the correct way to do that would be to place them into an optional "effects" module, a separate W3C standard, which would ensure interoperability among those agents that choose to implement the spiro math, _and_ at the same time provide a Bezier-only fallback for those agents who do not. Basically, that would amount to moving the Inkscape's Spiro LPE from Inkscape namespace into a W3C namespace specific to that optional module. The Bezier-only fallback, at least for Spiros, would add only a modest amount of noise to the file and will not significantly affect file size or editability. This way you get the best of both worlds: easy implementation for render-only agents and standardization for those who want to do more with SVG.