When I copy and paste an object, I expect the pasted object to be in the same positionas the original. This, however, is not true if the object's border has a thickness greater than 0. To reproduce: Draw an ellipse, set border thickness e.g. to 1.00 cm, then copy/paste and the pasted object will be pasted with a shift of -0.5cm/-0.5cm. (It's trivial, but this was always one detail why I liked OO/LibO so much more than MS products, so I file it as a minor bug.)
The same behaviour in 3.5.0rc3. Copy/paste moves the pasted object although the snap to grid is ON.
[Reproducible] with "LibreOffice 3.5.2.2 German UI/Locale [Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f] on German WIN7 Home Premium (64bit): 1. open attached "BUGTEST3.odg" 2. Click one of the yellow thick lines 3. <control+x> for cut 4. <control+v> for paste Expected: now line is at the same place as before Actual: for me some mm shifted to left and some mm to top Same in Current 3.6 Master Works fine with 3.4.5, so REGRESSION. [Reproducible] with server-Installation of "LibreOffice 3.5.0 Beta1 - WIN7 Home Premium (64bit) German UI [Build-ID: 7362ca8-b5a8e65-af86909-d471f98-61464c4] Windows_Release_Configuration 11-Dec-2011 06:51" Still worked fine with 3.5.0 Beta0 AFAIR in that area we had the fix for Bug 42227. I have a very vague suspect that the problem might be related to the commit. For some use this might be a minor problem, but for many others (like mine) it makes DRAW unusable, for example if you create complex objects by copy 7 paste / rotate / flip or if you simply want to get the object into a different layer and and and ... @Radek: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Created attachment 60369 [details] Sample Document See Comment 2 how to use!
Version due to research results
We need a fix!
regression against 3.4, needs a bibisect.
(In reply to comment #6) > regression against 3.4, needs a bibisect. Maybe not necessary: according to comment #2, it "worked fine with 3.5.0 Beta0", but according to comment #4 (both by Rainer), 3.5.0 Beta 1 is broken; so the regression must have been introduced with Beta 1.
(In reply to comment #7) > (In reply to comment #6) > > regression against 3.4, needs a bibisect. > > Maybe not necessary: according to comment #2, it "worked fine with 3.5.0 > Beta0", but according to comment #4 (both by Rainer), 3.5.0 Beta 1 is broken; > so the regression must have been introduced with Beta 1. Sorry, forget my comment! I just wanted to emphasize that the range of commits to check can already be narrowed by the relatively short timeframe from beta 0 to beta 1, because I thought that it was easy to miss this little, but important point.
Please never change NEW to NEEDINFO! <https://wiki.documentfoundation.org/QA-FAQ#How_to_use_Status_or_Keyword_NEEDINFO> Again and again I stumble upon bugs where no bugfix progress is coming, seems because developers see NEEDINFO and think no action is required until status is back to NEW (may be because queries are used that sort out NEEDINFO bugs or whatever else). Of course there is some sense in "redirecting" a Bug from the direct bugfixing process to an additional QA loop for bibisect or similar, but before that is common sense, has been announced, added to the manuals and so on this ded-end-street-danger is too big. And BTW, I can reproduce the problem with LibO 3.5.3.2 on Ubuntu Linux 12 My Bibisect knowledge is not very up to date, I alos doubt that we really have Bibisect Versions between 3.5.0Beta0 and Beta1 (where the bug appeared due to Comment2)? It seems <https://wiki.documentfoundation.org/Bibisect> is not up to date concerning available versions? And concerning <http://dev-builds.libreoffice.org/bibisect/>?
@Rainer: NEEDINFO makes a lot of sense when additional info can be provided by non-developers (which is a bigger crowd) to keep devs on the bugs that need direct code manipulation (and we also have enough of those). If you want to metadiscuss this, lets do on the qa mailing list, NOT in the bug. However, I dont think we need to tie down such common sense in documentation -- it will just scare away newcomers. Anyway, 3.5 Beta1 is before 3.5 branchoff, so a bibisect might help as Beta0->Beta1 seems small enough, but its still 696 commits.
38 commits in sd, most related to impress210
giving this one a try...
Odd...the width of the line is lost if an object is copied from draw and pasted to impress....
might be regression of BorderLine changes when BorderLine2 API was introduced. I fixed similar problem recently with http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea923cd424f6426d69a7fb375f5ac9e19ec2246a
*** Bug 51260 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > *** Bug 51260 has been marked as a duplicate of this bug. *** My analyses was simple: the X-pos and Y-pos are reduced with half the line width.
(In reply to comment #14) > might be regression of BorderLine changes when BorderLine2 API was introduced. > I fixed similar problem recently with > http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea923cd424f6426d69a7fb375f5ac9e19ec2246a Look forward to test this. I also noticed that with the export to .png (I did not test others) a line width > 0 results in a different position in the resulting graphic. Did not test this thoroughly by now, but from my head, I think that in that case, the X-pos and Y-pos are increased with half the line width..
*** Bug 51150 has been marked as a duplicate of this bug. ***
Cann't see any NEEDINFO requirement. I was not able to reproduce png observations in Comment 17 with "LibreOffice 3.5.5.2. German UI/Locale [Build-ID: 24b32b4-b87ec2e-85c8e98-87a4e20-9a1b8c1] on German WIN7 Home Premium (64bit)
Debugged this problem: Copy uses BoundRect() http://opengrok.libreoffice.org/xref/core/sd/source/ui/view/sdview2.cxx#133 while Paste uses SnapRect() http://opengrok.libreoffice.org/xref/core/sd/source/ui/view/sdview3.cxx#631 And both have a comment warning it shouldn't be changed to other :( [But, changing one of them to use common Rect() fixes the issue]
Muthu Subramanian committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e647cc9d895005c5bed2fec98c73ca28ccd925ae fdo#45260: Objects having line thickness misplaced while pasting.
Decided to revert the affected commit partially to fix this as http://cgit.freedesktop.org/libreoffice/core/commit/?id=e647cc9d895005c5bed2fec98c73ca28ccd925ae Can somebody verify this, please? Thank you!
Works fine during a quick test with attached sample document (and new DRAW document) and with parallel installation of Master "LOdev " 3.7.0.0.alpha0+ - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 25608fb]" (tinderbox: 2008R2@20, pull time 2012-07-14 00:31:17) Can we get tht for 3.6?
Muthu Subramanian committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c35c4769d8cabe0f01ef9911056d7a9d1d2f4b04&g=libreoffice-3-6 fdo#45260: Objects having line thickness misplaced while pasting. It will be available in LibreOffice 3.6.
[Fridrich helped cherry pick this to 3.6, so it should be available there. Thanks!] Resolving this fixed.
In reaction to the bug hunting session, I have tried the very long term bugs still present in OO/LO. This is one of them. Using the release version 4.2.2.1, this bug appears again! It even does not matter if the border thickness is greater than or equal to zero: - start LO - draw a rectangle - select it - ctrl+c - ctrl-v (the copied object becomes selected) - check position and size (both position coordinates are at 0.01 offset)
Please don't reopen really old bugs that have been closed for a long time as fixed. Instead report a new bug. Thanks
Andras Timar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=de8f5f2af78877bc63b462195ce63341f6ba7817 Revert "fdo#45260: Objects having line thickness misplaced while pasting." The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Andras Timar committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1677cffc602e15968ffb76ee0d5fd0ebcdac6b3c&h=libreoffice-4-2 Revert "fdo#45260: Objects having line thickness misplaced while pasting." It will be available in LibreOffice 4.2.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
OK :)