Uploaded image for project: 'PDFBox'
  1. PDFBox
  2. PDFBOX-3982

[Patch/RFC] Set maximum compression level on FlateFilter

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • 2.0.7
    • 2.0.8, 3.0.0 PDFBox
    • Writing
    • None
    • Patch

    Description

      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.

      Attachments

        1. PDFBoxDeflateLevel.patch
          1 kB
          Emmeran Seehuber
        2. FlateFilterCompressionLevelSystemProperty.patch
          2 kB
          Emmeran Seehuber

        Activity

          People

            tilman Tilman Hausherr
            rototor Emmeran Seehuber
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: