Description: Exporting a LibreOffice document (in my case, Writer) that is rich in images to a PDF generally works well. However, there is a need to be able to produce small file sizes, as Adobe Acrobat does when requested. Example 1: One file creates a PDF of size 39.8 Mb using the lossless options on export-to-PDF. With 80% quality and image reduction to 300dpi, it creates a PDF of size 16.5 Mb. However, running the lossless version through Adobe Acrobat's option "Reduce File Size" creates a PDF of just 3.9 Mb, without visible loss of resolution (on-screen or printed). Example 2: A more extreme example is a 113.0 Mb PDF that Adobe Acrobat reduces to just 5.3 Mb, again without any visible loss of resolution. Note that in both cases, the default settings were used in Adobe Acrobat. Request: I would like to see an option on the PDF export dialogue to achieve a similar reduction. A brief summary of how Adobe Acrobat does this is given here: https://answers.acrobatusers.com/What-s-the-difference-between-Reduce-Size-PDF-and-Optimized-PDF-q107619.aspx I quote (with some editing): "It resamples and compresses images; subset-embeds embedded fonts; compresses document structure; cleans up elements such as invalid bookmarks." I suspect that the image-compression is the most important of these. Thank you Steps to Reproduce: 1. Create a Writer document that is rich in images, especially photographs. Include both JPG and PNG. 2. Export as PDF. Try to shrink the size without visible loss of resolution by playing with the options "JPEG compression" and "Reduce image resolution". Actual Results: The file size is generally within expected values, which is why this is a feature request and not a bug report. Expected Results: If a suitable option is provided, LibreOffice should shrink the file to its minimum size without visible loss in resolution, as the "Reduce File Size" feature of Adobe Acrobat achieves (as described above). When this option is chosen, the options "Lossless", "JPEG Compression" and "Reduce image resolution" would be greyed out and ignored. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 6.4.1.2 Build ID: 4d224e95b98b138af42a64d84056446d09082932 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded I have marked this as the latest release because that's what I currently use, but it predates this release by a long time.
So is your proposal about the assumption that the JPEG compression and DPI reduction settings are too complex for the average user and there should be a simplified additional option?
Did you search for existing bugs? Looks like bug 45168, that one can be improved.
@Buovjaga — No, it's not that. I have experimented with the JPEG compression and DPI settings, and the compression is far from that achieved by Adobe Acrobat. However, it is a good point that you raised: The "average" user wouldn't have much clue in that direction — it might even be that I could achieve the same level of compression if I were more tech savvy. @Timur — Bug 4518 looks similar to this one, but the OP of bug 4518 talks about halving the size, whereas my versions are much less than half. Also, the OP talks about using cropped images, whereas I didn't crop any. So, are the two bugs the same? I'm unsure.
(In reply to Paddy Landau from comment #3) > @Buovjaga — No, it's not that. I have experimented with the JPEG compression > and DPI settings, and the compression is far from that achieved by Adobe > Acrobat. However, it is a good point that you raised: The "average" user > wouldn't have much clue in that direction — it might even be that I could > achieve the same level of compression if I were more tech savvy. Sure, your general request is quite broad. It would be helpful to get to some specifics, like what parameters is Acrobat using in its compression. Image file size can be optimised by various crunching methods, see for example https://pngquant.org/
There are some general rules, like no duplicates and separate reports for separate features. But I also look at reality. We have very old bug with no progress, because no volunteer took it. Least useful is reporting another bug even with slightly different idea, without proper search. I'll mark duplicate. You may study other bug and add some comment - please be minimalistic. Should there be some progress but not all solved, we can always reopen this one. But until then, two broad bugs make no sense. *** This bug has been marked as a duplicate of bug 45168 ***