On Sat, 2009-03-28 at 13:17 +0000, john cliff wrote:
I'd be no less SVG compliant than Illustrator, which does exactly what I'm suggesting to get round this sort of issue. Its also what we do to blurs etc when we write them to PDF, so theres precedent in the codebase already...
Personally SVG is the means to the end, not the end in itself.
Same here. I do think your proposed bitmap solution is a good way to work around the problem of other SVG renderers (first thing that popped into my head too). As much as we all love SVG and standards, SVG evolves slowly. I'd argue that we should focus on making our program more standards compliant before we start pushing beyond the current standard, however, someone had a creative itch to scratch and they did (and will probably continue to if we support them).
It seems like a lot of people want a more creatively powerful tool than SVG will currently allow (if everything is to remain scalable in other renderers). Given that, are we willing to do things less elegantly due to current SVG limitations in the name of empowering of our users?
The other side of this, what if these features do get added to the SVG standard one day and it's radically different than how it's already implemented in Inkscape. This more than likely creates a "breaking a feature" backwards compatibility issue for our users' documents... and we haven't even been willing to do this for Spirals (I seem to recall that they're not "right" formula-wise).
Cheers, Josh