[jira] [Updated] (PDFBOX-3982) [Patch/RFC] Set maximum compression level on FlateFilter

["Emmeran Seehuber (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PDFBOX-3982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmeran Seehuber updated PDFBOX-3982:
-------------------------------------
    Attachment: FlateFilterCompressionLevelSystemProperty.patch

I've attached a patch, which allows to change this setting using a system property. As FlateFilter is private, I've put the constant for the property into the Filter-Interface. The Naming is similar to the {code}COSParser.SYSPROP_EOFLOOKUPRANGE{code} constant. This patch also changes the default compression to 9. If someone wants maximum write performance he should change the setting to 2 or 3.

> [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: FlateFilterCompressionLevelSystemProperty.patch, 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-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org