On 4/26/06, Aaron Spike <aaron@...749...> wrote: Sure, I never claimed this is the best layout. But it's fastest to implement. I proposed it as a quick way to get it up and running, to get at least a couple real effects working to test them in real life. Unfortunately this is taking much longer than I expected. Looks good to me. But this will require writing a rather convoluted parser for the grammar, which is rather a lot of work for the idea which is still untested in real life. So I propose to organize it like this: I think at this time you should concentrate on SPCurve distortion functions, port one or two real effects from Python, so we could test how effected objects behave in different situations, how easy it is to make them behave sanely, and if there are any gotchas in that (there may well be). 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). I think this is the best approach, with both of us doing what we can do best :) -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

On 4/26/06, Aaron Spike <aaron@...749...> wrote: Exactly. To get an idea, look how e.g SVG transforms are parsed in svg/svg-affine.cpp OK, I'll share :) -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

ted@...11... wrote: 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 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. I hadn't thought about using one effect multiple times, but we will probably desire that someday. Aaron Spike

MenTaLguY wrote: 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: 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: 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: 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: 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. 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. Fragility? Howso? -mental

On Thu, 27 Apr 2006 11:55:49 -0400, "bulia byak" <buliabyak@...400...> wrote: 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). 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. 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. 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: 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. 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. 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. 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). 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: What's a "generic AST" architecture? Aaron Spike

On Wed, Apr 26, 2006 at 11:37:13AM -0500, ted@...11... wrote: Concerning 'chattiness', the 'org.inkscape.' could be dropped since it is redundant with the 'inkscape:' prefix. Bryce