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
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
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
I'm just throwing out that the focal point of radial gradients snaps back to the center of the gradient when moving it nearby, this might be an area we want to ensure consistent interactions on-canvas as well (because they're similar functionally). I'm not advocating in favor of the gradient behavior btw... it can be both a hindrance and useful at different times.
Cheers, Josh
On Wed, Aug 20, 2014 at 12:32 PM, Diederik van Lierop <mail@...1689...> wrote:
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@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
Le 16/08/2014 23:21, Diederik van Lierop a écrit :
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
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Feb 20, 2015 at 3:45 PM, Marc Jeanmougin <marc@...3062...> wrote:
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
Hi Marc,
No, I won't have time for this any time soon, so if you want to fix this yourself then be my guest!
Diederik
participants (4)
-
Diederik van Lierop -
Josh Andler -
Marc Jeanmougin -
Tavmjong Bah