On Mon, 2009-03-30 at 08:24 -0500, Ted Gould wrote:
I understand that it's valid SVG. But, it's against the spirit of a vectored format. I personally found it inadequate when I found out that Adobe Illustrator made gradient meshes into bitmaps in SVG. Not that it wasn't valid SVG, more that it was an unreasonable workaround.
Many old-school vector artists think that SVG filters are also against the spirit of a vectored format... myself included. Ask any vector purist what they think of using bitmap anything (effects, textures, etc) in a "vector" image. The reality is that most people aren't purists and are willing to compromise when it's for very useful features. I think I abuse filters more than most... simply because I'm utilizing features of a powerful tool. And if filters weren't a part of the SVG standard? If inkscape offered them, I'd still use them. SVG is just a means to an end for me. As long as things are scalable in Inkscape, my needs are met.
Oh, and Adobe's gradient meshes are in no way a priority for scalable representation in SVG... it's totally a reasonable workaround for them. I don't think that hindering the abilities of their graphics application in the name of supporting a secondary format (as far as they're concerned) would make any sense. I guess what I'm getting at... Illustrator has some great features, if they can't provide a scalable alternative with SVG, should they just refuse to export? Either way, bringing up Illustrator is pointless... their goal isn't primarily to be an SVG editor, the fact that it exports to the format is a bonus for their users.
- Unless there's some serious speed increase in the way we render
blurs etc, we should probably avoid workarounds that introduce more
I'm not suggesting that *we* render it using a blur, I'm suggesting that we represent it in the SVG using a blur. Just like when drawing spirals we're not constantly editing the nodes, we're looking at the metadata, detecting it as a spiral, editing it as such, and then putting it back out as a path.
Editing vs representation in the doc was not the issue. However, what you said, us rendering something one way in inkscape and then us making other renderers render it in a different way, is an issue. I would think that it looking the same in different renderers would be a higher priority.
I would also think it would be nice of us to be considerate to our users, especially if we are going to abuse blur. Do we then put a nag screen saying "You used feature X, we have blurred the heck out of A, B, and C for the benefit of scalability in other renderers, so expect the app you open this in to be unresponsive for a couple minutes... oh and it may not look the same as it did in inkscape anyway"? Yes, it's exaggerated... but without such a nag, our bug tracker would implode from the weight of the reports of us producing SVGs that lock up every other app that opens them.
Again, I don't think anyone is saying a bitmap workaround would be optimal. So I think that we're all wasting time and energy agreeing on the fundamentals.
As for user expectations, let's say we have groups A and B... A wants the best and most capable vector graphics app, B wants an SVG editor. The question is do we implement features in a wonky way (meaning comparable features for every other vector app look significantly different) for the sake of scalability in other renderers? Do we refuse to implement features because there's no scalable solution for SVG? Or, do we make a compromise and allow things to behave and look right in Inkscape, and limit the scalability of the output but keep it compliant? To me, the last one is the best solution if there would be a big enough benefit to the user (and users that don't want to use the features for religious reasons don't have to).
Cheers, Josh