![](https://secure.gravatar.com/avatar/01c2dd03530db1afb305df3aaad0fed8.jpg?s=120&d=mm&r=g)
bulia byak wrote:
On 5/24/07, MenTaLguY <mental@...3...> wrote:
On Thu, 24 May 2007 17:20:26 -0300, "bulia byak" <buliabyak@...400...> wrote:
Therefore, we only need to save the original d, i.e. just a string.
It'll become more important when we start needing more inputs beyond a single path (e.g. for eventually reworking the calligraphy tool as a path effect as had been discussed, we'd also need intput paths representing e.g. pressure and tilt over time).
Why paths? I think what we need here is an array of width values, or an array of pairs of [distance, width]. I think even such inputs are easily representable as strings in extension attributes. If SVG stores all paths as strings, why can't we do the same for stroke width which is structurally even simpler than a path?
I agree that svg:paths are probably not the right input type for caligraphic effect parameters. I would assume an artist would think more about adjusting the final ouput (ie parameters such as width and angle of the stroke) rather than the physics of how the mark got on the page.
Multiple input paths are necessary. A blend effect will require them, though a blend effect could be accomplished easily using the technique you describe below (ie generating an array of new paths with inkscape:path-effect="blend(#path1, #path2, 0.2)").
Moving objects to the defs will be necessary. A live Union effect will require this, as will any other effect that proposes to replace multiple objects on the canvas with a single object rather than distorting a single path.
Introducing additional XML structure becomes necessary anyway if we want to be able to stack path effects, which I can promise will start getting requested if we release with non-stackable effects.
Stackability of effects is orthogonal to using switch for the path itself. As I proposed before, why can't we just go on with the simplest possible approach:
<svg:path inkscape:original-d="..." d="..." inkscape:path-effects="effect1(param) effect2(param,param) ..."/>
I'm sure this will cover 99% of all practical needs, including, as you see, stackability. If ever in the future we feel that this is too limiting, we can always introduce a way to reference a separate stack of effects, similar to a filters stack:
<svg:path inkscape:original-d="..." d="..." inkscape:path-effects="url(#effects-stack)"/>
with effects-stack being in defs. This won't break any past or future compatibility.
IIRC, my original suggestion for path effects was something similar to the svg:transform grammar as you have described above. You were originally opposed to this method because it requires a grammar and a parser; I was originally opposed to the single effect with parameters attributes because it didn't get very far into the sorts of effects system I had envisioned.
I personally think that we will be able to get a significant amount of mileage out of:
<svg:path inkscape:original-d="..." d="..." inkscape:path-effects="effect1(param) effect2(param,param) ..."/>
If others would agree to participate, I believe we can make a lot of progress in this discussion by listing features (in the wiki?) that will be necessary in our path-effect system, descriptions of effects that will require such features and examples of grammars that may fulfill such needs.
Aaron Spike