Hi Marja,

Please try to give files with shapes to reproduce. If not: thanks for the effort, but it's not possible to fix anything, and we have to close as invalid.

Hope you understand.
Thanks - Cor

Created attachment 118812 [details]
One Document.

I'm not sure why you're asking for a sample document. Doesn't this affect *every* draw document?

After some more experimentation, it seems to be predictable, though still maddening.

If I copy and paste in affected files, the pasted object is placed about 50% farther from the upper left corner than the original object, and in the same direction as the original object.

If I copy and past in some other files, the pasted object is placed directly on top of the original object.

If I paste objects from an affected file into a new file, and then copy and paste them again, they are moved away from the upper left corner, as I  described. If I paste objects from an unaffected file into that same file, and then copy and paste them again, they are placed directly atop the original.

In theory, if I recreated every single object from scratch, I might be able to work around this problem. But I'd rather have each object just behave normally.

(In reply to MarjaE from comment #2)

> I'm not sure why you're asking for a sample document. Doesn't this affect
> *every* draw document?

Could be. Anyway, QA loves sample documents and useful descriptions as you've given in comment 3 ad 4 :) Thanks!
Will look at it.

Created attachment 118823 [details]
test file analysing the problem

Hi Marja,

Please take a look at my file.
Do you think that it's correct to state that this is a problem with C&P of lines (and grouped object with lines inside)?

No problem in 4.4.5.2, so a regression.

(In reply to Cor Nouws from comment #6)
> Created attachment 118823 [details]
> test file analysing the problem
> 
> Hi Marja,
> 
> Please take a look at my file.
> Do you think that it's correct to state that this is a problem with C&P of
> lines (and grouped object with lines inside)?

Looks like it. Thank you. They aren't moving as far on your sample as they were on mine.

Still reproducible. Both Draw and Impress.

Created attachment 120597 [details]
Impress document to demonstrate the copy bug

I also observed the same bug in Impress and add this odp-document as another sample for completeness. All objects containing lines don't preserve their position after copy. But I didn't find any rules or the offset.

*** Bug 95833 has been marked as a duplicate of this bug. ***

See https://bugs.documentfoundation.org/show_bug.cgi?id=95833#c2

"However, I am possibly hitting the worst possible case of it, with objects getting pasted outside the drawing page and needing zoom out to realize that they got pasted."

I've hit this same bug too. It appears new as of 5.0.3.2, I was previously using a slightly earlier 5.0 release and doing lots of copy/paste and didn't observe it.

For me the pastes can appear wildly away from the current view, outside of the slide boundaries.

This seems to have begun at the below commit.
Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one? Thanks
 4a101ce68b02931a5486f32d1eb7acddbd13268d is the first bad commit
commit 4a101ce68b02931a5486f32d1eb7acddbd13268d
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Wed Jul 29 15:44:27 2015 -0700

    source d1046e7c3f66e5f3384ee1ef534ef28346702fc6

    source d1046e7c3f66e5f3384ee1ef534ef28346702fc6
	
	author	Caolán McNamara <caolanm@redhat.com>	2015-07-15 09:10:25 (GMT)
committer	Caolán McNamara <caolanm@redhat.com>	2015-07-15 12:11:14 (GMT)
commit d1046e7c3f66e5f3384ee1ef534ef28346702fc6 (patch)
Resolves: tdf#63955 clip 19km long line to some sane limit

bibisect-win32-5.1
$ git bisect log
# bad: [a2ca6bb70db1ba8f306a617d92070351d9a3a624] source 8b5182155b6d35a1be64d37136584e30ea6a6ef8
# good: [c1efd324c6ad448ac9edb030dc9738b9e6899e4d] source ab465b90f6c6da5595393a0ba73f33a1e71a2b65
git bisect start 'a2ca6bb70db1ba8f306a617d92070351d9a3a624' 'c1efd324c6ad448ac9edb030dc9738b9e6899e4d'
# skip: [1e602523875e23a7969d8c28276c82311eb2fa74] source 5b8e4f3d676eb0a026ce1eb4c1df2ec6e0736cb1
git bisect skip 1e602523875e23a7969d8c28276c82311eb2fa74
# good: [a83f3c3be6878a0416e48547e2ee1b40d616953f] source aad27e89564752a2bee3da4558f4d276685ba50a
git bisect good a83f3c3be6878a0416e48547e2ee1b40d616953f
# skip: [55284040623ccb6b13d6254613f004becae9cff3] source bd53697bab53d46df952eeb23b609c59adc330cc
git bisect skip 55284040623ccb6b13d6254613f004becae9cff3
# bad: [73fc8ee73c1c2ee0e85d4ba4f8059c64e6a7a69f] source 8cb1f9ac1ce90b324307711f752591a1acc9a6df
git bisect bad 73fc8ee73c1c2ee0e85d4ba4f8059c64e6a7a69f
# bad: [9a440205724ddea0a246ff448dd2b8ecb2a4fad9] source c3a06bcac6536ccfcc49949492c98bfd82c68b52
git bisect bad 9a440205724ddea0a246ff448dd2b8ecb2a4fad9
# good: [5216590be93db937d9d6f5559d36dfad2b5856da] source 67941bd098dc8080c3381cf91aec12492656817e
git bisect good 5216590be93db937d9d6f5559d36dfad2b5856da
# good: [57f95b66c1608d57583558d48c922e9f0375f869] source 6793eaa4fa77292b23e9b86221e598f438d45b8e
git bisect good 57f95b66c1608d57583558d48c922e9f0375f869
# bad: [a3cbd1cecd6cb9bdc1dde91e5683636e6a517883] source 4ca2cf1b7e57c823e911bcbae0c87102a7c9851e
git bisect bad a3cbd1cecd6cb9bdc1dde91e5683636e6a517883
# good: [53cb97f01e82e20f0f444354ba7e65c878dfe424] source 7cedeaeba79bdd54b3bcbadb21c51cc535cf4a5d
git bisect good 53cb97f01e82e20f0f444354ba7e65c878dfe424
# good: [e413c6cb75514c79bdbab5b8309dfd376f6fb16f] source 2f0d1a23759c1b973593bfba642d01fb3df3c269
git bisect good e413c6cb75514c79bdbab5b8309dfd376f6fb16f
# good: [1b7a7177963a9ca57409400b74cd69cd8cd32f73] source adfa89b5ffc3589b3a19a32e707a134cee232429
git bisect good 1b7a7177963a9ca57409400b74cd69cd8cd32f73
# bad: [0b898e7eebdd3e09fb176feb3fdd5dc7febeb2c2] source d6790de07ff225f9e5b58152d01719e5fbe9e6cd
git bisect bad 0b898e7eebdd3e09fb176feb3fdd5dc7febeb2c2
# bad: [5f2b324761d1b07e78adc269f2fb796b1e3066d4] source 0789a1f8d62c2d9859f41473459252e706426c3a
git bisect bad 5f2b324761d1b07e78adc269f2fb796b1e3066d4
# bad: [4a101ce68b02931a5486f32d1eb7acddbd13268d] source d1046e7c3f66e5f3384ee1ef534ef28346702fc6
git bisect bad 4a101ce68b02931a5486f32d1eb7acddbd13268d
# good: [31dd6c7fd2ee1ca25bb254d1ce18faf879d999b1] source dffb58131f06fbe1aaeaa7b0d3ebe049d8384593
git bisect good 31dd6c7fd2ee1ca25bb254d1ce18faf879d999b1
# good: [01408893ffc11fbee6cd90dcc2e6d2ab679b4141] source 536051f8862203e0e115a5394a6379acd83cc8fe
git bisect good 01408893ffc11fbee6cd90dcc2e6d2ab679b4141
# first bad commit: [4a101ce68b02931a5486f32d1eb7acddbd13268d] source d1046e7c3f66e5f3384ee1ef534ef28346702fc6

Bonjour,

I have the same problem and because of that I loose much time (creating music scores ...).
Pasting a text zone is OK: the text is pasted just on the copied text and so easy to move horizntally or vertically. But, for example, a line seems to be pasted anywhere, sometimes even out of the page (!!), this is aberrant. There is no reason to paste an element anywhere else than to the position of the copied element.
There is no need for an example file, this is systematic.

And an element copied in one page must be pasted at the same position in another page.

I use LO 4.4.7.2 with Mageia Linux.

Pierre

Bonjour,

I have the same problem and because of that I loose much time (creating music scores ...).
Pasting a text zone is OK: the text is pasted just on the copied text and so easy to move horizontally or vertically. But, for example, a line seems to be pasted anywhere, sometimes even out of the page (!!), this is aberrant. There is no reason to paste an element anywhere else than to the position of the copied element.
There is no need for an example file, this is systematic.

And an element copied in one page must be pasted at the same position in another page.

I use LO 4.4.7.2 with Mageia Linux.

Pierre

NOT reproduced with:
- Version: 4.4.5.1
Build ID: 1b6df295803ea040dab1b48b5424da8d78d94cf0
Locale : fr_FR

Reproduced with:
- Version: 5.0.1.2
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale : fr-FR (fr_FR)

NOT reproduced with:
- Version: 5.3.4.2 (x64)
Build ID: f82d347ccc0be322489bf7da61d7e4ad13fe2ff3
Threads CPU : 4; Version de l'OS :Windows 6.1; UI Render : par défaut; Moteur de mise en page : nouveau; 
Locale : fr-FR (fr_FR); Calc: group

==> works for me

Still present in 5.4.0

Created attachment 134948 [details]
Test case

Copy and paste arrow. At paste it appears at a position that is no more on grid.

Sorry, but I cannot reproduce the bug. My procedure:
- open attachment 134948 [details]
- clic on arrow
- Ctrl+C, Ctrl+V
I get two arrows exactly on the same place. My configuration:
Version: 5.4.0.3
Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c
Threads CPU : 4; OS : Windows 6.1; UI Render : par défaut; 
Locale : fr-FR (fr_FR); Calc: CL

@sergio: Could you detail your procedure?

Arrow is at 49,28 mm (top left corner)

Copy, Paste

Copy of arrow is at 48,95, 28.05 mm

On 5.4.0.3 (from LibO DEB repo), Kubuntu Linux, LibO with KDE integration.

The fact that this issue is so erratic IMHO makes it even worse.

Ideally, objects should be pasted either in their original position or one grid step away from them (in case you want to make it more evident that a copy has been taken, to avoid users remaining with multiple copies of the same object stacked one onto the other).

The test case now almost works form me in LO 5.4.0.3 (32-Bit-Version, Build-ID: 92c2794a7c181ba4c1c5053618179937228ed1fb) on Windows 7, 64bit, Intel System. The original arrow is at 4.9/1.8 cm, the copy at 4.9/1.81 cm.

But for grouped objects there is still a big displacement after copy pase (See following sample document). Left object: 6.34/8.85 -> 6.34/8.44 cm, right object: 15.54/8.04 -> 15.65/8.04 cm.

Created attachment 135013 [details]
Demo document fpr copy paste dosplacement of grouped objects

When I test attachment 118823 [details]  (from comment #6) it's obvious that there are only minor displacements in some situations, as bellgardt showed too.

This issue was about real huge wrong positions with lines/grouped objects.

So IMO we should close this issue as works for me, and open a new one with one or two test cases for the current problems.

If you need grid aligment, it does not really matter if the skew is 0.1 mm or 20 cm. You'll need anyway to open a dialog and enter an on-grid position manually. For every paste action. Incidentally, whenever you build a diagram with connectors, you need accurate grid alignment otherwise the connectors will appear skewed. Hence, this issue is causing a degradation of the user experience for one significant usage case, drawings of diagrams using connectors, for which blocks are typically copied and pasted many times.

In any case, it is definitely an option to open a new bug, possibly with a standard rather than major priority. Something like "copy+paste breaks objects alignment to grid requiring manual position editing".

(In reply to sergio.callegari from comment #26)
> If you need grid aligment, it does not really matter if the skew is 0.1 mm
For such application I would suggest Duplicate (Shift+F3) functionality: copies are placed as expected.

On the Mac, it's Command-D. Shift-Fn-F3 is a contortion and isn't compatible with the Mac's version of Sticky Keys.

No, really, it would be a weird flow...

Say you are building a diagram and you have like 5-7 different types of blocks and that altogether your diagram will include 30-100 blocks. The usual flow is to take them off a gallery and align them to the grid (because objects cannot be taken out of the gallery ready aligned to the grid) to then move them off the work area. Then you start building your diagram, copying the blocks you need where you think you need them and adjusting their positions with the arrow keys, so that they stay on grid until the result is visually pleasant.

Opening the duplicate dialog and editing it, in place of a CTRL-C, CTRL-V, some arrow key presses would be an overkill. Particularly if you need to place 100 objects overall from a set of 5-7 in positions you cannot exactly forecast in advance.

Incidentally, the 100 objects is the reason why having to re-adjust their position manually one by one is a big burden.

Now, all this is not unusual for those using LibO to design flowcharts (there are many galleries and templates of blocks, for it), or circuits (same) or logic circuits (same), etc.

(In reply to QA Administrators from comment #31)
I tested the sample documents again using LO Version: 6.1.2.1
Build-ID: 65905a128db06ba48db947242809d14d3f9a93fe
CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; 

Now several samples works for me. The test cases "One Document" and "test file ..." don't show any replacements after copy.

In "Impress document..." only the lowest object at the right side shows a  replacement from 15.1/13.52 to 14.99/13.51. 
"Test case" (demo.odg) has a replacement from 5.25/3.25 to 5.25/3.26. 
If the copied object is copied and inserted again, there a further replacements by 0.01 in x- or y-direction.  Is it by rounding errors? In any case I don't think is serious.

In "Demo doc...." (CopyPositionBug2.odp) the upper right object is moved from 12.24/3.64 to 12.31/3.64 and the lower left object from 5.34/8.85 to 6.34/8.45. The replace remains similar after pasted objects are copied and pasted again. In my opinion these big replacements are still bugs.

Bug not reproducible in version 6.3.0.0.alpha0+ (x64)

Problem description: 
Copy-Paste displacement

Steps to reproduce:
1. Open "demo.odg" file from the attachment "Test case"
2. Copy the image
3. Paste

Current behavior:
The pasted image is exactly on the top of the original image.(No displacement)

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
Locale: zh-TW (zh_TW); UI-Language: en-US
Calc: threaded

OS:Windows 10 Pro. 64-bit x64

(In reply to Lun from comment #33)
> Bug not reproducible in version 6.3.0.0.alpha0+ (x64)
 Where can I get this version? On the server I only find 6.2-

(In reply to bellgardt from comment #34)
> (In reply to Lun from comment #33)
> > Bug not reproducible in version 6.3.0.0.alpha0+ (x64)
>  Where can I get this version? On the server I only find 6.2-

https://dev-builds.libreoffice.org/daily/master/

*** Bug 153225 has been marked as a duplicate of this bug. ***

Bug 63955 comment 8 / bug 63955 comment 19 regarding the commit causing the problem:

Armin Le Grand 2018-02-22 17:33:56 UTC
Oh man, why was this fixed *in the primitive creation* ? Prinitive creation should always represent the 'truth' about the geometry. If decomposition takes too long, the fix should be where it gets decomposed. Each decomposition implementation at the primitive level *has* ViewInformation exactly for that purpose (!)
Did I mention that for dashed lines when *clipping* against *something* the dash *will move* and not be the same as when started from the line's start ???

Armin Le Grand 2018-02-22 17:36:49 UTC
The fix also does not prevent a 18km long line be feeded to rendering from other sources, only one source is elliminated. That's why it should be fixed where it gets visualized/discretisized.

*** Bug 127424 has been marked as a duplicate of this bug. ***

Created attachment 185204 [details]
Reproducible copy paste test file

I use draw a lot, and I meet with this problem multiple times every day.
I am submitting a reproducible test file, which I originally submitted in bug 153225.

Steps to Reproduce:
In the attached document, select all objects, then copy and paste (Ctrl-A, Ctrl-C, Ctrl-V): you will see that the pasted objects appear in a different position instead of appearing in the same position as the original ones.

Actual Results:
the pasted objects appear in a different position instead of appearing in the same position as the original ones

Expected Results:
the pasted objects should appear in the same position as the original ones.

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f87ea14edfe3053e3091731deb90fc87c17ddad4

Related: tdf#94319 Revert "tdf#63956 clip 19km long line to some sane limit"

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4f45d7bb863a991e70adcea4848377a3c65f7194

Related: tdf#94319 object pasted in draw/impress is always centered

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

As far as I can tell the very original problem, the regression, isn't a issue in the current version. I've reverted the sequence of clip attempts anyway.

The specific sub case in comment #47 is still an issue, but exists since OpenOffice AFAICS (will overlap the original on copy and paste if there is no text in the line, the snap rect only considers the line, not the text in the line I think is the issue there).

Very recently we began pasting to the middle of the page, that is since Jan this year and is now fixed, that issue didn't appear in a release, just dev version.

Seeing as the general case is fixed I'll close this bug, remaining issues can be filed as new bugs if necessary.