[
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-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
