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
> > 2. 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
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
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).