[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 #71 from Tomaz Vajngerl <quikee at gmail.com> ---
(In reply to Luke from comment #70)
> 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. 

Yes, but you can't guarantee that when you hit save it is the end of the
workflow. I hit save all the time and I'm not the only one.

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

This is all about the workflow. I'm demonstrating that it is not guaranteed
save time is the end of the workflow and that there are scenarios where you
could end up ruining your picture (by mistake lowering the DPI more than you
wanted). 

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

If image is more than 220 DPI what do you think Word does with the image when
you hit save? 

It takes the original, shrinks the image down to the 220DPI (by default) and
compresses again (with JPEG). What q setting does it use? What interpolation
algorithm does it use to shrink down? Who knows...

Everything else what you said Word (actually MSO as this is true for the whole
suite) doesn't do we don't plan to do either. All this has been from the
beginning a talk to resize and recompress when the image has a DPI larger than
X (by default 300DPI + some margin), but instead of constantly doing it at save
with not showing the final result until the next time the user opens the
document, we want to do it one time at insert and show it right away. 

If you will disable image compression - the per document setting - LO won't do
any destructive edits on insert too, and revert the images to original size (if
still in the original session).

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

OMG .. we don't want to recompress every image - only massive images. Again ..
save time is not the end of the workflow.

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

It is, but you see the result of the compression. Inserting image and hitting
save without showing the compressed image instead - how is that not silently
compressing?

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

Me too... even more than you.

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

Who cares. As long as the result of the compression is not visible and we end
up with smaller documents. That's all about. For those who care - turn it off
and trigger it manually at the end.

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

Again describing the professional workflow. That's not the concern of most
users.

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

That's what we plan to add too, in addition to the automatic insert time
compression of massive images.

-- 
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/80a49ea9/attachment.html>