[Issue] Why does Ctrl+V add offset to object position?

[smiropolsky]

Dear OpenOffice Users,

May I ask for your help with the following case?

When an object is copied (Ctrl+C) or cut (Ctrl+X) and pasted back (Ctrl+V), the pasted object appears with a small offset comparing to the original object position. The offset is rather small, but definitely visible.

The question is,
a) Is it a bug or a feature?
b) Is it possible to turn this "feature" off?

Best regards,
Sergey M.

[acknak]

I've noticed this also but it doesn't seem to happen all the time and I never bothered to work up a report for it. I've seen each alternative (paste with or without an offset) followed by different software but never "paste with a tiny offset some of the time" -- I think it must be a bug.

[Tutorial] Reporting bugs or suggestions

[RoryOF]

I've just tried it on Xubuntu, at a magnification of 200%. 20 copies and pastes, not an offset!

[Zizi64]

I have tried it on WinXP, a lot of copies and pastes, not was any offset!
(tried on AOO3.4.0, LO3.6.4.3, LO4.1.1Portable)

But it seems "slightly thicker outlines" when I have pasted a lot of same object on same place...

[acknak]

Hmm, on copying a single object and then pasting a bunch of times, I see a shift of 0.01 mm in the position on the first paste; the following pastes then keep the same value. Each time I repeat the copy/paste, the position shifts.

My guess is that the screen rendering is actually magnifying the shift--0.01 mm seems too small to notice otherwise.

[smiropolsky]

Thank you for the hints. It seems that a) this is really a bug, and b) I have probably just found the reason.

I have tried to describe the steps to reproduce it and the possible reason in the attached document. May I ask you to try to reproduce it at your OpenOffice?

Alltogether, the object seems to have two "frames". One is "physical", consisting of the object points, which are normally located at the document's grid. The second is the "displayed" frame, i.e. it wraps the displayed object with all labels, thick edges, etc., and is larger than the physical frame.

it seems, that when an object is copied,
- the reference point is "copied" as left top corner of the displayed object frame
- the object is pasted into the reference point with the left top corner of its physical frame

This explains the three test cases above.

The objects with a zero frame thickness are pasted almost exactly at the same location as the original object, since the physical and displayed frames almost coincide. By repeating the procedure iteratively (test case 1b in the attached document), the offset can still be observed.

The objects where the displayed frame is larger than a physical frame (e.g. due to thick edges or wide labels, test cases 2 and 3) are shifted by the difference in frame sizes, or more exactly, by the offset in the the location of left top corners of the "displayed" and "physical" object frames.

UPDATED: This refers to OpenOffice 3.4.1. Starting with 4.0.0 the behaviour is different.

[acknak]

No, I don't see the larger shifts, only the very tiny one (0.01mm).

The second is the "displayed" frame, i.e. it wraps the displayed object with all labels, thick edges, etc., and is larger than the physical frame.

This is called the object's "bounding box".

If there's a specific term for your first frame--the area encompassed by the object's vertices--I don't know what it is.

[smiropolsky]

No, I don't see the larger shifts, only the very tiny one (0.01mm).

The first moral of the story for me is, "always try the latest version before reporting bugs"

I have just updated the OOffice to the latest version (v4.0.0). The behaviour has been changed. As you say, the high line thickness shows no more influence on the copied object position, i.e. the object is pasted exactly over the original object. However it seems, that the developers have just implemented a "crutch" into the code, and just paste the object with the center of "vertex box" into the center of "bounding box". This works correctly as long as the boxed have the same center.

Take a square object with a thick frame line (case A in the screenshot below). The bounding box and vertex box are different, bus have the same center. The pasted object appears exactly over the original object.

Take a square object with a zero frame line, add an extra thick line at any of it's sides or corners, and group the objects together (case B, C). The vertex box of the entire object doesn't change comparing to the case A, while the bounding box becomes asymmetric due to the thickness of the line added at ONE box side.

Now copy-paste the object. The pasted object is inserted with an offset, which is (presumably) equal to the shift between the centers of the vertex box and bounding box.

Repeat the experiment, but extend the thick lines for the entire edge width (case D). The round line tip now sticks out and extends the bounding box at the other sides, making it again symmetrical with the same center as the vertex box. Copy-paste this object. Since vertex-box and bounding-box centers are at the same location, no offset is observed.

ooo_4.0.0_XP32_bug.png (6.81 KiB) Viewed 11331 times

Could you test it at your OOffice? If this is true, this can still be reported as a "bug".

Anyway, thanks for the help. At least now I know, how to avoid the issue.

[keme]

[...]
Alltogether, the object seems to have two "frames". One is "physical", consisting of the object points, which are normally located at the document's grid. The second is the "displayed" frame, i.e. it wraps the displayed object with all labels, thick edges, etc., and is larger than the physical frame.

it seems, that when an object is copied,
- the reference point is "copied" as left top corner of the displayed object frame
- the object is pasted into the reference point with the left top corner of its physical frame
[...]

Nice catch, Sergey!

Multiple tests indicate that this was an issue only with the initial Apache versions.

• 3.3.0 on Windows 7: not an issue (only the tiny shift as indicated by acknak, regardless of asymmetry)
  3.4.0 on Mac OSX: Issue present: Pasted objects with "asymmetric line thickness" is shifted from the original object.
  3.4.1 on Windows XP (as you reported): Issue present
  4.0.0 on Mac OSX: not an issue
  4.0.1RC1 on Windows 7: not an issue

So it seems that there was a bug introduced in version 3.4, but it is fixed for current versions.

[alg]

This was dependent on the line width used for the object, it was set off by half of the line width used. Thus it did not happen on hairline (which have no width) and not on objects without a line. This was fixed in AOO400. HTH!

[tkerlin]

Hi guys!

I'am not much experienced in AOO, but exactly this issue bothers me for a long time. And it still happens to me even in freshly updated AOO 4.1.1. :/

I usually set a grid to 1 mm x 1 mm and copy-paste action on anything more complex than zero-width-line object causes an pasted object out off the grid, which is really annoying when you want to draw a simple perpendicular schematics.

Thus, was it really fixed in AOO 4.x.x?

Thx for reply,
Tomas K.

[acknak]

Hi and welcome to the community forum!

I'm not seeing the problem myself, from your description. Copy/paste, even with line thickness >0, always obeys the 1mm grid setting.

One issue: it's quite easy when dragging objects to fall into drag/drop mode, which does not obey the grid. And once an object leaves the grid, or has a dimension that doesn't fit the grid, it can be difficult to get it back onto the grid and the misalignment can propagate.

It would be helpful if you could attach a small sample drawing and describe the steps to follow to see the problem.

I don't know any solution for this, other than to

[tkerlin]

Hi acknak and thax for your comments!

1) I really meant the copy-paste action done by pressing CTRL+C and CTRL+V, not by drag/drop approach. But thx for reminding!

2) In my previous post, I was wrong with the grid, it's set to 1 cm x 1 cm, with 10 steps subdivision. I enclose the screenshot, but it's in czech, however the "fit to grid" and "visible grid" checkbox are checked.

My grid settings (in Czech language)

3) The procedure:
a) There is a zero-width-line box on [0,00 cm; 0,00 cm] position and a "thick" (1 mm) line at [0,00 cm; 0,00 cm].
b) I select both the box and the line.
c) I press CTRL+C.
d) I press CTRL+V.
e) Inserted objects are at [0,00 cm; -0,02 cm], which seems negligible at first glance, but is clearly visible.

Below is a picture of pasted objects with a visible offset and the "Position and size" window. I enclosed also the source ODG file.

The pasted objects with a visible offset and the "Position and size" window.

AOO_411_copypaste_problem - pasted objects Position and size window.gif (9.38 KiB) Viewed 10006 times

Thx for your time!
Tomas K.

[acknak]

Interesting. Yes, I see that as well.

The pasted position is correct when I copy/paste one object at a time, but the position is off when I copy/paste both together.

It seems to be the line thickness that throws it off; my guess is that the bug was fixed for the situation where only one object is being pasted but not for pasting a collection of objects.

[tkerlin]

It seems to be the line thickness that throws it off; my guess is that the bug was fixed for the situation where only one object is being pasted but not for pasting a collection of objects.

Acknak, also the one object (even with zero-width-line) is placed off the grid when it is e.g. line with some "endings", see previously enclosed ODG file and the perpendicular line ended with circle.

It seems that there si something wrong. I give it up for now and continue to align the pasted object with its original as I did till now
Tomas K.

[acknak]

... also the one object (even with zero-width-line) is placed off the grid when it is e.g. line with some "endings", ...

Right. I see it as well.

The problem seems clear: the paste is using a size for the objects that includes the extra thickness coming from the line width or line endings.

[acknak]

I just realized: you can duplicate the selected objects correctly using the Edit > Duplicate function. It's less convenient than copy/paste but it's not horrible. There's a built-in shortcut key, Shift+F3, and you can re-configure that to something more convenient. The dialog settings are "sticky" so it just takes a couple of keystrokes to use it.

[acknak]

Submitted bug report:
Issue 125533: Copy/paste changes position for line+ends or multi-selection with thick lines or line+ends
You can register there and add your vote (up to two) or comment.

[tkerlin]

Thanks, Acknak, for bringing forward the Duplicate function, it satisfies my needs very well. I didn't know about that.

Tomas K.

[smiropolsky]

Nice to hear, that there were some more people interested in this issue

Acknak, thanks for noting the "Duplicate" functionality. This is exactly what I was trying to do with Ctrl-C + Ctrl-V sequence.