From: <Jea...@ma...> - 2008-01-20 23:38:43
|
Nice! I think Johan's solution is acceptable for 0.46. I am still thinking about having the output in a group. This would have some advantages. Of course, the transform would automatically go into the tranform attribute, whatever the preferences of inkscape are... But more importantly, some effects might want to produce distinct svg objects. For instance, pattern-along-path a wavy pattern on a square. You obtain a wavy square with a fancy stroke, but what if you want to fill it? Filling the orginal square is not correct, while filling the wavy one only modifies the pattern fill. A 'pattern-stroke' effect would produce two objects: the stroke and the region to be filled...(any other example??? this might not be easy to implement!!!...). I don't know if it is relevant. It might confuse users as well... As for the transform pb, one more remark: notice that the transform attributes wont solve the problem when dealing with several effects: a priori an object with n effects might require to store up to n transforms... (that was why I suggested to have simple "tranfom effects") Anyway, all this does not concern 0.46 nor bug fixing but 0.47! JFB. > It is, in a way, already fixed. > > To clearify, the problem is not in obtaining the output, it's in editing > it. There is no discussion about how the result should look with certain > parameters (this is good, because it therefore will stay the same in > future versions). > The easy solution is setting Inkscape to transformations preserved > (transform attribute is written to paths, instead of recalculating path > data), this works splendid and gives visually correct scaling. I have > this turned off, and therefore the original path data *is* recalculated > which gives visually incorrect editing problems. > Maybe this transform preserving should be a separate parameter for LPEs, > with a toggle in the dialog to turn it on and off quickly. > > -Johan > > > >> -----Original Message----- >> From: lib...@li... >> [mailto:lib...@li...] On >> Behalf Of Jea...@ma... >> Sent: zondag 20 januari 2008 10:29 >> To: lib...@li... >> Subject: Re: [Lib2geom-devel] Impossible to correctly scale >> LPE stitch subcurves? >> >> Hi! >> I think that when trying to apply transform to an object >> having a path effect, the transform should go into a >> "tranform" attribute. >> >> Maybe the result of a path effect could be a group containing >> the output. >> I think this would "solve" the problem, but this would also >> open the way to more sophisticated outputs (?) >> >> This also means that the transform attribute should be >> applied to the path before the effect is computed, and >> removed from the output... >> >> A better fix would be as follows: in the future, we can dream >> of multiple effects applied one after the other. A transform >> is then simply a "linear effect". Applying a new transform >> would simply mean insert a new "transform effect" at the end >> of the list. You could navigate the list (or even better, the >> tree as we might want to breaks things into components), and >> the transformation would go at the current level... >> >> >> > Please ignore my earlier mail because it was sent too soon. :-( >> > >> > >> > Hello all, >> > >> > I am trying to fix transformation behavior for LPE (translation, >> > scaling, rotation). I think I found a fundamental problem. >> > >> > Take Stitch Subcurves. Let's say we are stitching between a >> straight >> > horizontal line, and a line with a horizontal and angled part: >> > Because stitching is equidistant, the stitch start points would be: >> > >> > ____o_____________o >> > / >> > / >> > / >> > o >> > >> > o__________o___________o >> > >> > Note that the distance between stitch points is constant >> *along* the >> > length of the line (not just the distance in the >> x-direction as this >> > would not work in general) >> > >> > Now, after scaling in the Y direction: >> > >> > __________________o >> > / >> > | >> > | >> > o >> > | >> > | >> > | >> > / >> > | >> > | >> > | >> > | >> > | >> > | >> > / >> > o >> > >> > o__________o___________o >> > >> > Can you spot the problem? The 2nd line has shifted position >> along the >> > line, because the distance along the angled part of the topline >> > changed dramatically. >> > For 'correct visual scaling' the result should have been: >> > >> > ____o_____________o >> > / >> > | >> > | >> > | >> > | >> > | >> > | >> > / >> > | >> > | >> > | >> > | >> > | >> > | >> > / >> > o >> > >> > o__________o___________o >> > >> > This however can never be the result of any stitch subpath, because >> > the stitch start points are not equidistant (unless using >> the variance >> > parameters and being very very lucky). >> > >> > I have attached an SVG for you to try with the latest inkscape SVN. >> > Note that this problem exists regardless of the "scale >> width relative" >> > setting. >> > >> > Thanks for any comment on how to "fix" this. >> > >> > kind regards, >> > Johan >> > >> ---------------------------------------------------------------------- >> > --- This SF.net email is sponsored by: Microsoft Defy all >> challenges. >> > Microsoft(R) Visual Studio 2008. >> > >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________ >> > ________________________________ >> > Lib2geom-devel mailing list >> > Lib...@li... >> > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel >> > >> >> >> -------------------------------------------------------------- >> ----------- >> This SF.net email is sponsored by: Microsoft Defy all >> challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Lib2geom-devel mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Lib2geom-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel > |