[Libreoffice-bugs] [Bug 34133] Add ability to automatically compress and resize images

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=34133

--- Comment #70 from Luke <lukebenes at hotmail.com> ---
I get that professionals can and will disable compression here just like they
can with MSO. That has never been my concern. My concern for the past has
always been about the work flow. JP gave 2 advantages which I replied to. As
far as yours, this is my response.

(In reply to Tomaz Vajngerl from comment #63)


> At save is not a good time for compression: 
> Users won't have an idea that compresion will happen and informing them

No one here is asking to inform users. The concern has always been that
destructive edits belong at the very end of the work flow. 

> Users have different habits and use save at different times. Some save
> frequently after every action, so they could insert, resize too much, save
> and then realize the image should be bigger.

This is just an argument for having conservative(high) DPI defaults. This has
nothing to do with save time or insert time compression. 


> could be in a hurry and save, close LO, then after a while open and realize
> the images are compressed and it is not what they want.

This is not a problem in MSO and if it's a problem in LO, we're doing something
wrong. Users do not expect destructive edits to happen without them asking for
it. Word does not crop images, does not resize < 220 dip images, does not
recompress unless the user request that at save. And if the user Checks "Do not
compress images in file" Word does no destructive edits on save. 

This the right way to handle document wide resizing, compression, and cropping. 


> MSO even doesn't show the result after save - as long as you keep the
> document open, it will show the original.


Because MSO doesn’t do destructive edits implicitly (assuming you don't have
massive files). It’s not a normal “save”. To compress your document, You have
to click Save →Tools → Compress Picture. All of these occur at the end of the
work flow, when you can think about your target audience.  

> We don't want to use a workflow that
> silently does compression or potentially could compress to a lower DPI than
> specified.

Most users insert images by dragging and dropping. How is this not silently
compressing? 

Silently compressing and resizing images is what we are all concerned about. 

> Additionally we want the user to have the control and the ability
> to decide on case-by-case basis.

So you want to put the destructive edits at the front of the work flow where
they can happen silently by a drag an drop?  Do you really think anyone knows
the compression level they will need while their still creating the document? 

That's now how it works in the real world. People work with the highest
reasonable quality to create a master. When they are ready to share, they want
to resize/re compress their images to the target file size/output media.

The correct way to implement this feature is with a document minimizer like we
do with Impress.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20170513/7afa7981/attachment-0001.html>