item.pivot is specified in the item's local coordinate space. Wouldn't it be better if it was in the paren't space?

[lehni]

Consider the following case:

Sketch 1

The item doesn't pivot around the expected pivot point, because the shape's internal center point is always at [0, 0], and it always has shape.applyMatrix = false (shapes can't bake transformations into their content), therefore it does not share its coordinate system with the parent. Simply moving it to a new position means that it stores that translation in shape.matrix, and after that the pivot is off.

The solution currently is to manually transform into the item's internal, local coordinate space:

Sketch 2

In comparison, gradient registration points aren't provided in local coordinates, but in parent coordinates, and that's way more intuitive to handle, e.g.:

Sketch 3

I would like to argue that we defined item.pivot wrongly.

Here's a proposal for a solution:

• Introduce item.anchor, describing the same attribute as item.pivot, but in the parent's coordinate system.
• Deprecate item.pivot, but keep it around for now, delegating to item.anchor, with internal correct transformation.

Please let me know your thoughts.

[dexterial]

I think that this anchor point is quite important, especially when handling animations (rotations and scaling particularly). I would argue that all points in any shape should be assigned as offsets from this anchor point and not as global coordinates as this will simplify so much the design of odd/complex shapes.

[lehni]

Well we already have this item.anchor point, but it's called item.pivot. This issue is about in which coordinate system it should be specified. Also, please note that only path items (Path and CompoundPath) can contain points in Paper.js, Shape items are for predefined geometries.

If you create a path item with path.applyMatrix = false, then you have a local coordinate system for the points you're adding, and can use the pivot as the location around which you're rotating. Currently, you specify it in local coordinates, so this works:

Sketch 1

The problem I am seeing is that this doesn't work:

path.pivot = path.bounds.topLeft;

Sketch 2

And for anything other than paths, this is strange, because for Shape, PointText, etc. items, you never work with the internal coordinate system...

With this proposed new anchor point, you could still do what I do in Sketch 1, as long as the Path you are creating doesn't have transformations stored in its matrix at the time you're creating the segments:

Sketch 3

But this would be the confusing situation then:

Sketch 4

I still think that this proposed anchor point is more aligned with how things are specified elsewhere, e.g. gradients... Is this clearer now?

[mokafolio]

I think in my port pivot is actually in the parents transformation space as I assumed that was how it was done in the first place. I'll double check and study your sketches a little more to make sure I am not misunderstanding this.