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
On Wed, Aug 20, 2014 at 12:32 PM, Diederik van Lierop
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
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
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 has a 'transform-origin' property which is defined
> in terms of the bounding box. This property is/will be supported by all
> major browsers.
>  http://www.w3.org/TR/css-transforms-1/#transform-origin-property
Video for Nerds. Stuff that matters.
Inkscape-devel mailing list