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.

Thanks Tav for pointing this out! So instead of the "inkscape:transform-center-x" and "inkscape:transform-center-y" we have now, we would need to support "transform-origin". It's still expressed in terms of the geometric bounding box, but it's relative to the top left corner (instead of the center). So we need to change this anyway. I still believe that it would be best to use absolute coordinates in Inkscape, both for ease of coding as well as for intuitive manipulation by the user. But we would then have a write a relative center to the file, complying with the CSS standard. That shouldn't be too difficult. On top of that, the GUI for these manipulations needs some love. For example, in the selector tool the transformation center is only used for rotations and skewing, but not for scaling and stretching. For scaling and stretching, the corner or midpoint opposite of the bounding box opposite to the handle is used instead. This is not really consistent. I believe that for any transformation, it should be possible to use either the transformation center or the point opposite to the handle. There will be use cases for both, and we only have to provide a single toggle on the selector's toolbar. And while we're at it, we can add a toggle to reset the transformation center too (currently, the only way to reset it is to use the XML editor) Diederik On Mon, Aug 18, 2014 at 10:12 AM, Tavmjong Bah <tavmjong@...8...> wrote: > > On Sat, 2014-08-16 at 23:21 +0200, Diederik van Lierop wrote: > > 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. > > I haven't thought this through carefully but you should note that CSS > Transforms Level 1[1] has a 'transform-origin' property which is defined > in terms of the bounding box. This property is/will be supported by all > major browsers. > > Tav > > [1] http://www.w3.org/TR/css-transforms-1/#transform-origin-property > > ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Hi Diederik, Have you planned to do anything about this matter ? I was working on bug 168651 (tiled clones in transformed groups) and found it quite a hassle to find what was going on in which coordinate system for the center. I also found a bug related to the new unit stuff (when in a non-px document, a transformation center is wrongly computed for tiled clones) -- Mc