Rotation center of groups not transformed properly

[Thomas Hicks]

I have been trying to form a (simple) mannequin by grouping together objects and moving the rotation center so that it is off centre, however when you rotate one group, the rotation center of subgroups is not transformed as expected.

See file: when you rotate the group on the right hand side, I would expect the sub-groups rotation center to remain in the same location relative to that groups contents.

Instead, it remains in the same place relative to the center of the selection

[Alvin Penner (apenner)]

cannot reproduce the problem on Windows 7, Inkscape 48.1, or perhaps I am not understanding the issue. Just for clarification, was the ellipse on the right hand side, the one that is almost at the center of the group of two objects, intended to be part of the same group or was it deliberately left out of the group?
- which version of Inkscape, and OS?

[su_v (suv-lp)]

Reproduced with current trunk - though I'm not sure if it's a bug or a misunderstanding what origin/reference the coordinates of a rotation center refer to, e.g.:
       inkscape:transform-center-y="-50"
       inkscape:transform-center-x="-50"

See attached file for a reduced example of rotating a group of a single rectangle which has the rotation center positioned at the midpoint of the top edge. The group itself has the rotation center moved to the lower left corner.

[Diederik van Lierop (mail-diedenrezi)]

This is what I posted to the inkscape-devel mailinglist yesterday, let's see if there are any objections so changing this behaviour:

Hi people,

The past weeks I've been trying to fix some transformation center offset regressions, which were caused by the new unit/viewbox stuff. That should all work reasonably well again, but it remains a headache. IMHO this transformation center handling is broken by design, and judging by some comments in the code I'm not the only one to think so. It requires all kinds of special casing everywhere transformations are being applied, due to the transformation center being expressed in horizontal/vertical coordinates, relative to the center of the bounding box. Does anybody know why it was designed like this?

If there are no strong objections, then I'd propose to use absolute coordinates, and to apply transformations as if it were simply a point of a path. This would make code much cleaner. We will no longer need to call document->ensureUpToDate() to force an update of the bounding box everytime the center is requested or changed. It might also allow us to get rid of the weird behavior of the transformation center (which should rotate with the item in case an object is rotated!)

Not that I'm going to change this now, but I might get to this after the 0.91 release.

Diederik

[dronus (paul-geisler)]

Maybe this even have some deeper implications: There is no clean control over nested coordinate systems in Inkscape.

It is not possible to exchange transformation between matrices (eg. group transform) and path control points.

So for example, if you draw a rectangle at 100,100, and group it.
The group is now implicitely placed at 0,0.
If the rotation handles are activated, a temporary bounding box center is computed and used as offset to place the rotation center. This will lead to a matrix with akward coordinates, but work as expected.

On the other hand, drawing a rectangle at 0,0, group it, and move it to 100,100.
will give a totally different situation, despite looking equally. The rotation tool will still work as expected, but creates a simpler matrix (it does not have to correct for the 100,100 offset inside the group).

To switch between both situations, one would have to enter the group, offset the rectangle, exit the group and move it to the old location again.

If grouping and manipulation of the transform origin would involve recentering of the nested coordinates, it would give a very simple, technically clean solution. Most CAD and 3D modellers work this way.
The transform centers would be stable and suitable to build a mannequin.
However, modifying underlying pathes would not affect their transform centers, which may lead to an unexpected situation for less experienced users.

So maybe Inkscape could drop the stored centers and switch to a transform center system as mentioned above, but add another state "automatic" that is the default and keeps the transform origin centered to the bounding box, unless moved manually. This would need another UI button to delete the manually placed center and revert to the automatic mode.

For several uses it would be very useful to have control about the real matrix transform origins, eg. building manequins, or split SVG documents to subgroups for use in dynamic UIs.