You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Tilman Hausherr (JIRA)" <ji...@apache.org> on 2017/10/29 11:59:00 UTC
[jira] [Comment Edited] (PDFBOX-3982) [Patch/RFC] Set maximum
compression level on FlateFilter
[ https://issues.apache.org/jira/browse/PDFBOX-3982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16223961#comment-16223961 ]
Tilman Hausherr edited comment on PDFBOX-3982 at 10/29/17 11:58 AM:
--------------------------------------------------------------------
Why would a global system property not be a nice solution?
I agree with you that size is more important e.g. 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.
was (Author: tilman):
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-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org