Bug 86512 - EDITING: Some objects displaced upon paste
Summary: EDITING: Some objects displaced upon paste
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: preBibisect, regression
Depends on:
Blocks:
 
Reported: 2014-11-21 06:52 UTC by Luiz Gonçalves
Modified: 2021-11-29 18:06 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
minimal example (52.32 KB, application/vnd.oasis.opendocument.presentation)
2014-11-23 08:42 UTC, Luiz Gonçalves
Details
test presentation with shape / group - orig and copied/pasted ones (14.88 KB, application/vnd.oasis.opendocument.presentation)
2019-02-16 16:41 UTC, Cor Nouws
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luiz Gonçalves 2014-11-21 06:52:07 UTC
When cutting and pasting objects or groups of objects inside the same slide or into a differente slide of the *same presentation*, 
**** Impress displaces pasted objects (both vertically and horizontally), relatively to the original object, in both X and Y positions.****

This is quite annoying, specially when drawing diagrams where alignment is critical.

Steps to reproduce:
1. Draw any object (arrows, circles or something)
2. Copy object (CTRL + C)
3. Paste object (inside the same slide or into another one) (Ctrl-V)

Current behavior:
Pasted object displaces +0.15mm in X direction and +0.1mm in Y direction (always positive displacements). Different displacements are obtained for different presentations.

Expected behavior:
Keep X and Y positions of pasted objects the same as the copied/cut objects.
Comment 1 Terrence Enger 2014-11-21 18:03:39 UTC
I see the behaviour tha Luiz asks for in each LibreOffice version that I have tried:
(*) daily dbgutil bibisect repository version 2014-11-21
(*) 3.5.4.2 as delivered with debian-wheezy
(*) Windows tinderbox from 2014-11-21.
Comment 2 A (Andy) 2014-11-22 22:48:26 UTC
Reproducible with LO 4.4.0.0.beta1 (Win 8.1).

Tested with an arrow:
To reproduce/see it I had to zoom in.  If I press CTRL + V the first time then the arrow will be a little bit above.  When pressing CTRL + V once more then the arrow will be pasted at the same place as the first pasted arrow.

But I could not reproduce/see this behaviour with the rectangle and circle shapes.
Comment 3 Luiz Gonçalves 2014-11-23 08:42:27 UTC
Created attachment 109886 [details]
minimal example
Comment 4 Luiz Gonçalves 2014-11-23 09:01:13 UTC
I(In reply to A (Andy) from comment #2)
> Reproducible with LO 4.4.0.0.beta1 (Win 8.1).
> 
> Tested with an arrow:
> To reproduce/see it I had to zoom in.  If I press CTRL + V the first time
> then the arrow will be a little bit above.  When pressing CTRL + V once more
> then the arrow will be pasted at the same place as the first pasted arrow.
> 
> But I could not reproduce/see this behaviour with the rectangle and circle
> shapes.

I've added an example.
It seems that there are roundoff errors when dealing with C&P of shapes. I've not checked all possibilities, but even when a C&P operation *apparently* does not promote a displacement, it does. When it *does not*, it's *likely* to be a coincidence.
The problem seems to be significantly worse when dealing with shadowed shapes.

IMHO, the problem is related with the storage of the temporary object: the object attributes are not *likely* to be cloned, but being copied in some other way. (I didn't look at the code, though)
 
Cheers
Comment 5 Luiz Gonçalves 2014-11-23 09:15:53 UTC
Terrence
I'm using LibreOffice since 2010 (I guess it was OpenOffice at that time), at that time with Ubuntu 10.04 and I remember that these problems *did not* happen.
In all machines I use (Xubuntu 12.04 32bits/64 bits, 14.04 64bits, notebooks, desktops, whatever), the problem is the same. I also remember using StarOffice :) with Windows XP (2009/2010) and these problems didn't exist.

There are lots of other problems related with object copying, some I can't reproduce: font formatting loss, numbered items, tables (which are the real nightmares of LibreOffice), and many others I can't recall.
Such problems are not exclusive of Impress and Writer have some of them (and their own).

Regards
Comment 6 Matthew Francis 2015-04-09 12:56:32 UTC
On LO 3.3.0 there is an extremely slight displacement when pasting.
By the start of the 43all bibisect repository (~3.5.0) the displacement is noticeable.

So on balance let's call this a regression, although it's not one we can easily identify the source of.
Comment 7 MarjaE 2015-09-12 00:22:29 UTC
In 5.0.1.2 it can end up halfway across the page, requiring users to scroll to find it.
Comment 8 MarjaE 2015-09-12 00:23:49 UTC
(In reply to MarjaE from comment #7)
> In 5.0.1.2 it can end up halfway across the page, requiring users to scroll
> to find it.

Whoops. I was thinking of how this bug behaves in Draw, not Impress.
Comment 9 Cor Nouws 2015-12-02 12:42:44 UTC
Mind that bug 94319 is specific about lines and object with lines. That is a regression after version 4.4.5.2 (see comment 7 there).
Comment 10 Cor Nouws 2015-12-02 12:46:01 UTC
(In reply to Matthew Francis from comment #6)
> On LO 3.3.0 there is an extremely slight displacement when pasting.

There has been some time that pasted objects were displaced by the line thickness.
Has been resolved.. See bug 45260.
Comment 11 Robinson Tryon (qubit) 2015-12-14 05:40:06 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2017-01-03 19:48:03 UTC Comment hidden (obsolete)
Comment 13 Luiz Gonçalves 2017-01-03 22:08:45 UTC
THE *BUG* IS STILL THERE.

It seems that every behavior described before by me and by the other colleagues persists. 

Copying from the same opened file (same errors from copying from another copy of the file). The observed behavior is usually random: copies of grouped objects or simple objects (with or wo lines)  
1) Sometimes, a small displacement by one line thickness
2) Sometimes, no displacement at all  
3) Sometimes, a not-so-small displacement 
4) Sometimes, after using Impress for a long time (multiple file opening and closing), fonts and colors begin to change.
5) Copying and pasting tables can be included in another separate bug due to the richness of behaviors. :)

Tested version: 
Version: 5.2.3.3
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
OS Version: Linux 4.4 (Xubuntu 14.04) 
Locale: en-US (en_US.UTF-8)

Although the results are quite random, it seems that there was a little improvement over the last versions. This time I tested using the built in standard units of LibreOffice (inches). *** The final result is regardless of the used units. ***

As pointed out by MarjaE, this *bug* appears also in Draw, I've tested by my own.

Still.... 
**** The expected behavior of a copy is to preserve recursively the attributes of the original object: origins, sizes, etc.  *****
Comment 14 Thomas Woltjer 2017-02-13 15:00:13 UTC
This bug still exists in 5.3.0.3 on Manjaro.
Comment 15 QA Administrators 2018-02-14 03:37:07 UTC Comment hidden (obsolete)
Comment 16 Cor Nouws 2019-02-16 16:41:57 UTC
Created attachment 149330 [details]
test presentation with shape / group - orig and copied/pasted ones
Comment 17 Cor Nouws 2019-02-16 16:42:23 UTC
So this issue is resolved.
Comment 18 Cor Nouws 2019-02-16 16:42:55 UTC
sorry; tested in Version: 6.3.0.0.alpha0+
Build ID: aa31976c2e4399a86bc6f70f140972d9ccef6fc0
CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-02-12_16:47:45
Locale: nl-NL (nl_NL.UTF-8); UI-Language: en-US
Calc: threaded
Comment 19 Luiz Gonçalves 2019-02-19 12:08:18 UTC
Just to give some feedback:

- Version: 5.2.3.3
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
CPU Threads: 4; OS Version: Linux 4.4 (Ubuntu 14.04:, LO updated from canonical in the last few days)
> The problem seems to not exist anymore (possibly due to the update)

- Version: Version: 6.1.5.2
Build ID: 6.1.5-2
CPU threads: 1; OS: Linux 4.20 (Archlinux 4.20.10)
> The problem seems to not exist

Also the problem looks like to have disappeared from Draw.

tnx to you all for the good work.
Comment 20 Cor Nouws 2019-02-19 13:41:52 UTC
thanks for confirming Luiz!
Comment 21 José Trujillo 2021-11-29 18:06:40 UTC
This bug still exists in 7.2.2.2 on Debian 11