[
https://issues.apache.org/jira/browse/PDFBOX-3982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16223961#comment-16223961
]
Tilman Hausherr commented on PDFBOX-3982:
-----------------------------------------
Why would a global system property not be a nice solution?
I agree with you that size is more important because when sending PDFs to
mobile devices, but we've had speed complaints in the past. Some people
generate large amount of PDF files to be sent to a printer.
I did a test with an image of size 248KB. It took 16% more time and the PDF was
4% smaller so this is quite a price to pay, so IMHO we should give the user a
choice.
> [Patch/RFC] Set maximum compression level on FlateFilter
> --------------------------------------------------------
>
> Key: PDFBOX-3982
> URL: https://issues.apache.org/jira/browse/PDFBOX-3982
> Project: PDFBox
> Issue Type: Improvement
> Components: Writing
> Affects Versions: 2.0.7
> Reporter: Emmeran Seehuber
> Priority: Minor
> Attachments: PDFBoxDeflateLevel.patch
>
>
> Currently the flate filter uses the default compression level, which in case
> auf zlib is 6. When looking around the web for zlib compression level
> settings, most result suggest that a level higher than 6 does not gain much
> but take longer to compress.
> This is true for most data, but not for lossless compressed images. The
> savings there can be very measurable (e.g. in a PDF containing some big
> highres images 66 MB (level 6) to 57 MB (level 9); Nope, I don't have sample
> data ready, as this were customer images).
> The attached patch changes the deflate compression to 9. Most time you want a
> maximum compressed PDF file, as generating PDFs is usually not time critical.
> On the other side, when you want to generate a PDF very fast, you usually
> want a compression level of 2 or 3, as at this levels you have a higher write
> performance due to less IO (at least in my tests) and very fast compression.
> The best would be of course to allow the user to set the compression level
> them self, e.g. on the document level. But I don't think it's possible to get
> the compression level from the document to the COSStreams. A global system
> property (e.g. apache.pdfbox.deflatelevel) could be a solution, but not a
> nice one.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
