Created attachment 91755 [details] Test case Problem description: Selecting an object that is grid aligned, copying it (CTRL+C) and pasting it (CTRL+V) returns an object that is not anymore aligned to the grid. This makes it compulsory to realign objects to the grid at every copy and paste operation. The issue is seen on 4.2.0 RC1 and did not exist in 4.1.4.2, so it is a regression Steps to reproduce: 1. Open attached document 2. See that the position of the single line in the drawing is X=10cm, y=4,8cm 3. Select the line and copy it to the clipboard 4. Paste from the clipboard 5. See that the position of the pasted line is X=10.01cm, Y=4.81cm Current behavior: The pasted object is off-grid even if the copyed object was on grid Expected behavior: The pasted object should be on-grid. Namely at X=10cm, Y=4.8cm. Operating System: Ubuntu Version: 4.2.0.2 rc Last worked in: 4.1.4.2 release
Hello Sergio, I reproduce using LO 4.3.0.0.alpha0+ Build ID: b1ac01de06262bda39be7f970fbceeda9b267fe4 TinderBox: Win-x86@42, Branch:master, Time: 2013-12-15_08:41:01 Works with LO 4.1.4.2 OS: Windows 7 Home Premium Kind regards, Jacques
Thanks for confirming on the 4.3 branch. I've just tested the RC2 of 4.2.0 and the bug is here too. Seems to be triggered by graphical objects with non-null line width.
Still present in 4.2.0RC3. So I guess it will be in 4.2.0 when it gets released. Can it be considered for fixing in 4.2.1? This regression really makes drawing very inconvenient wrt 4.1.x. When repetitive elements exist (like in diagrams, circuits, etc.) every time one replicates an object what used to be as simple as CTRL+C, CTRL+V, arrows keys to position the object now becomes CTRL+C, CTRL+V, arrows keys to approximately position the object, RIGHT click + position and size, remove decimals from X, Y position, click on OK and takes 10 times longer. Incidentally: it is the 2nd time that this regression happens. It first happened going from 3.4 to 3.5 (and got fixed in 3.6.2). See bug 44990.
Still present in LibO 4.2.2 RC 1. Please, try to have it fixed before 4.1 goes EOL. This makes drawing with non-null line widths a big pain. Also note: This bug was first introduced in 3.5.0 -> fixed in 3.6.2.2 Reintroduced in 4.2.0 Maybe same fix that went in 3.6.2.2 can still apply.
Works again as expected. Win 7 64-bit 4.3.3.2 and Version: 4.4.0.0.alpha1+ Build ID: b7d8a58ff2698ffc6e22943f64aa97c5ea253bd9 TinderBox: Win-x86@42, Branch:master, Time: 2014-11-05_00:40:38
Migrating Whiteboard tags to Keywords: (possibleRegression) [NinjaEdit]
Regression confirmed in comment #1. Removed bug 44990 from summary because it was never independently confirmed. Best regards. JBF