https://bugs.documentfoundation.org/show_bug.cgi?id=139398
--- Comment #7 from simons...@belgacom.net ---
(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
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
