Beside the feature described in bug #34133, I would like a complementary feature.
I think that the resolution (DPI) should be kept below a maximum limit at insertion time. Basically you can reasonably assume that the image would possibly not exceed the page dimension. This would keep enough margin in order to later crop or resize the image before exporting with the "minimizer" tool.
At my office, the users are creating a lot of LO Writer documents and they won't use a simple click in order to reduce the size of the document. With a standard page, what should we keep 10 Megapixel images for ?
For example, if you have a 10 Megapixel image (4/3 form factor, 3640 pixels for the big side), it will exceed 300 dpi if you make this image fill a A4 page (21x29,7 cm or 8,3x11,7 inches or 2480x3507 pixels at 300 dpi). Note that the A4 form factor doesn't fit a 4/3 form factor of the image. The difference between those form factors and the maximum number of pixel allowed by the page (user defined maximum resolution) would help to guess the new resolution of the inserted image.
Moreover, if you take into account a 1 cm margin, the area to be fit is 2362x3390 pixels at 300 dpi. This would increases the gap between the resolution of the inserted image and the user defined max dpi.
Maybe this feature could have an option in order to tell if the margins of the page should be taken into account (in addition to the user defined max dpi).
If a user need a part of an image to fit the full page, then he/she would use a specific image processing tool or he/she would disable this feature into the settings dialog.
Once again, wishing you a Merry UXmas, team!
Status -> NEW
We're replacing our use of the 'ux-advise' component with a keyword:
Component -> LibreOffice
Add Keyword: needsUXEval
Closing this ticket and comment on 34133.
*** This bug has been marked as a duplicate of bug 34133 ***
I'm fine with this being an optional feature. But destructive defaults that are on by default is a terrible idea. Let's keep this issue separate until we've had more time to discuss this.
(In reply to Luke from comment #4)
> I'm fine with this being an optional feature. But destructive defaults that
> are on by default is a terrible idea. Let's keep this issue separate until
> we've had more time to discuss this.
What qualifies this ticket to be opened again? Is there an advantage of having two duplicate tickets open?
This bug is asking for a destructive action AT INSERT TIME. However, bug 34133 asks for THE OPTION. Every other Office Suite handles this as an export, publishing time, because the operation is destructive.
A destructive operation cannot be undone. Therefore, it's not **optional**. Even if bug 34133 is “resolved” with this poorly thought out at insert time idea. I would file a new bug report asking for the option to do it at export time, because this feature is not useful for most use cases at insert time.
For example, if I have need to shrink a document to < 5MB to email, I would do the at the end of my work flow. With insert time options, this would not be possible. So bug 34133 wouldn't actually be resolved.
These are 2 totally separate issues.
(In reply to Luke from comment #6)
> Every other Office Suite handles this as an export,
> publishing time, because the operation is destructive.
MS Office doesn't - it automatically compresses on save.
See here description how to turn it OFF (because it is ON by default): https://support.office.com/en-us/article/Turn-off-picture-compression-81a6b603-0266-4451-b08e-fc1bf58da658
We talked about this topic in the design meeting Apr/27 2017 and agreed on the idea. Removing needsUX.