Since I still can't get to the Wiki to document this, after talking to the SVG WG chair and studying the LPE proposal in more detail, here's what I think the live path effect stuff should look like:
svg:defs <!-- input paths stored here; collect=always means they are auto-deleted by inkscape when no longer hreffed --> <path d="..." id="foo" inkscape:collect="always" /> </svg:defs> ...
<!-- sodipodi:type lets us bind a custom SPObject type --> <svg:switch sodipodi:type="livePathEffect">
<!-- we use the Inkscape namespace since it's not standard yet --> inkscape:vectorEffect requiredExtensions="http://www.inkscape.org/SVG/vectorEffect" inkscape:vePath <inkscape:vePathRef xlink:href="#foo" /> </inkscape:vePath>
<!-- the effects go here --> <inkscape:extensionEffect name="org.inkscape.ext.jumble"> <inkscape:param name="spacing" value="10" /> <inkscape:param name="increment" value="0.5" /> </inkscape:extensionEffect>
<!-- gets us standard SVG painting of result path --> <inkscape:veFill /> <inkscape:veStroke /> <inkscape:veMarker /> </inkscape:vectorEffect>
<!-- result path for backwards-compatible rendering, and reference by text-on-path, etc. --> <svg:path d="..." /> </svg:switch>
Bear in mind that it's not necessary to implement ALL features of vector effects upfront, merely the small subset used here.
Vector effects are documented here:
http://www.w3.org/TR/2004/WD-SVG12-20041027/vectoreffects.html
-mental
On Tue, 2007-05-22 at 16:34 -0400, MenTaLguY wrote:
Since I still can't get to the Wiki to document this, after talking to the SVG WG chair and studying the LPE proposal in more detail, here's what I think the live path effect stuff should look like:
Hmm, there are a couple of things I like, but some that I'm worried about.
<!-- input paths stored here; collect=always means they are auto-deleted by inkscape when no longer hreffed -->
<path d="..." id="foo" inkscape:collect="always" /> </svg:defs>
I really like this, I think that putting the old path data in defs and referencing it is a much better way to do it.
<!-- sodipodi:type lets us bind a custom SPObject type -->
<svg:switch sodipodi:type="livePathEffect">
I'm concerned about using a switch here, will applications like librsvg render it properly? Firefox? I don't know that this is widely supported enough to use. We need to make sure that these paths show up rendered in a large set of renders (in real life, not just a "support more of the spec" type answer)
<!-- we use the Inkscape namespace since it's not standard yet -->
inkscape:vectorEffect requiredExtensions="http://www.inkscape.org/SVG/vectorEffect"
We use flowText that isn't part of the standard yet... I would rather just leave this in the SVG namespace. I'm so frustrated with the lack of a 1.2 spec that I'm willing to risk the incompatibility...
<inkscape:vePath> <inkscape:vePathRef xlink:href="#foo" /> </inkscape:vePath> <!-- the effects go here --> <inkscape:extensionEffect name="org.inkscape.ext.jumble"> <inkscape:param name="spacing" value="10" /> <inkscape:param name="increment" value="0.5" /> </inkscape:extensionEffect> <!-- gets us standard SVG painting of result path --> <inkscape:veFill /> <inkscape:veStroke /> <inkscape:veMarker /></inkscape:vectorEffect>
I really like using the vector effect object so that the vector effects and the path effects can be stacked together. Also, this provides an easy mechanism for stacking in the path effects. (I have no idea how this UI is going to work though... :) )
--Ted
On Wed, 23 May 2007 11:35:48 -0700, Ted Gould <ted@...11...> wrote:
I'm concerned about using a switch here, will applications like librsvg render it properly? Firefox? I don't know that this is widely supported enough to use. We need to make sure that these paths show up rendered in a large set of renders (in real life, not just a "support more of the spec" type answer)
It's a valid concern. I think we'll be okay so long as they:
- at least treat svg:switch like svg:g - ignore tags in namespaces they don't understand
(obviously we should test this)
<!-- we use the Inkscape namespace since it's not standard yet -->
inkscape:vectorEffect requiredExtensions="http://www.inkscape.org/SVG/vectorEffect"
We use flowText that isn't part of the standard yet... I would rather just leave this in the SVG namespace. I'm so frustrated with the lack of a 1.2 spec that I'm willing to risk the incompatibility...
They are finally moving on 1.2 now, releasing it module-by-module rather than waiting interminably for the whole thing to spring fully-formed from the forehead of the working group. We're also a much bigger player in the SVG space than we used to be even a year ago; I am hoping to be able to take advantage of that influence. Given that, I'd rather build goodwill with the W3C by keeping their namespace clean.
I definitely don't want to see a repeat of the flowText disaster on either side.
Also, this provides an easy mechanism for stacking in the path effects.
Yeah, it's obviously functionality we'd like to have eventually, and vector effects certainly provide an already well-defined mechanism for doing just that. Much better than trying to hack in stacking later.
(I have no idea how this UI is going to work though... :) )
I think the UI will probably work something like the one for filter effects, which has essentially the same model for effect chaining (which my SoC student will hopefully come up with... :D).
-mental
On Wed, 2007-05-23 at 17:28 -0700, MenTaLguY wrote:
On Wed, 23 May 2007 11:35:48 -0700, Ted Gould <ted@...11...> wrote:
I'm concerned about using a switch here, will applications like librsvg render it properly? Firefox? I don't know that this is widely supported enough to use. We need to make sure that these paths show up rendered in a large set of renders (in real life, not just a "support more of the spec" type answer)
It's a valid concern. I think we'll be okay so long as they:
- at least treat svg:switch like svg:g
- ignore tags in namespaces they don't understand
(obviously we should test this)
I don't see where it says that switch should be treated as a group:
http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#SwitchElement
Am I missing something?
<!-- we use the Inkscape namespace since it's not standard yet -->
inkscape:vectorEffect requiredExtensions="http://www.inkscape.org/SVG/vectorEffect"
We use flowText that isn't part of the standard yet... I would rather just leave this in the SVG namespace. I'm so frustrated with the lack of a 1.2 spec that I'm willing to risk the incompatibility...
They are finally moving on 1.2 now, releasing it module-by-module rather than waiting interminably for the whole thing to spring fully-formed from the forehead of the working group. We're also a much bigger player in the SVG space than we used to be even a year ago; I am hoping to be able to take advantage of that influence. Given that, I'd rather build goodwill with the W3C by keeping their namespace clean.
Well, when is the vector effects module expected? Before 0.46? Can we ask for that one and flow text first?
(I have no idea how this UI is going to work though... :) )
I think the UI will probably work something like the one for filter effects, which has essentially the same model for effect chaining (which my SoC student will hopefully come up with... :D).
I guess an interesting question is: should they be the same UI?
--Ted
On Thu, 24 May 2007 09:04:44 -0700, Ted Gould <ted@...11...> wrote:
I don't see where it says that switch should be treated as a group:
http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#SwitchElement
Am I missing something?
No, not at all. It's just that implementing it as a group seems to be the minimal fallback position over not rendering it at all -- but that looks like a moot point; as, since I wrote that, I tried switch with Inkscape, librsvg, and gecko, and it worked fine in all three cases.
Well, when is the vector effects module expected? Before 0.46?
I don't think we can expect a final standard before 0.46. It's worth noting that they are more likely to release it if there are more prototype implementations which prove the concept (e.g. ours).
Can we ask for that one and flow text first?
Yes, I'll be getting into that soon on the SVG mailing list as a side thread to the gradient mesh discussion.
I guess an interesting question is: should they be the same UI?
Possibly, yeah. Or at least something very close. The main distinction is that a vector effect is its own object, whereas filter effects are attached to other existing objects.
-mental
On 5/22/07, MenTaLguY <mental@...3...> wrote:
Since I still can't get to the Wiki to document this, after talking to the SVG WG chair and studying the LPE proposal in more detail, here's what I think the live path effect stuff should look like:
Wow, this really looks extremely W3C-esque.
I'm not saying I'm totally against using this syntax. It will work (if implemented properly) and it probably has its advantages. I'm just saying that myself, I would not do it that way.
In particular, I really don't see any valid reason to add a copy of the original path to defs. We're speaking about path effects, which by definition do not change anything except the d= of the path. Therefore, we only need to save the original d, i.e. just a string. Why copy and ref the entire element? This will introduce a ton of unnecessary problems of all kinds - inherited styles, relinking clones, refcounting, etc. etc. - not only for the person who implements LPEs but, more importantly, for everyone else who will have to adapt lots and lots of code all around the codebase to work with effected paths.
Similarly, I see no reason to use <switch>. For flowText, using switch is a sad necessity. But here, we can do everything we want in the same path element, via inkscape: attributes, without adding another level of nesting which will make work with such constructs a lot more cumbersome.
I shudder when I think about all the disruption that will be caused by moving flowText into a switch - but again, there we have no choice. But here? Suddenly turn a plain, basic, flat <path> element into a monstrous multi-level subtree with all kinds of hrefs and stuff if I just want to round the corners? This does not look very attractive to me as an implementor.
Originally, I came up with the idea of LPE because I found a very simple, cheap, easy to implement way to build it into the existing codebase without any significant disruption. It was so simple that a proof-of-concept effect was coded by Aaron in less than a day. All we needed back then was just coding the effects themselves. The boring part was largely done (or at least it was clear how to do it, and it was very simple), what remained was the interesting part. Unfortunately this all stalled at that point. And what I see being discussed now seems to have lost all of the attractive simplicity of the original idea. And with it, it has lost much of its appeal for me personally.
I may be missing something important, of course, but for now that's how I see it.
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 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.
(One style issue I _do_ forsee with my suggestion is between setting styles on the switch versus setting styles on the result path.)
relinking clones
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.
refcounting
That should be covered via the existing tree refcounting, the xlink:href machinery and inkscape:collect.
, etc. etc. - not only for the person who implements LPEs but, more importantly,
for everyone else who will have to adapt lots and lots of code all around the codebase to work with effected paths.
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).
Similarly, I see no reason to use <switch>. For flowText, using switch is a sad necessity. But here, we can do everything we want in the same path element, via inkscape: attributes, without adding another level of nesting which will make work with such constructs a lot more cumbersome.
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. The question is -- how far do we want to reinvent SVG's vector effects without actually using them? If we allow multiple inputs and stacking, the only difference is going to be that we allow custom effect types, and vector effects give us more rendering options.
For the sake of getting Johan's SoC done, I'm content with doing this the expedient way, but I'm reluctant to do a release with the feature enabled as-is if there's going to be a lot of pressure to evolve it into a replacement for SVG vector effects, which I think there will be.
-mental
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.
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
participants (4)
-
Aaron Spike -
bulia byak -
MenTaLguY -
Ted Gould