Bug 97993 - EDITING: images and shapes that are successively Copy/Pasted or Pasted should to be shifted
Summary: EDITING: images and shapes that are successively Copy/Pasted or Pasted shoul...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Paste Writer-Images Shapes
  Show dependency treegraph
 
Reported: 2016-02-19 02:40 UTC by Luke
Modified: 2019-08-03 06:23 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Copy/Paste on MS Word (27.61 KB, image/png)
2018-07-20 09:27 UTC, Heiko Tietze
Details
Screenshot of Word vs Writer, same procedure (149.12 KB, image/png)
2018-07-23 03:02 UTC, Luke
Details
WPS Office, same procedure (109.79 KB, image/png)
2018-07-24 04:48 UTC, Luke
Details
Google Docs also does not hide pasted copies (180.93 KB, image/png)
2018-07-25 20:17 UTC, Luke
Details
SoftMaker Office, same procedure (186.38 KB, image/png)
2018-07-25 20:22 UTC, Luke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2016-02-19 02:40:30 UTC
Steps to Reproduce:
1. In Writer, Insert Shape or Image
2. While Shape/Image is still highlighted, CTRL+X then CTRL+V

Expected Results:
1. A copy of your Shape/Image is placed on top of or below and to the right of your original Shape/Image. 
2. The copied object should be selected.

Actual Results:
1. Nothing

Both Calc and Impress, work as expected. I also tested Corel WordPerfect, MS Word, and Kingsoft Writer. They also all behaved as expected.
Comment 1 raal 2016-02-20 19:19:46 UTC
Hello,
ctrl+x is cut not copy.

I can confirm with Steps to Reproduce:
1. In Writer, Insert Shape or Image
2. While Shape/Image is still highlighted, CTRL+C then CTRL+V

Setting to new.
Comment 2 QA Administrators 2017-03-06 15:17:52 UTC Comment hidden (obsolete)
Comment 3 Luke 2017-03-09 23:27:11 UTC
Version: 5.4.0.0.alpha0+
Build ID: 5b805de10a1b05647b616e726f0a8b88ff30ae77

Shapes and images are still placed directly on top of each other after CTRL+C then CTRL+V.
Comment 4 QA Administrators 2018-07-05 02:48:48 UTC Comment hidden (obsolete)
Comment 5 Luke 2018-07-07 18:03:28 UTC
CTRL+C then CTRL+V still behaves unexpectedly with shapes / images.
Version: 6.2.0.0.alpha0+ (x64)
Build ID: e3d42b3fa996f11669933d5d6b393c0d89fb8261


Heiko Tietze,
Is this something the design team could take a look at or be added to 100 paper cuts? We are internally inconsistent here. In addition, any user coming from any other office suite or image editing app would not expect the pasted image to fully obscure the original.
Comment 6 Heiko Tietze 2018-07-20 09:16:51 UTC
There are situations when you want the target exactly where the source was, ie. when you cut/paste (closing the ticket as WFM). In other use cases it's better to apply an offset, of course. Microsoft Word puts the shape on pos 0,0 and applies an offset when there is another shape at this pos (just like windows are arranged on the desktop).

We have the duplication tool in Draw that provides more functionality. But there is no "quick duplication" (bug 100028).
Comment 7 Heiko Tietze 2018-07-20 09:27:34 UTC
Created attachment 143654 [details]
Copy/Paste on MS Word
Comment 8 Luke 2018-07-21 01:52:30 UTC
Heiko,
There is an error in the description instructions. It should read:

2. While Shape/Image is still highlighted, CTRL+C then CTRL+V

Raal realized this which it why it was confirmed. 

If you try to COPY and paste in Word, you will see it's behavior is not the same as writer. But this goes far beyond that. Shifted copy and pasted images/shapes is the default for all Office Suites and all image editing software that I am familiar with.
Comment 9 Regina Henschel 2018-07-22 18:05:10 UTC
(In reply to Luke from comment #8)
> If you try to COPY and paste in Word, you will see it's behavior is not the
> same as writer. But this goes far beyond that. Shifted copy and pasted
> images/shapes is the default for all Office Suites and all image editing
> software that I am familiar with.

In case you paste the clipboard content while an image is selected, I see different behaviors: Word and SoftMaker insert the clipboard as new image at same top-left position, only shifted in case of identical size; Google Docs replaces the selected image with the clipboard content;  Scribus inserts the clipboard as new image at same top-left position, in case source image is selected and does not paste it at all if different image is selected. So LibreOffice behaves same as Google Docs.

SoftMaker has a dedicated command "Duplicate", which copies the image and inserts it shifted. LibreOffice can duplicate the image by using Ctrl+Drag. Perhaps a short-cut for such duplication with a default 'drag' can solve the problem, so that you can easily duplicate an image without using the mouse? Which would be a 'quick-copy' (bug 100028) for Writer?
Comment 10 Luke 2018-07-23 03:02:30 UTC
Created attachment 143702 [details]
Screenshot of Word vs Writer, same procedure

Regina,
I'm not looking for a workaround. The point is that the current copy/paste behavior is confusing to the end user.

I attached a screenshot where I did the exact same procedure of inserting a shape and an image in Word and Writer. Then copy/pasting 8 times. In Writer there is no indication that the copy/pasting was successful or how many and where the pasted images are located. However, Word removes all this ambiguity by stacking them or putting them in a row, depending on the objects wrapping settings.
Comment 11 Heiko Tietze 2018-07-23 08:26:37 UTC
My comment 6 intended to show the different use cases. If we change the copy/paste behavior to having an offset many users may feel this as a regression. And Regina pointed out in comment 9 that there is no standard.

=> still voting for WFM

(In reply to Regina Henschel from comment #9)
> Which would be a 'quick-copy' (bug 100028) for Writer?

It's a copy/paste function with offset working on shapes and images (haven't made a complete list).
Comment 12 Regina Henschel 2018-07-23 09:29:24 UTC
I suggest such special 'quick-copy' as _addition_ to the current behavior for Writer. Bug 100028 is only about Draw/Impress.
Comment 13 Luke 2018-07-24 04:48:24 UTC
Created attachment 143723 [details]
WPS Office, same procedure

Heiko
I understand how you thought that shifting on a cut/paste would confuse the end user. However, that was an error in my instructions, and not what I was asking for. This is about copy/paste.

From a UI design theory perspective, how is it better to give no feedback to the user? When working with shapes, I often make a master shape, then customize each instance. For example when making flowcharts, I will have 5 or 6 master objects that I copy dozens of times. In LO, I have to trust that my copy/pastes are working AND keep track in my head. How is this better than how other systems work? How is hiding each copy better than showing it shifted?

What is the use-case are you imagining where the default behavior in Word, WPS Office, and WordPefect is inferior to Writer's current copy/paste behavior?
Comment 14 Luke 2018-07-25 20:17:37 UTC
Created attachment 143762 [details]
Google Docs also does not hide pasted copies

Only recently did most browsers start supporting HTML5's Clipboard API, even so CTRL+C/CTRL+V does not work for me. Google Docs is in the default "in line" wrapping and you copy/paste with the menu, it behaves exactly the same as Word when "in line", which makes sense as wrapping options should be respected. 

Their Presentation app stacks exactly like the behavior bug report is requesting.
Comment 15 Luke 2018-07-25 20:22:46 UTC
Created attachment 143763 [details]
SoftMaker Office, same procedure

As you can see from the screenshot, the Softmaker Office also shifts duplicated objects. This is the industry standard.
Comment 16 Heiko Tietze 2018-07-26 10:10:28 UTC
How about that:
* Shift the pasted object to down and right if
** the source object is on the same canvas (don't shift in case of cut and when pasting into a different document)
** the source object has not changed its position/size
** no other command was executed
* Shift by an amount of pixels depending on the object size (small vs. large objects) 
* Multiply the shifting by how often the object was copied
Comment 17 Regina Henschel 2018-07-26 10:33:53 UTC
@Heiko: The problem is the case, that the object is still marked, when you use Ctrl+V. In that case the clipboard content is not inserted as new object, but it replaces the marked object. That does not only happen, if you do Ctrl+C and then immediately Ctrl+V, but in other cases where an image is marked too. Therefore my suggestion to implement a "duplicate" feature: Click on image to select it, make "duplicate", and then a slightly shifted copy of the selected image is inserted as new image. Which of the settings of the original image are preserved and how they are handled need to be specified. Especially anchoring and wrapping is a problem.
Comment 18 Heiko Tietze 2018-07-26 10:39:34 UTC
(In reply to Regina Henschel from comment #17)
> @Heiko: The problem is the case, that the object is still marked, when you
> use Ctrl+V. In that case the clipboard content is not inserted as new
> object, but it replaces the marked object....

Evaluating the previous commands independently from what is being selected shouldn't be too hard. And eventually how to realize the feature is up to the devs (with another loop if something is not possible or unclear).
Comment 19 QA Administrators 2019-07-30 03:14:45 UTC Comment hidden (obsolete)
Comment 20 Luke 2019-08-03 00:46:42 UTC
CTRL+C then multiple CTRL+V still behaves unexpectedly with both shapes / images. No user feedback that the command was executed like in Word. 

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 41d3be4a48ea2abe019cd4f9b51bef703a2dc454