Libre-Writer: unexpected reaction to copy an image Description: I included a screen-image in a document, paste (ctrl-v) then manipulated it: 'crop' image to remove overhead, at end of this work i saved the document, i wanted to reuse the cropped-image into an email and MSword, -for that i used copy (ctrl-c) and paste (ctrl-v) Unexpected beaviour SINCE: with AND MSword AND thunderbird the paste inserted the UNCROPPED image instead of the manipulated (crop) image WorkAround - select the cropped-image select: save the image - choice save-manipulated-version in thunderbird AND MSword - use the option: insert image from file note: in most programs commands ctrl-c and ctrl-v act the same way, ctrl-c copies te WYSWYG image note: "help" refers to usage of "ALT"button to copy images to another document, that method does not work for this manipulation, Improvement might be that the operation "select" -> "copy" opens a warning/option box to choice between 'original' - 'mainpulated' as is done withe theh save to file option. sincerely yous wim
comment by simonswim, to avoid changes in the menu -i assume that a choice between: -copy-original <-> copy-processed is fixed for a user, -it is contraproductive to add a selection in repeatedly used commands -thus one workaround/method can be to handle this via a user-related setting in the options . . . .
I confirm it with Version: 7.2.0.0.alpha0+ (x64) Build ID: 9f9798f07f0b56ae474f31ded671cc8da598d244 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded Steps to reproduce 1. Insert an image in a document 2. crop image (context menu of image => crop) 3. Copy image 4. Open thunderbird an paste image Actual result: Pasted image is uncropped. I agree with expected result from comment 0, but I'm not sure about it => Design-Team for further input and decision
Expectation is to take the image including styling attributes such as crop. The image must not be changed but the crop parameter applied so uncroping would be possible.
@heiko.tietze, the reported issue was that with LibreOff- when using copy (ctrl+c) the copied image included all attributes AND the image had its original format (eg the cropping was not applied. in my humble opinion, the standard expectation when using the copy is that one copies what you see AND nothing more, BECAUSE the user/author of a document/email intentionly removed info that the destination/reader should not see AND even should not be able to recuperate, bij doing some experiments I found that: -A- when copyinng an image across platforms (software. . . ) only the visible info/pat was retained - the remainder is removed. -B- in contrary the copy of image from one MSword doc to another did retain all attributes <-- EVEN this is not intended the better approach is that in the copy-paste nvironment the basis operaton is - remove all modification and only keep the WYS part, if needed one should have at the "copy" command an option to retain the attributes eg in MSword there is a paste-options menu
Sorry, should have read more carefully. Cropping is not finalized unless the document is compacted (Minimize Presentation in Impress, requested for Writer in bug 82951). Don't think the confirmation box on copy is accepted by the majority of users since you typically copy for one position to another and want to keep the cropping as it is. So let's make it a duplicate to raise the importance of the other report. Feel free to reopen if you disagree. Besides, this image manipulation could perhaps also be done with an extension. *** This bug has been marked as a duplicate of bug 82951 ***
@heiko tietze, added comment, about the functionalities, -concern-1 security & privacy after further evaluation in my opinion whatever solution should automatcally restrict the copy of an image to WYSWYG as a requirement, i understand that this does mean ELEMINATE attributes rational: in 99% of cases - users that did modify an imgae (crop or compress or . . . ) do intentionly remove the not-visible content compare this operation with usage of image-processing software, - then one uses a step/step method such that: -- in each step you manipulate the image with ability to evaluatie/undo the effect untill one is happy, -- then we hit the "save" image button, NO way back the intention for 82951 was to reduce the total size of the document, so after the manipulation the image is WYSWYG from the comment by dieter i do understand that 82951 is not solved, - looking forward for the enhancement - wim
(In reply to Dieter from comment #2) > I confirm it with > > Version: 7.2.0.0.alpha0+ (x64) > Build ID: 9f9798f07f0b56ae474f31ded671cc8da598d244 > CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: > win > Locale: de-DE (de_DE); UI: en-GB > Calc: threaded > > Steps to reproduce > 1. Insert an image in a document > 2. crop image (context menu of image => crop) > 3. Copy image > 4. Open thunderbird an paste image > > Actual result: > Pasted image is uncropped. > > I agree with expected result from comment 0, but I'm not sure about it > => Design-Team for further input and decision at dieter by wim -concern-1 security & privacy after further evaluation in my opinion whatever solution should automatcally restrict the copy of an image to WYSWYG as a requirement, i understand that this does mean ELEMINATE attributes rational: in 99% of cases - users that did modify an imgae (crop or compress or . . . ) do intentionly remove the not-visible content compare this operation with usage of image-processing software, - then one uses a step/step method such that: -- in each step you manipulate the image with ability to evaluatie/undo the effect untill one is happy, -- then we hit the "save" image button, NO way back the intention for 82951 was to reduce the total size of the document, so after the manipulation the image is WYSWYG from the comment by dieter i do understand that 82951 is not solved, - looking forward for the enhancement - wim
Admittedly it's how MSO works, the cut image is copied instead of the original. The point is that you have to decide on copy not paste what goes into the clipboard. Otherwise the target application needs to decide, and that's not the fact. It would be quite disturbing to request a decision once you copy something (even when only applied to modified graphics). What I could imagine is the "compact" function, if you think it makes sense to separate this from other properties let's keep this ticket (the more people on CC or duplicates the more attractive is a topic). UI wise I would search at the image properties dialog for a function "Compact" that finalizes the current modifications (crop, rotation, scaling). It clashes with linked images and should be disabled in this case.
I think a better solution would be a new "Copy modified image" function under "Copy" in the context menu and in the Edit menu. This would be a significantly more convenient alternative to the following workflow: Right-click > Save... > Yes (to save modified version and not original) > filename + location > Default settings > insert saved file into other app