Relating compiled offsets to edited ones

[uliska]

Currently we can determine if the position of an object differs from its compiled one.
We can also insert an extra-offset override in the source, which is great.

However, when recompiling the document the new position will be regarded as "initX/initY", and all further dragging operations are calculated from this new position. But this isn't appropriate. When we have offset an item by, say, (3 . 4) the item should however be orange after all. And when we drag that item by, say, (-1 . -2) the resulting new offset should be (2 . 2) and not (-1 . -2).

To achieve this it will be necessary to get to the next step and interpret the source itself. That is "someone" (I suppose the Object Editor) should try to find out about existing extra-offset overrides and do the necessary calculations.

But this doesn't prevent us from opening our currently planned pull request. This is actually a bigger thing and can only be tackled in the context of other issues.

[PeterBjuhr]

I would say that currently we can't deal with existing overrides at all.

You're pointing to some necessary steps. Here's an overview of how I see it:

1. When an item gets selected the Object Editor apart from examining this node also checks if there's an override node.
2. If there's an override the information from that is used to recalculate in the way you're mentioning.
3. When the new position is established the object editor will know that there is an override and change that node instead of inserting a new.

[PeterBjuhr]

In addition if the override is position based but not an extra-offset I guess it has to be transformed into that.

[jan-warchol]

@uliska you can also try using David Nalesnik's \offset, which, IIRC, can accumulate.

Good job anyway!

[uliska]

It will be a big one to discuss which overrides we will want to support for which grobs. And particularly how to design a clean user interface for that (and to write user documentation that does not encourage manual formatting).

But I think your suggestion doesn't help with the current issue. The new coordinates resulting from any tweak will show up as 0/0 after compilation.