Hi, Transforms (translate, rotate, etc...) and lpe do not get on well... If you are not familiar to it, consider lpe-bend for instance: Imagine you rotate the input, but not the path parameter (along which the input is bent) the new result is completely different. So transforms need a particular treatment in presence of lpes.
Our solution to this problem up to now is to transform the parameters along with the object (or more precisely, to let each lpe decide what todo on transform).
This (good!) solution is user friendly, as your lpe parameters nicely move along with your object. However, it implies some limitations (please invalidate if I'm wrong!): I think it prevents from sharing lpes accross different objects, as if one is moved but not the other, which one should be followed by the lpe-parameters? Note that atm, lpe are automatically forked/made unique when you move one object, and I guess that's the reason (?right?). A related (but different) question is about "cloned" path parameters (i.e. references). I might be wrong, but I think path-reference parameters are not transformed atm. (Marginally, one can even think of lpe that depend on the object location, but not relatively to a path or point parameter --- "underlying objects color" for instance?!?--- in which case, transfering the transform to parameters is useless; hmmm! I agree, this is pure abstraction ;-)
Although this is not a critical issue ("sharing lpe" jsut does not make sens for a lot of them!!), I think it's a good thing to have, so let's discuss possible strategies!
One easy workaround is to add a "lpe-transform" at the end of the lpe-stack whenever the object is transformed (of course, if the last lpe is already a (non shared) transform-lpe, we should just update it instead of adding a new one). This is easy to implement and solves the issue. I think it is a bit cleaner as pes don't have to care about transforms anymore, etc... The (serious) drawback however, common to all solution you can think of, is that if the lpe-parameters do not follow the object anymore, you'll have to look for them all the time and everywhere: if you applied your lpe somewhere, and moved your object a lot, at edition time you'll wonder why the lpe parameter shows up at the other corner of the page, which was the original place, but you completely forgot about. :-(
As a conclusion, if we want to keep track of the objects transforms *and* allow lpe to be shared, lpe must be able to strore object specific information at objects level (not in the lpe itself in the defs). Maybe we could add one more attribute to the object, where lpes could register all the data they need (this would be usefull for other purposes anyway). This would make it possible to remember the original position of the object when the lpe was applied: lpe paramters could then be suitably transformed at apply/display/edition time, but stored untransformed.
What do you think? jfb.
On Tue, Oct 7, 2008 at 7:59 PM, jf barraud <jf.barraud@...400...> wrote:
This (good!) solution is user friendly, as your lpe parameters nicely move along with your object. However, it implies some limitations (please invalidate if I'm wrong!): I think it prevents from sharing lpes accross different objects, as if one is moved but not the other, which one should be followed by the lpe-parameters? Note that atm, lpe are automatically forked/made unique when you move one object, and I guess that's the reason (?right?).
Exactly.
A related (but different) question is about "cloned" path parameters (i.e. references). I might be wrong, but I think path-reference parameters are not transformed atm. (Marginally, one can even think of lpe that depend on the object location, but not relatively to a path or point parameter --- "underlying objects color" for instance?!?--- in which case, transfering the transform to parameters is useless; hmmm! I agree, this is pure abstraction ;-)
Well, I see nothing wrong with a LPE that reflects some other objects in the drawing or the background under it. After all, it is completely Inkscape's discretion how to construct the LPE path. Although this will require an extension of the API that LPEs use, but it's doable.
One easy workaround is to add a "lpe-transform" at the end of the lpe-stack whenever the object is transformed (of course, if the last lpe is already a (non shared) transform-lpe, we should just update it instead of adding a new one). This is easy to implement and solves the issue. I think it is a bit cleaner as pes don't have to care about transforms anymore, etc...
I think this is a good idea. It is btw similar to how we handle gradients: we have a "vector" gradient which contains color stops and can be shared, and each object has its own "private" gradient which specifies the coordinates of the gradient line for this object. When object is transformed, only its private gradient may need to be updated with the transform.
The (serious) drawback however, common to all solution you can think of, is that if the lpe-parameters do not follow the object anymore, you'll have to look for them all the time and everywhere: if you applied your lpe somewhere, and moved your object a lot, at edition time you'll wonder why the lpe parameter shows up at the other corner of the page, which was the original place, but you completely forgot about. :-(
Why can't we show the parameters already transformed with the "lpe-transform" at the end of stack, so they show up where the object is?
As a conclusion, if we want to keep track of the objects transforms *and* allow lpe to be shared, lpe must be able to strore object specific information at objects level (not in the lpe itself in the defs). Maybe we could add one more attribute to the object, where lpes could register all the data they need (this would be usefull for other purposes anyway).
I don't think an extra attribute is needed. Just add another "private" lpe to the list in inkscape:path-effect so it stores the transform, and then maybe other object-specific lpes if necessary.
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: vrijdag 10 oktober 2008 7:01 To: jf barraud Cc: inkscape-devel Subject: Re: [Inkscape-devel] lpe and transforms
One easy workaround is to add a "lpe-transform" at the end of the lpe-stack whenever the object is transformed (of course, if
the last
lpe is already a (non shared) transform-lpe, we should just
update it
instead of adding a new one). This is easy to implement and solves the issue. I think it is a bit cleaner as pes don't have to care about transforms anymore, etc...
I think this is a good idea. It is btw similar to how we handle gradients: we have a "vector" gradient which contains color stops and can be shared, and each object has its own "private" gradient which specifies the coordinates of the gradient line for this object. When object is transformed, only its private gradient may need to be updated with the transform.
LPE's already don't need to think about transforms. There is only one LPE that does something that is abnormal (curve stitch), the rest just calls the default, apparently it was copied a number of times in the source. (I'll clean it up when I'm home).
I figured adding an LPE at the end of the stack would be the same as just writing to the transform attribute of a path. Turns out this is the case, and actually bugs for subpath stitching! (set preference to optimized, scale a path with a curved stitch applied, then check with scaling when preference is set to preserved. the results are different) I.o.w. I think that paths with an LPE applied should always use the "non-optimized" or "preserved" transform attribute setting (found in preferences). So we should remove the Effect::transform_multiply method completely, and always use preserved transforms for paths with LPE.
The (serious) drawback however, common to all solution you
can think
of, is that if the lpe-parameters do not follow the object anymore, you'll have to look for them all the time and everywhere: if you applied your lpe somewhere, and moved your object a lot, at edition time you'll wonder why the lpe parameter shows up at the
other corner
of the page, which was the original place, but you
completely forgot
about. :-(
Why can't we show the parameters already transformed with the "lpe-transform" at the end of stack, so they show up where the object is?
This is already the case for the path's transform attribute.
So I think back then I made a solution for a non-existing problem. Probably just using the path's own transform attribute instead of propating the transform to the LPEs will speed up things by a lot too! (notably transforming a spiro path)
Thanks for uncovering the issue JFB :)
Johan
LPE's already don't need to think about transforms. There is only one LPE that does something that is abnormal (curve stitch), the rest just calls the default, apparently it was copied a number of times in the source. (I'll clean it up when I'm home).
I figured adding an LPE at the end of the stack would be the same as just writing to the transform attribute of a path. Turns out this is the case, and actually bugs for subpath stitching! (set preference to optimized, scale a path with a curved stitch applied, then check with scaling when preference is set to preserved. the results are different)
What if you add one lpe, transform, add a second lpe, and transform again? I think the first transform still affects the output, while the transform attribute cannot keep track of both...
I don't think you solved a non existing problem :-). We realy have to keep track of all the transforms...
As for the "private-effect", I think it's better to keep object-specific data in the object itself than in the defs: for instance, either we'll have incredibly long and ugly defs, or when deleting an object we'll have to clean them of the eventual object specific entry, which is not very natural. What about an "inkscape-lpe-local-data = #lpe1234,blah...,#lpe5678,blah...."? jfb.
participants (3)
-
unknown＠example.com -
bulia byak -
jf barraud