Bug 83927 - EDITING: Pasted object position still differs from the original one
Summary: EDITING: Pasted object position still differs from the original one
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.3.1.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Paste Shapes
  Show dependency treegraph
 
Reported: 2014-09-16 12:11 UTC by pafal
Modified: 2026-03-26 18:24 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
ODG with various shapes LOv4322 (16.03 KB, application/vnd.oasis.opendocument.graphics)
2014-09-28 06:27 UTC, Owen Genat (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pafal 2014-09-16 12:11:12 UTC
The issue reported in bug 78413 persists for any other shapes (looks like it has been fixed for rectangle only).

- draw a shape (other than rectangle)
- select it
- ctrl+c
- ctrl-v (the copied object becomes selected)
- check position and size (both position coordinates are at 0.01 offset)

Trying the daily build (libo-43~2014-09-16_08.54.36_LibreOfficeDev_4.3.3.0.0_Win_x86.msi) and the reported bahavior is not reproducible. Might this depend on any settings?
Comment 1 Owen Genat (retired) 2014-09-28 06:27:54 UTC
Created attachment 106981 [details]
ODG with various shapes LOv4322

(In reply to comment #0)
> Might this depend on any settings?

The various snap-to-grid options would likely be influential. You will need to ensure these are turned off before testing.

(In reply to comment #0)
> - check position and size (both position coordinates are at 0.01 offset)

Please indicate the units being used. Unable to reproduce under GNU/Linux using v4.3.2.2 in the attached example, for the default centimetre unit.
Comment 2 Owen Genat (retired) 2014-09-29 00:20:54 UTC
As a result of comment 1, status set to NEEDINFO. Please set back to UNCONFIRMED once the requested information is provided. Thanks.
Comment 3 pafal 2015-02-20 10:10:43 UTC
- Using millimeters as the main units, but centimeters behave the same.
- Testing snap to grid and grid granularity, no influence on the offset.

Opening the attached "ODG with various shapes LOv4322" in OO 4.4.1.1 on Win7 64 bit and using following steps:

- select (click) the shape, 
- ctrl-c, 
- ctrl-v, 
- check the position of the pasted one (expecting the exact same position and size as the original)

1) Rectangle: *same as the original*
2) Circle   : x+0.01 mm, y+0.01 mm
3) Cylinder : x+0.01 mm, y+0.01 mm
4) Heart    : x+0.01 mm (y unchanged!)
5) LArrow   : x+0.01 mm, y+0.01 mm
6) Flag     : x+0.01 mm, y+0.01 mm
7) Bubble   : x+0.01 mm, y+5.43 mm (WTF?)
8) Star     : x+0.01 mm, y+0.01 mm
9) RArrow   : *same as the original*
Comment 4 pafal 2015-02-20 10:53:02 UTC
As this is pretty annoying I have performed following additional steps:

1) Complete wipe of ANY libre/open office traces in system (uninstall, delete program/data directories)
2) Clean instal of LO 4.4.1.1 (msi downloaded from 
   http://dev-builds.libreoffice.org/pre-releases/win/x86/
3) Testing of following shapes in default setup is OK: 
   - rectangle, 
   - ellipse, 
   - heart!. 
   The bubble is weird even in the default setup, it adds 1.03cm to y coordinate.
4) Change settings from default to "my" values (due to localization I would try to guess the original english equivalents):
   - general, measurement units : centimeters -> millimeters
   - grid, main spacing (both)  : 10.00mm     -> 5.00mm
   - grid, aux spacing (both)   : 10          -> 5

This is the setup the described copy/paste behaviour occurs. I'm starting to suspect the code of some wrongly handled floating point arithmetics and rounding problems...

Could you please apply these details and try to reproduce?
Comment 5 Buovjaga 2015-02-25 12:06:17 UTC
Reproduced results from comment 3 on Win & Linux.

Tools - Options - LibreOffice Draw - General - Unit of measurement: Millimeter
In the sidebar, have Position and size visible to immediately see the change.

This isn't major, though (can be correctec manually afterwards), so lowering severity: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

Win 7 Pro 64-bit, LibO Version: 4.4.0.3
Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Locale: fi_FI

Version: 4.5.0.0.alpha0+
Build ID: b13534de022972131b46f93f5ada90af155eec9e
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-02-19_00:21:37
Locale: fi_FI

Ubuntu 14.10 64-bit
Version: 4.4.0.3
Build ID: 40m0(Build:3)
Locale: en_US
Comment 6 MarjaE 2015-09-17 00:30:07 UTC
In LibreOffice 5.0.1.2, it is a pain when something pastes out of view, and you have to scroll around the document, find the object, and drag it back.

For example, if I copy something at 3.7in x 2.9in, it may paste at 5.68in x 4.48 in.
Comment 7 QA Administrators 2016-09-20 10:31:56 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2019-12-03 14:20:58 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2022-09-22 03:55:35 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2024-09-22 03:19:19 UTC Comment hidden (obsolete)
Comment 11 Andreas Heinisch 2026-03-26 17:19:02 UTC
No repro anymore in:
Version: 26.8.0.0.alpha0+ (X86_64)
Build ID: 4436421ec7cf788190faaaee9c215a3899a4dc95
CPU threads: 32; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: CL threaded

Could repro only Bubble (x+0.01 mm, y+5.43 mm) anymore in:
Version: 24.2.0.1 (X86_64) / LibreOffice Community
Build ID: b4d45829793cddfe67b58a53f495528c75738d8a
CPU threads: 32; OS: Windows 10.0 Build 26200; UI render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL threaded