Stirling-Tools
[Bug]: Compression doesn't work anymore
Installation Method
None
The Problem
Since several versions the tool Compress PDF doesn't work anymore. Now there are more quality degrees (1 to 9) than mentioned in the UI (1 to 4). But despite these settings the resulting PDF has always only a slightly smaller size than the original. Also the automatic mode doesn't work, too.
Version of Stirling-PDF
0.36
Last Working Version of Stirling-PDF
No response
Page Where the Problem Occurred
No response
Docker Configuration
No response
Relevant Log Output
No response
Additional Information
I used the compress PDF tool for many months with very similar PDF files. The original file size was always ~3 MB. With compression setting 2 the resulting file size was typically 280 - 320 kB. Now I get resulting file sizes of ~2,8 MB.
Browsers Affected
Other
No Duplicate of the Issue
- [X] I have verified that there are no existing issues raised related to my problem.
Are you able to provide the docker logs for your compression to help investigate? I have seen it work well with some PDF files, it might be the existing PDF file is already compressed
I provide some data, the docker collapsed, trying to compress an invoice with 36 mbs embedded multilanguage and forcing to create a 2mb pdf collapsed. These support captures:
Logs : with values increased in each phase (151..) 17:32:52.622 [Thread-287] INFO s.s.SPDF.utils.ProcessExecutor - WARNING: /tmp/input_10910280782982895602.pdf: reported number of objects (151) is not one plus the highest object number (149) 17:32:55.829 [Thread-287] INFO s.s.SPDF.utils.ProcessExecutor - qpdf: operation succeeded with warnings; resulting file may have some problems 17:32:55.830 [qtp1179968371-523] INFO s.s.S.c.api.misc.CompressController - Current compression ratio: 16.92 17:32:55.849 [qtp1179968371-523] WARN o.apache.pdfbox.pdmodel.PDDocument - You are overwriting the existing file input_10910280782982895602.pdf, this will produce a corrupted file if you're also reading from it 17:32:55.881 [qtp1179968371-523] INFO s.s.SPDF.utils.ProcessExecutor - Running command: qpdf --normalize-content=y --optimize-images --recompress-flate --compression-level=9 --compress-streams=y --object-streams=generate /tmp/input_10910280782982895602.pdf /tmp/output_12839791714410200731.pdf
I tried running from the command line qpdf with the various parameters being passed and the problem seems to be related to --normalize-content=y; With this parameter a pdf containing only images (I tried Wikipedia homepage) goes from 2 MB to 18 MB, then Stirling does not send it and sends the uncompressed version because it recognizes that it is lighter. Passing this parameter also the value of --compression-level creates no difference, both the version with 1 and the one with 9 have the same size, while without using the parameter --normalize-content=y the size changes
Thanks we will remove this asap for next update
Appreciate your help on this