2009/8/2 Krzysztof Kosiński <tweenk.pl@...400...>:
While rewriting the node tool I necessarily had to look into path effects. Live path effects are currently seem to be represented by a single svg:path that has information on what the original path looked like in the inkscape:original-d atribute, the applied effects in another attribute, and additional. I think this is not very flexible, because it does not allow for example nondestructive boolean operations where both operands are other path effects.
Actually it does, and we even have these boolean operations in the codebase. They are just disabled for now because they are buggy on the 2geom side. But they work and they are live :)
- A live path effect is represented by an svg:switch element.
That would work, and it is indeed more generic in that it would allow other replacements than path->path, for example path->bitmap or anything else. In fact, svg:switch is just a general mechanism for these kinds of renderer-specific stuff. But the intent of "path effects" is path->path mapping - its entire terminology and tools are focused on this. Other mappings should be treated separately, and indeed they would use svg:switch. For example, we URGENTLY need to convert our flowtext into a switch which would have our flowtext stuff in the Inkscape branch and its exact equivalent using svg:text in the default branch.
However, for the path->path domain of path effects, our current representation without switch is adequate, especially since it was made applicable to groups and thus made possible live booleans. I just don't see what a change you're proposing would buy us.
- The first element in that svg:switch is an inkscape:path-effect element
that contains all the information about objects it was generated from. Shape parameters are represented as inkscape:path-effect-param elements that can contain anything including svg:use, svg:rect, svg:path, another inkscape:path-effect etc. This could allow very nifty things like live boolean operations. It would also simplify the node editor, because it could just operate on the invisible children of inkscape:path-effect while being completely unaware of path effects.
But it will still need to know to go into your switch's correct branch to find them. Just as now, it just knows to read the inkscape:original-d attribute instead of d, but otherwise it is "completely unaware of path effects."
As bonus points, path effects created from rectangles, circles, spirals, etc. could preserve the editing capabilities of those shapes.
And they do now. Try assigning Gears to an ellipse - you will still see ellipse handles that are editable, and the effect will update live. There are three problems with this right now:
- it only works in shape tools, not in Node - hopefully your node tool rewrite will take care of that
- if you assign an effect which has its own knotholder, such as Hatches, you will lose ellipse handles because we can only have one knotholder at a time. Again, this is either in the scope, or very close to it, of your SoC work, so hopefully we'll see this fixed soon :)
- rect does not use path element at all and so cannot have any path effects - this needs to be fixed in SPRect, has been planned for a long time.
So, these three issues need to be addressed, but this does not require us to change the SVG representation at all.
Now some use cases:
- To create an outline of some collection of objects, we create clones of
them, group them, apply Flatten Group and then Offset. Result: whenever any of those objects is moved or modified, the outline updates.
This is possible now, if only we had these effects available. One of them is there but disabled - it's Union. Offset badly needs to be written (hey 2geom folks!) so we can finally remove the "offset object" abomination.
What do you think? I think when done this way, path effects (or maybe they should be called Vector Effects, because they're not really limited to paths?) provide a generic vector equivalent to filtering. This means they could become super-powerful, and in fact the main method of editing complex drawings. There would be some problems with legacy live path effects, but it can be dealt with at document load.
Well, I think our path effects are already a "vector equivalent to filtering" and "super-powerful" :) They just need to be cleaned up, UI limitations fixed (which you are working on right now!) and then it will be dream come true :)