perspective extension fails on group with transforms

[Fenn]

The perspective extension works on a single path just fine. But, if you
group that path with another, and then move, rotate, scale, or skew that
group, the math goes all wrong and the result does not fit the perspective
box.

tested in 0.45.1-1 and 0.46.0-svn+16180

http://fenn.dyndns.org/pub/irc/perspective1.png
http://fenn.dyndns.org/pub/irc/perspective2.png

[Tom Davidson (tjd-mit)]

Confirmed on Fedora 6

[Zach Smith (zvsmith)]

I see that this hasn't gotten any attention recently. I was about to report this as a new bug as it has been bothering me for a while now. And although the example images are long gone, I can confirm what he is saying on 0.46 under Ubuntu 8.10 and OS X 10.4. I'm sorry for wasting your time if you have already fixed this in the 0.47 release, because I haven't checked.

It also should be noted that this applies to any path, not just groups of paths. Perspective just doesn't work if the path has any transformations on it.

For instance:
1. Create an object that is not a path
2. Rotate or otherwise transform this object
3. Convert this to a path
4. Apply the perspective effect
5. This produces an incorrect result

...on the other hand...
1. Create any object
2. Convert it to a path
3. Perform any transformation you like
4. Apply perspective effect
5. It works great

Inspection of the XML shows us that the difference here is that in the first case, the path is created, but the path contains a transformation tag. In the second, the transformation is already applied to the points in the path. Is this the way things should be? It seems to really limit the usefulness of this feature.

A quick way to deal with this would be to have the perspective code zip along the path and apply any transformations. This reduces the first case to the second and it's just some matrix-vector multiplication but it seems like a special case fix for something that will come up again and again (even in other extensions). A less quick fix would be to have "Convert to path" automatically apply any transformations to the underlying path, and also edit the resizing, rotation, skewing stuff to do the same if it is acting on a path... yuck.

Well, this is your program and I have no idea how to do this sanely, but something should be done as this seems to definitely be an error.

[Alvin Penner (apenner)]

confirmed on Windows XP, Inkscape rev 21570

[su_v (suv-lp)]

related discussion on irc about workarounds for grouped paths (like converted text):

|03:31| < jaddison> aha! this link (http://inkscape-forum.andreas-s.net/topic/104594) helped. when you apply transformations on paths, they can't be grouped. you need to ungroup them, transform (rotate, for eg), regroup them and THEN apply the perspective. that seemed to work for my simple text example - perhaps not for my more complex boxshot, but we'll see.
|03:34| < jaddison> or alternatively, transform the group of paths (which sets the transform attribute on the group in the xml editor), ungroup it (which applies the transform to individual paths within the group) and then regroup it (in order to apply the perspective). quirky, but neat.
|03:34| < su-v> jaddison: yes - for some groups I had to 'Ungroup > move the selected objects > Group' to get the perspective working

[Coz (cosimo321)]

Hey guys,
 I can confirm 0.47 on Ubuntu 9.10 karmic inkscape from repository
same thing occurs
When moving text before making it into path then trying to transform that into perspective...it will not work unless I dont touch the text before making into path

coz

[Vanessa Dannenberg (vanessadannenberg)]

Affects 0.48 and 0.48.1 (via ppa) on Maverick; A group of objects that contains simple blurs (in the Fill and Stroke dialog) and/or clips (Object -> Clip -> Set) will also trigger this bug. In such cases, the perspective tool will occasionally transform part of the object, sometimes leaving a few pieces behind untouched, scattering a few other pieces around the canvas, and deleting the rest. Attempting to undo fails to restore the object that was transformed, and often causes other, unrelated objects in the drawing to go awry as well. Attached is an example that the perspective tool makes mincemeat out of. :-)

[Alvin Penner (apenner)]

attached is a new version of perspective.py, which is used for the Perspective extension. This version will take account of transform elements that are present in either the source or the target.

[Alvin Penner (apenner)]

committed to bzr rev 10416

[su_v (suv-lp)]

@Alvin - could this backported to 0.48.x by copy&pasting the function 'invertTransform()' from voronoi2svg.py (which is new file only available in trunk) [1] into 'perspective.py ', and adding the changes to simpletransfoms.py from r10414 [2]?
Or there other underlying changes in shared extensions files the fix depends on?

[1] <http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/extensions/voronoi2svg.py#L168>
[2] <http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10414#share/extensions/simpletransform.py>

[Alvin Penner (apenner)]

would it be possible to instead add the latest versions of the files voronoi2svg.py and simpletransfoms.py . In the case of voronoi.py one would also have to modify the makefile.am, I guess, but adding a new file like that will not break anything since there is no .inx file to call it, so it will never be used except by the envelope effect. In the case of simpletransform.py the changes were only additions, nothing was edited or modified, so the new version should still be compatible with the current version.

[su_v (suv-lp)]

@JazzyNico - what do you think about adding 'voronoi2svg.py' (and 'voronoi.py' as dependency of 'voronoi2svg.py) to the 0.48.x branch? Does it pose issues due to adding a translatable 'inkex.errormsg()' to the branch (line 209), even if the inx file is not added as well?

[Alvin Penner (apenner)]

sorry, I mis-typed, the dependency is only on voronoi2svg.py, not voronoi.py

[su_v (suv-lp)]

> the dependency is only on voronoi2svg.py, not voronoi.py

But 'voronoi2svg.py' imports 'voronoi.py'. Wouldn't not finding 'voronoi.py' cause the import of 'voronoi2svg.py' in 'perspective.py' fail?

[Alvin Penner (apenner)]

yes, you're correct, I just did a test to confirm that both voronoi2svg.py and voronoi.py are required.

[jazzynico (jazzynico)]

> Does it pose issues due to adding a translatable 'inkex.errormsg()' to the branch

No. As long as it's only an error message and that the reports have an importance value higher than wishlist, I'd prefer to see the bugs fixed.

[Krzysztof Kosinski (tweenk)]

Backported to stable in 9862