![](https://secure.gravatar.com/avatar/bb65b6b3a109d97cf9f8d6c014ede042.jpg?s=120&d=mm&r=g)
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?
Why copy and ref the entire element? This will introduce a ton of unnecessary problems of all kinds
- inherited styles,
vePathRef only takes the d= from the <path>, so we need only create a bare <path> to contain the original path data.
I think this is just another hint that we don't need another element for storing just a single attribute.
Don't we have an existing facility for moving an original object around in the document without breaking clones (e.g. when grouping)? It'd be the same thing here; on conversion to a "live effect", the existing path element, with its original id, would become the final child of the switch.
So, you propose to clone the path and not the switch? why?
The idea would be that most things reference the final "output" <path> in the switch statement, so very little code would need to change (it would still be referencing an ordinary path, whose d= corresponds to the visible path).
No. Most things are not smart enough to look inside the switch for the path they expect to see. That's exactly what I'm talking about. They will all need to be painstakingly and verbosely fixed to work with this special case. Whereas with my original proposal, very little special-casing is necessary; most things (e.g. boolean ops) will work as expected with the effected path automagically.
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.