On Thu, 2006-04-27 at 16:00 -0400, bulia byak wrote:
> It won't break anything which worked before. To be extra sure, we can
> prefix all the built-in functions with inkscape:, or even make them
> full URNs, guaranteed unique.
An aside: at this point I'd go with a x-inkscape-extension: URI scheme
for identifying extensions of any sort. I used to favor URNs, but then
I realized that the way URNs are specified basically assumes a central
registry to maintain uniqueness. Don't think we want to deal with that.
> Personally, I'm almost sure that the defs thing will never be needed.
> But I don't want to bet on that. Instead I propose a start-simple
> approach which will be easy to extend if really necessary.
I'm not really interested in implementing fully chainable effects or
anything to start with. I understand that simple and incremental is the
only reasonable way to do things, since you can't expect a complicated
feature to spring from the head of Zeus fully-formed. However, I do
want to make sure that whatever we release with in the beginning is
going to be something like a subset of the "full" approach.
Most importantly, though, as Ted pointed out, extension arguments have
names, so we've got a list of nodes (path effect instances) _*which have
There's not much distance at all between e.g.:
inkscape:path-effects=3D"someeffect(amount: 3, whatever: 4)
othereffect(q: 3, argle: 29)"
and the obviously silly:
inkscape:path-effects=3D"<someeffect amount=3D'3' whatever=3D'4'/>
<othereffect q=3D'3' argle=3D'29'/>"
I simply don't want to see us using parsed strings for attributed lists
in an XML document. Even CSS only deals in lists of named attributes,
not lists of things having named attributes.
> > That has a lot less to do with complexity of the SVG standard and
> more with the severe crappiness of our own codebase, which makes the
> things that should be easy hard.
> Yes, but this does not change my argument. We still have the same
> crappy codebase. But I want path effects NOW, I will not agree to wait
> 2 years as I did with SVG filters.
I'd really like to see SVG filters NOW, too. As bad as the SPObject
code is, it's not so bad that the SPObject part of filters couldn't be
done reasonably quickly. But there's not much motivation so long as the
canvas/arena code isn't capable of rendering even gaussian blur. I
suspect the reverse may be true as well, which is why we've not seen any
progress. However, Aaron's already writing the path effect code, so we
shouldn't encounter the same impasse for path effects.
I actually wouldn't object to an inkscape:gaussian-blur attribute if it
helped us get filters bootstrapped, _provided we never released with
By extension, I also wouldn't object to such a basic approach for path
effects either, _provided we never released with it_. But I'm worried
we'd find that more tempting because there'd be nobody to beat us over
the head with the SVG standard in that case.
Once we release with something, we're stuck with it unless the standard
says otherwise. And I'd rather not have to maintain two parallel
systems for path effects when we inevitably (looking at the history of
all similar things in SVG) needed more flexibility.
> > With a saner architecture, the SVG filters specification would
> actually be something like the path of least resistance.
> I'm not so sure of that. Maybe I'm spoiled by our crappy codebase, but
> at this time I really abhor the "something which refers something else
> out there" design. In my view it's fundamentally broken, and our ugly
> "vacuum defs" command is a monument to that brokenness. Again, I'm
> exaggerating for the sake of the argument, but you get the idea :)
Actually "vacuum defs" is a monument to us not having a real UI for
managing resources in <defs>.
But yes, there are two big issues with referencing external resources:
1. handling the appearance/disapparance of the resource (e.g. even if
it simply occurs later in the document and hasn't been encountered yet)
2. lifetime -- how and when should we dispose of unused resources?
However, for those resources which are a) document-local, and b) aren't
first-class objects from the user's point of view, these are solved
problems [via Inkscape::URIReference and inkscape:collect,
respectively]. Object-local gradients are one example, and I think
per-path effect lists would qualify too.
For a per-object effect list, it might be overkill, but then we've
already ruled out the simplest XML solution (child elements).
> > True. Though was almost all SPObject and RDF code bugs, not XML tree.
> Right. But again, this does not invalidate my argument. We still have
> to deal with the same SPObject and the rest of the code. You won't
> believe how many crashes I fixed caused simply by the the fact that
> Adobe SVG files have lots of empty lines and these lines end up as
> empty text nodes in our tree.
To be honest, I felt the need to clarify that because I feel a bit
proprietary about the XML tree code. :) SPObject crashes if you look at
it wrong, but I like to imagine that the XML tree, while not perfect, is
really pretty decent.