On Tue, 2004-01-27 at 13:37, bulia byak wrote:

Think what will happen when we use groups as layers, and what is happening already now that it's possible to select within group. For example:

• group some objetcs

• move and scale the group

• select an object within group

• copy

• paste

Auto-propagating transforms doesn't fix this. What happens if you're working on a document that was originally prepared without transformations "flattened", or are working in the non-flattening editing mode?

What happens if you want to paste _inside_ a group acting as a layer?

The real fix for this is to record the full effective transformation relative to the document root at the time the object is copied, so we can adjust the pasted copy appropriately for its new context.

The simplest way to handle this with the existing clipboard code would probably be to find the transform for the node relative to the document root.

copied transform = ( docroot * ... * parent * node )

(where docroot...parent are where the node is copied from)

Then when the node is pasted:

pasted transform = ( 1/( docroot * ... * parent ) * node )

(where docroot...parent are where the node is pasted)

That approach applied naively is subject to a little numerical imprecision, but it wouldn't be anywhere near as bad as an auto-flattening mode, and it still leaves room for improving accuracy.

Really, our current clipboard code is severely broken though. Copy and paste shouldn't be done at the simple XML level (except perhaps in the XML editor), because there is important context we need to capture.

We also need to worry about similar issues for e.g. copying objects with gradients across documents anyway.

Also see this bug:

https://sourceforge.net/tracker/index.php?func=detail&aid=867521&gro...

[ the bug describes updating node editing stuff failing to update when the parent node's transformation changes ]

How do you propose to solve these problems without propagating transforms within groups? Especially given that groups may nest arbitrarily deep?

See my note on the bug -- propagating transforms down the tree is the wrong way to fix this too.

Of the two approaches:

* propagating transforms downwards:

- lossy -- math errors will accumulate quickly

- work required increases polynomially with nesting depth

- altering the transforms on individual nodes is very expensive (it triggers all kinds of updates, as well as the matrix calculations involved)

* attaching listeners to parent SPItems

- limits effects of transformations

- work required increases only linearly with nesting depth

- using listeners is relatively inexpensive

I certainly think a "flatten transformations" or similar feature is useful sometimes, but should remain an explicit operation, done only when requested.

-mental