
On 4/27/06, MenTaLguY <mental@...3...> wrote:
I need to check, but if I remember correctly some of the original SVG filter and vector effect proposals used flat attributes as you propose, but obviously they decided not to do that. Our path effects have similar design considerations, so I'd rather not repeat old mistakes.
This is entirely different, as you yourself note below. Filters _do_ use flat attributes on the paths themselves, it's only that these attributes refer to something external (which may or may not be hierarchical).
I'd almost like to see something like:
svg:svg ...
<defs> ... <inkscape:path-effect xlink:href="x-inkscape-plugin:org.inkscape.effect.foo" id="path-effect2"> <inkscape:param name="blah" value="foo" /> </inkscape:path-effect> ... </defs> ... <svg:path ... inkscape:path-effects="#path-effect2 ..." /> ... </svg:svg>
This approach would satisfy me, but why not make it even simpler: designate a number of built-in extensions that do not require putting anything in defs and give their parameters right in the attribute. These built-ins can be freely mixed with references to defs (probably added later), which would apply to plug-in effects that are similar to the current extensions. The effects in defs even could contain their own code right in SVG, and have arbitrary nesting or hierarchy if needed. For example:
<svg:path ... inkscape:path-effects="#path-effect1" />
<svg:path ... inkscape:path-effects="add-nodes(10);radius-randomize(5)" />
<svg:path ... inkscape:path-effects="add-nodes(10);#path-effect2;#path-effect3" />
And speaking of W3C example, I think as an implementor you should agree that their filters system is a huge burden. It's flexible? Perhaps (though they still don't allow new effects apart from those defined in the spec, as far as I can see). But if _in addition_ to that flexibility they would allow to simply add "gaussian-blur:5;" to style, without any hrefs or defs, I would have written a support for this in a couple days. Without this simple alternative, filters remain unimplemented for years, and now we have to declare them a SoC project in the hope to get them finally working. See the difference?
IMO it's a case of overengineering, and given the general fragility of our XML tree, it's much more trouble than it's worth.
Fragility? Howso?
Did you notice how much trouble was caused by adding RDF metadata?
- There are no validity checks on output XML, so at first we were producing SVG without proper namespace declarations.
- A lot of code assumed that there's nothing but defs and items under the root, so metadata caused a number of freezes and crashes in various parts.
I think the assumption that SVG paths have no children is embedded even deeper.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org