Bug 139398 - IMAGE: Copy and paste a cropped image from LO to Tunderbird or MSWord has uncropped image as result
Summary: IMAGE: Copy and paste a cropped image from LO to Tunderbird or MSWord has unc...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.7.2 release
Hardware: All Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Image-Crop
  Show dependency treegraph
 
Reported: 2021-01-04 11:16 UTC by simonswim
Modified: 2021-02-03 00:38 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description simonswim 2021-01-04 11:16:23 UTC
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 1 simonswim 2021-01-04 14:06:09 UTC
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 . . . .
Comment 2 Dieter 2021-01-19 07:00:16 UTC
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
Comment 3 Heiko Tietze 2021-01-20 16:11:37 UTC
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.
Comment 4 simonswim 2021-01-22 11:16:43 UTC
 	@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
Comment 5 Heiko Tietze 2021-01-26 09:30:43 UTC
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 ***
Comment 6 simonswim 2021-01-26 14:15:03 UTC
@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
Comment 7 simonswim 2021-01-26 14:16:49 UTC
(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
Comment 8 Heiko Tietze 2021-01-26 14:35:24 UTC
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.