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.

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.

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.

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).

Created attachment 143654 [details]
Copy/Paste on MS Word

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.

(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?

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.

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).

I suggest such special 'quick-copy' as _addition_ to the current behavior for Writer. Bug 100028 is only about Draw/Impress.

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?

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.

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.

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

@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.

(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).

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

Dear Luke,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug