[Issue] Why does Ctrl+V add offset to object position?
- smiropolsky
- Posts: 10
- Joined: Fri Feb 01, 2013 2:22 pm
- Location: Dortmund, Germany
[Issue] Why does Ctrl+V add offset to object position?
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.
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.
Last edited by Hagar Delest on Mon Nov 23, 2015 12:05 am, edited 2 times in total.
Reason: tagged [Issue] (link to a bug report).
Reason: tagged [Issue] (link to a bug report).
OpenOffice 4.0.0 on Windows XP 32 Bit
Re: Why does Ctrl+V add offset to object position?
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
[Tutorial] Reporting bugs or suggestions
AOO4/LO5 • Linux • Fedora 23
Re: Why does Ctrl+V add offset to object position?
I've just tried it on Xubuntu, at a magnification of 200%. 20 copies and pastes, not an offset!
Apache OpenOffice 4.1.15 on Xubuntu 22.04.4 LTS
Re: Why does Ctrl+V add offset to object position?
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...
(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...
Tibor Kovacs, Hungary; LO7.5.8 /Win7-10 x64Prof.
PortableApps/winPenPack: LO3.3.0-7.6.2;AOO4.1.14
Please, edit the initial post in the topic: add the word [Solved] at the beginning of the subject line - if your problem has been solved.
PortableApps/winPenPack: LO3.3.0-7.6.2;AOO4.1.14
Please, edit the initial post in the topic: add the word [Solved] at the beginning of the subject line - if your problem has been solved.
Re: Why does Ctrl+V add offset to object position?
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.
My guess is that the screen rendering is actually magnifying the shift--0.01 mm seems too small to notice otherwise.
AOO4/LO5 • Linux • Fedora 23
- smiropolsky
- Posts: 10
- Joined: Fri Feb 01, 2013 2:22 pm
- Location: Dortmund, Germany
Re: Why does Ctrl+V add offset to object position?
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.
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.
- Attachments
-
- ooo_bug_description.odg
- (17.08 KiB) Downloaded 271 times
Last edited by smiropolsky on Fri Sep 20, 2013 9:55 am, edited 1 time in total.
OpenOffice 4.0.0 on Windows XP 32 Bit
Re: Why does Ctrl+V add offset to object position?
No, I don't see the larger shifts, only the very tiny one (0.01mm).
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.
This is called the object's "bounding box".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.
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.
AOO4/LO5 • Linux • Fedora 23
- smiropolsky
- Posts: 10
- Joined: Fri Feb 01, 2013 2:22 pm
- Location: Dortmund, Germany
Re: Why does Ctrl+V add offset to object position?
The first moral of the story for me is, "always try the latest version before reporting bugs"acknak wrote:No, I don't see the larger shifts, only the very tiny one (0.01mm).
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.
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.
OpenOffice 4.0.0 on Windows XP 32 Bit
Re: Why does Ctrl+V add offset to object position?
Nice catch, Sergey!smiropolsky wrote:[...]
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
[...]
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
Apache OO 4.1.12 and LibreOffice 7.5, mostly on Ms Windows 10
Re: Why does Ctrl+V add offset to object position?
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!
OpenOffice 3.3/3.4 on various systems
Re: Why does Ctrl+V add offset to object position?
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.
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.
OpenOffice 4.1.1 on Windows 7
Re: Why does Ctrl+V add offset to object position?
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
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
AOO4/LO5 • Linux • Fedora 23
Re: Why does Ctrl+V add offset to object position?
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. 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.
Thx for your time!
Tomas K.
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. 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.
Thx for your time!
Tomas K.
- Attachments
-
- AOO_411_copypaste_problem.odg
- The source ODG file.
- (8.56 KiB) Downloaded 262 times
OpenOffice 4.1.1 on Windows 7
Re: Why does Ctrl+V add offset to object position?
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.
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.
AOO4/LO5 • Linux • Fedora 23
Re: Why does Ctrl+V add offset to object position?
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.acknak wrote: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.
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.
OpenOffice 4.1.1 on Windows 7
Re: Why does Ctrl+V add offset to object position?
Right. I see it as well.tkerlin wrote:... also the one object (even with zero-width-line) is placed off the grid when it is e.g. line with some "endings", ...
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.
AOO4/LO5 • Linux • Fedora 23
Re: Why does Ctrl+V add offset to object position?
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.
AOO4/LO5 • Linux • Fedora 23
Re: Why does Ctrl+V add offset to object position?
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.
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.
AOO4/LO5 • Linux • Fedora 23
Re: Why does Ctrl+V add offset to object position?
Thanks, Acknak, for bringing forward the Duplicate function, it satisfies my needs very well. I didn't know about that.
Tomas K.
Tomas K.
OpenOffice 4.1.1 on Windows 7
- smiropolsky
- Posts: 10
- Joined: Fri Feb 01, 2013 2:22 pm
- Location: Dortmund, Germany
Re: Why does Ctrl+V add offset to object position?
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.
Acknak, thanks for noting the "Duplicate" functionality. This is exactly what I was trying to do with Ctrl-C + Ctrl-V sequence.
OpenOffice 4.0.0 on Windows XP 32 Bit