On 4/26/06, Aaron Spike <aaron@...749...> wrote:

And I have implemented it that way, and I see now that this is a very small very easily reworked piece of the code.

Exactly.

...

Looks good to me. But this will require writing a rather convoluted parser for the grammar

Will the parser really be that covoluted?

To get an idea, look how e.g SVG transforms are parsed in svg/svg-affine.cpp

...

After we're sure it's gonna work, I will code the parameter parser and the corresponding infrastructure in SPShape (this will require a PathEffect class storing its own params and a linked list of PathEffect instances).

Who said you get to have all the fun coding this? ;-)

OK, I'll share :)

-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

ted@...11... wrote:

I'd really, really, really like path effects to be implemented as extensions.

Part of my plan was to beg you to make this jive with extensions. :-) We will eventually need much of the same sorts of infrastructure anyway, effects database, dynamic loading etc.

I realize that this is a little chatty. I'm counting on gzip to fix that ;)

I think Andy and various others will have a problem with the chattyness, but then again they will also likely be saving finished compacted work as plain svg anyway.

But, seriosuly, it works with the code that already does parameters for extensions and it provides doing multiple effects. I think the only downside is that you can't include the same path effect twice with different parameters. If we want to do that, I think we'll have to go with child nodes.

I hadn't thought about using one effect multiple times, but we will probably desire that someday.

Aaron Spike

MenTaLguY wrote:

On Wed, 26 Apr 2006 12:16:15 -0500, Aaron Spike <aaron@...749...> wrote:

...

I hadn't thought about using one effect multiple times, but we will probably desire that someday.

I believe it's better to think of this in terms of instances of an effect.

i.e. you're not attaching path effects to paths, but instances of them.

Indeed, that is exactly how I was thinking of it. Please keep catching my terminology until I start speaking correctly. :-)

(I was waiting for you to correct my omission of the namespace prefix on my example too. Luckily I got a chance to correct myself first.)

Aaron Spike

On Wed, 26 Apr 2006 13:16:32 -0500 (EST), ted@...11... wrote:

So, how about:

<path d="M 1 2 L 3 4"> <inkscape:patheffect id="org.inkscape.patheffect.a" val1="bob" val2="jack" /> <inkscape:patheffect id="org.inkscape.patheffect.b" var="true" /> <inkscape:patheffect id="org.inkscape.patheffect.a" val1="alvin" val2="jack" /> </path>

Looks good generally.

However, we should reserve id= for uniquely identifying elements within a document. I'd recommend using effect= to identify the effect instead. Inkscape will impose unique id= attributes anyway in this case, which is probably not what you want.

Additionally, if we're going to have attributes like val1=, val2=, etc, those names don't have any meaning; they're basically just positional. I think what I'd like to see is:

<svg:path d="M 1 2 L 3 4"> <inkscape:patheffect effect="org.inkscape.patheffect.a"> <inkscape:param value="bob" /> <inkscape:param value="jack" /> </inkscape:patheffect> <inkscape:patheffect effect="org.inkscape.patheffect.b"> <inkscape:param value="true" /> </inkscape:patheffect> <inkscape:patheffect effect="org.inkscape.patheffect.a"> <inkscape:param value="alvin" /> <inkscape:param value="jack" /> </inkscape:patheffect> </svg:path>

Though at that point, named parameters become easy:

<svg:path d="M 1 2 L 3 4"> <inkscape:patheffect effect="org.inkscape.patheffect.a"> <inkscape:param name="foo" value="bob" /> <inkscape:param name="bar" value="jack" /> </inkscape:patheffect> <inkscape:patheffect effect="org.inkscape.patheffect.b"> <inkscape:param name="zort" value="true" /> </inkscape:patheffect> <inkscape:patheffect effect="org.inkscape.patheffect.a"> <inkscape:param name="foo" value="alvin" /> <inkscape:param name="bar" value="jack" /> </inkscape:patheffect> </svg:path>

-mental

MenTaLguY wrote:

On Wed, 26 Apr 2006 13:16:32 -0500 (EST), ted@...11... wrote:

...

So, how about:

<path d="M 1 2 L 3 4"> <inkscape:patheffect id="org.inkscape.patheffect.a" val1="bob" val2="jack" /> <inkscape:patheffect id="org.inkscape.patheffect.b" var="true" /> <inkscape:patheffect id="org.inkscape.patheffect.a" val1="alvin" val2="jack" /> </path>

Looks good generally.

However, we should reserve id= for uniquely identifying elements within a document. I'd recommend using effect= to identify the effect instead. Inkscape will impose unique id= attributes anyway in this case, which is probably not what you want.

Oops. I didn't notice that. Well, actually, it goes beyond that. An id="" must be unique. And since it lives in the xml: namespace, it must be globally unique in the entire document.

name="" is probably better, since its commonly used by existing grammars, like svg or odf.

Spec'd here: http://www.w3.org/TR/2004/REC-xml11-20040204/#sec-attribute-types

...and this kinda cool little new thing that appeared recently: http://www.w3.org/TR/xml-id/

bob

On Wed, 2006-04-26 at 15:11 -0400, bulia byak wrote:

I just don't see why that simple solution might be inadequate.

Just to pick one issue:

The more we store complex structures as flat attribute strings rather than XML nodes, the more of the tree machinery (parser, AST, updates, etc...) we have to redo for that special case.

That's something I'd like to mitigate with the "generic AST" architecture I've been playing with for a long time, but we're definitely not there yet.

-mental

On Wed, 2006-04-26 at 22:40 -0300, bulia byak wrote:

SVG paths use attribute grammar and work just fine.

Why? Because they are flat.

XML is good for hierarchical structures. I do not foresee any hierarchy in a chain of sequentially applied effects, each with its own parameters.

That was just one example; XML nodes have other desirable properties like being addressable via URIs (I'm thinking mostly local references at the moment, like #id).

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.

Among other things, non-sequential composition of filters/effects of seem to be frequently desired for these sorts of things once they come into widespread use (e.g. many interesting uses of SVG filters involve trees rather than linear chains). I'd rather not close that door early by making the filter stuff non-addressable in the document.

So, I remain opposed to the approach involving non-SVG child elements.

I'm not fond of adding children to svg:path either, actually.

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 is just a rough idea, though. I'm going to have a look at how SVG vector effects are done; the architecture is very similar in some respects; I think we basically want to mirror that approach.

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?

-mental

On Thu, 27 Apr 2006 11:55:49 -0400, "bulia byak" <buliabyak@...400...> wrote:

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).

Hmm, no, what I meant by flat attributes is representing a non-trivial structure as a flat string. With SVG filters, the only thing that goes in the style attribute is a single uri reference. There's no non-trivial structure there (i.e. a list of nodes with named or positional parameters).

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.

It would have made the full specification harder to implement (and larger, and more complex). Remember that for every facility you define, you also have to carefully define the ways in which it interacts with all other related facilities.

There are also subtle issues with the particular approaach -- CSS properties aren't ordered except for overriding/inheritance, so if there were more than one filter type available via CSS, there'd be no well-defined way to stack them.

So, be careful what you wish for. The SVG filters are nearly as simple as you can reasonably get if you want to include more than just gaussian blur.

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?

That has a lot less to do with complexity of the SVG standard and more with the severe crappiness of our own codebase, which makes the things that should be easy hard. Given what we do, shouldn't adding a new element or a new CSS property be easy?

With a saner architecture, the SVG filters specification would actually be something like the path of least resistance. If you just wanted to implement gaussian blur to start with, it should have been be easy enough to implement just enough to handle a <filter> element with a single <feGaussianBlur> child and ignore the rest.

It's not, of course. Just adding a new SPObject subclass that doesn't do anything takes 40 or 50 lines of code, and dealing with anything in SPStyle is just exruciatingly painful.

...

...

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?

True. Though was almost all SPObject and RDF code bugs, not XML tree.

As far as the XML tree things are concerned, I'm also not really sure what validity checks we can or should have on our XML at that level ; past a certain point we have to trust that other code which is responsible for knowing about more specific constraints (like the RDF code) will do the right thing. Emitting non-namespaced names is actually valid, from an XML standpoint.

(I recall we had once had a bug with missing xmlns: declarations entirely, but that was no less than a bug in the XML code itself.)

-mental

On Thu, 2006-04-27 at 16:00 -0400, bulia byak wrote:

It won't break anything which worked before. To be extra sure, we can prefix all the built-in functions with inkscape:, or even make them full URNs, guaranteed unique.

An aside: at this point I'd go with a x-inkscape-extension: URI scheme for identifying extensions of any sort. I used to favor URNs, but then I realized that the way URNs are specified basically assumes a central registry to maintain uniqueness. Don't think we want to deal with that.

Personally, I'm almost sure that the defs thing will never be needed. But I don't want to bet on that. Instead I propose a start-simple approach which will be easy to extend if really necessary.

I'm not really interested in implementing fully chainable effects or anything to start with. I understand that simple and incremental is the only reasonable way to do things, since you can't expect a complicated feature to spring from the head of Zeus fully-formed. However, I do want to make sure that whatever we release with in the beginning is going to be something like a subset of the "full" approach.

Most importantly, though, as Ted pointed out, extension arguments have names, so we've got a list of nodes (path effect instances) _*which have named parameters*_.

There's not much distance at all between e.g.:

inkscape:path-effects="someeffect(amount: 3, whatever: 4) othereffect(q: 3, argle: 29)"

and the obviously silly:

inkscape:path-effects="<someeffect amount='3' whatever='4'/> <othereffect q='3' argle='29'/>"

I simply don't want to see us using parsed strings for attributed lists in an XML document. Even CSS only deals in lists of named attributes, not lists of things having named attributes.

...

That has a lot less to do with complexity of the SVG standard and

more with the severe crappiness of our own codebase, which makes the things that should be easy hard.

Yes, but this does not change my argument. We still have the same crappy codebase. But I want path effects NOW, I will not agree to wait 2 years as I did with SVG filters.

I'd really like to see SVG filters NOW, too. As bad as the SPObject code is, it's not so bad that the SPObject part of filters couldn't be done reasonably quickly. But there's not much motivation so long as the canvas/arena code isn't capable of rendering even gaussian blur. I suspect the reverse may be true as well, which is why we've not seen any progress. However, Aaron's already writing the path effect code, so we shouldn't encounter the same impasse for path effects.

I actually wouldn't object to an inkscape:gaussian-blur attribute if it helped us get filters bootstrapped, _provided we never released with it_.

By extension, I also wouldn't object to such a basic approach for path effects either, _provided we never released with it_. But I'm worried we'd find that more tempting because there'd be nobody to beat us over the head with the SVG standard in that case.

Once we release with something, we're stuck with it unless the standard says otherwise. And I'd rather not have to maintain two parallel systems for path effects when we inevitably (looking at the history of all similar things in SVG) needed more flexibility.

...

With a saner architecture, the SVG filters specification would

actually be something like the path of least resistance.

I'm not so sure of that. Maybe I'm spoiled by our crappy codebase, but at this time I really abhor the "something which refers something else out there" design. In my view it's fundamentally broken, and our ugly "vacuum defs" command is a monument to that brokenness. Again, I'm exaggerating for the sake of the argument, but you get the idea :)

Actually "vacuum defs" is a monument to us not having a real UI for managing resources in <defs>.

But yes, there are two big issues with referencing external resources:

1. handling the appearance/disapparance of the resource (e.g. even if it simply occurs later in the document and hasn't been encountered yet)

2. lifetime -- how and when should we dispose of unused resources?

However, for those resources which are a) document-local, and b) aren't first-class objects from the user's point of view, these are solved problems [via Inkscape::URIReference and inkscape:collect, respectively]. Object-local gradients are one example, and I think per-path effect lists would qualify too.

For a per-object effect list, it might be overkill, but then we've already ruled out the simplest XML solution (child elements).

...

True. Though was almost all SPObject and RDF code bugs, not XML tree.

Right. But again, this does not invalidate my argument. We still have to deal with the same SPObject and the rest of the code. You won't believe how many crashes I fixed caused simply by the the fact that Adobe SVG files have lots of empty lines and these lines end up as empty text nodes in our tree.

To be honest, I felt the need to clarify that because I feel a bit proprietary about the XML tree code. :) SPObject crashes if you look at it wrong, but I like to imagine that the XML tree, while not perfect, is really pretty decent.

-mental

MenTaLguY wrote:

That's something I'd like to mitigate with the "generic AST" architecture I've been playing with for a long time, but we're definitely not there yet.

What's a "generic AST" architecture?

Aaron Spike

On Wed, Apr 26, 2006 at 11:37:13AM -0500, ted@...11... wrote:

On Wed, 26 Apr 2006, Aaron Spike wrote:

...

I'm still rather hating the way I'm currently implementing attributes for storing live effects parameters.

Okay, I'm going to go off on a tangent here, but take a trip with me :)

I'd really, really, really like path effects to be implemented as extensions. I've got most of the code done to do this, I'll finish it up and get it into the main repository. With that, I'm going to suggest this syntax:

<path inkscape:path-effects="org.inkscape.patheffect.a, org.inkscape.patheffect.b" inkscape:extension-param-org.inkscape.patheffect.a-val1="1023" inkscape:extension-param-org.inkscape.patheffect.a-val2="bob" inkscape:extension-param-org.inkscape.patheffect.b-val1="1"

Concerning 'chattiness', the 'org.inkscape.' could be dropped since it is redundant with the 'inkscape:' prefix.

Bryce

d="M 1 2 L 3 4"
inkscape:path-effect-orig-d="M 1 0 L 2 3"
inkscape:pressures="1.0 0.8"
inkscape:tilts="45 134"
inkscape:pressures-orig="0.9 0.4"
inkscape:tilts-orig="23 34"/>

I realize that this is a little chatty. I'm counting on gzip to fix that ;) But, seriosuly, it works with the code that already does parameters for extensions and it provides doing multiple effects. I think the only downside is that you can't include the same path effect twice with different parameters. If we want to do that, I think we'll have to go with child nodes.

--Ted

---

Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&da... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel