Reducing PDF file size using Ghostscript on Linux didn't work

后端 未结 2 801
無奈伤痛
無奈伤痛 2020-12-07 23:23

I have about 50-60 pdf files (images) that are 1.5MB large each. Now I don\'t want to have such large pdf files in my thesis as that would make downloading, reading and prin

相关标签:
2条回答
  • 2020-12-08 00:06

    DNA decided to go for grayscale PNGs. The way he's creating them is in two steps:

    1. Step 1: Convert a color PDF page (such as this) to a grayscale PDF page, using Ghostscript's pdfwrite device and the settings
      -dColorConversionStrategy=/Gray and
      -dProcessColorModel=/DeviceGray.
    2. Step 2: Convert the grayscale PDF page to a PNG, using Ghostscript's pngalpha device at a resolution of 300 dpi (-r300 on the GS commandline).

    This reduces his initial file size of 1.4 MB to 0.7 MB.

    But this workflow has the following disadvantage:

    • It looses all color info, without saving much disk space as compared to a color output written at the same resolution, directly from the PDF!

    There are 2 alternatives to DNA's workflow:

    1. A one-step conversion of (color) PDF -> (color) PNG, using Ghostscript's pngalpha device with the original PDF as input (same settings of 300 dpi resolution). This would have this advantage:

      • It would keep the color information in the PNG output, requiring only a little more space on disk!
    2. A one-step conversion of (color) PDF -> grayscale PNG, using Ghostscript's pnggray device with the original PDF as input (same settings of 300 dpi resolution), with this mix of advantage/disadvantage :

      • It would loose the color information in the PNG output.
      • It would loose the transparent background that was preserved in DNA's workflow.
      • It would save lots of disk space, because the filesize would go down to about 20% of the output from DNA's workflow.

    So you can make up your mind and see the output sizes and quality side-by-side, here is a shell script to demonstrate the differences:

    #!/bin/bash
    #
    # Copywrite (c) 2012 <kurt.pfeifle@gmail.com>
    # License: Creative Commons (CC BY-SA 3.0) 
    
    function echo_do() {
            echo
            echo "Command:     ${*}"
            echo "--------"
            echo
            "${@}"
    }
    
    [ -d out ] || mkdir out
    
    echo 
    echo "    We assume all PDF pages are 1-page PDFs!"
    echo "    (otherwise we'd have to include something like '%03d'"
    echo "    into the output filenames in order to get paged output)"
    echo
    
    echo '
     # Convert Color PDF to Grayscale PDF.
     # If PDF has transparent background (most do), 
     # this will remain transparent in output.)
     # ATTENTION: since we don't use a resolution,
     # pdfwrite will use its default value of '-r720'.
     # (However, this setting will only affect raster objects...)
    '
    for i in *.pdf
    do
    echo_do gs \
     -o "out/${i}---pdfwrite-devicegray-gs.pdf" \
     -sDEVICE=pdfwrite \
     -dColorConversionStrategy=/Gray \
     -dProcessColorModel=/DeviceGray \
     -dCompatibilityLevel=1.4 \
      "${i}"
    done
    
    echo '
     # Convert (previously generated) grayscale PDF to PNG using Alpha channel
     # (Alpha channel can make backgrounds transparent)
    '
    for i in out/*pdfwrite-devicegray*.pdf
    do
    echo_do gs \
     -o "out/$(basename "${i}")---pngalpha-from-pdfwrite-devicegray-gs.png" \
     -sDEVICE=pngalpha \
     -r300 \
      "${i}"
    done
    
    echo '
     # Convert (color) PDF to grayscale PNG using Alpha channel 
     # (Alpha channel can make backgrounds transparent)
    '
    for i in *.pdf
    do
    # Following only required for 'pdfwrite' output device, not for 'pngalpha'!
    #                -dProcessColorModel=/DeviceGray 
    echo_do gs \
     -o "out/${i}---pngalphagray_gs.png" \
     -sDEVICE=pngalpha \
     -dColorConversionStrategy=/Gray \
     -r300 \
      "${i}"
    done
    
    echo '
     # Convert (color) PDF to (color) PNG using Alpha channel
     # (Alpha channel can make backgrounds transparent)
    '
    for i in *.pdf
    do
    echo_do gs \
     -o "out/${i}---pngalphacolor_gs.png" \
     -sDEVICE=pngalpha \
     -r300 \
      "${i}"
    done
    
    echo '
     # Convert (color) PDF to grayscale PNG 
     # (no Alpha channel here, therefor [mostly] white backgrounds)
    '
    for i in *.pdf
    do
    echo_do gs \
     -o "out/${i}---pnggray_gs.png" \
     -sDEVICE=pnggray  \
     -r300 \
      "${i}"
    done
    
    echo " All output to be found in ./out/ ..."
    echo
    

    Run this script and compare the different outputs side by side.

    Yes, the 'direct-grayscale-PNG-from-color-PDF-using-pnggray-device' one may look a bit worse (and it doesn't sport the transparent background) than the other one -- but it is also only 20% of its file size. On the other hand, if you wan to buy a bit more quality by sacrificing a bit of disk space -- you could use -r400 instead of -r300...

    0 讨论(0)
  • 2020-12-08 00:26

    If you run Ghostscript -dPDFSETTINGS=/screen this is just a sort of shortcut. In fact you'll get (implicitly) a whole bunch of settings used, which you can query with the following command:

    gs \
      -dNODISPLAY \
      -c ".distillersettings {exch ==only ( ) print ===} forall quit" \
    | grep '/screen'
    

    On my Ghostscript (v9.06prerelease) I get the following output (slightly edited to increase readability):

    /screen 
      << /DoThumbnails false 
         /MonoImageResolution 300 
         /ColorImageDownsampleType /Average 
         /PreserveEPSInfo false 
         /ColorConversionStrategy /sRGB 
         /GrayImageDownsampleType /Average 
         /EmbedAllFonts true 
         /CannotEmbedFontPolicy /Warning 
         /PreserveOPIComments false 
         /GrayImageResolution 72 
         /GrayACSImageDict << 
                            /ColorTransform 1 
                            /QFactor 0.76 
                            /Blend 1 
                            /HSamples [2 1 1 2] 
                            /VSamples [2 1 1 2] 
                          >> 
         /ColorImageResolution 72 
         /PreserveOverprintSettings false 
         /CreateJobTicket false 
         /AutoRotatePages /PageByPage 
         /MonoImageDownsampleType /Average 
         /NeverEmbed [/Courier 
                      /Courier-Bold 
                      /Courier-Oblique 
                      /Courier-BoldOblique 
                      /Helvetica 
                      /Helvetica-Bold 
                      /Helvetica-Oblique 
                      /Helvetica-BoldOblique 
                      /Times-Roman 
                      /Times-Bold 
                      /Times-Italic 
                      /Times-BoldItalic 
                      /Symbol 
                      /ZapfDingbats] 
         /ColorACSImageDict << 
                              /ColorTransform 1 
                              /QFactor 0.76 
                              /Blend 1 
                              /HSamples [2 1 1 2] 
                              /VSamples [2 1 1 2] >> 
         /CompatibilityLevel 1.3 
         /UCRandBGInfo /Remove 
    >>
    

    I'm wondering if your PDFs are image-heavy, and if this sort of conversion does un-welcome things (f.e. re-sampling images with the 'wrong' parameters) which increase the file size...

    If this is the case (image-heavy PDF), tell so, and I'll update this answer with a few suggestions....


    Update

    I had a look at the sample file provided by DNA. Interesting...

    No, it does not contain any image.

    Instead, it contains one large stream (compressed using /FlateDecode) which consists of roughly 700.000+ (!!) operations, mostly single vector operations in PDF language, such as:
    m (moveto),
    l (lineto),
    d (setdash),
    w (setlinewidth),
    S (stroke),
    s (closepath and stroke),
    W* (eoclip),
    rg and RG (setrgbcolor)
    and a few more.

    (That PDF code is very inefficiently written AFAICS (but does its job), because it does concatenate many short strokes instead of doing 'long' ones, and nearly each stroke defines the color again (even if it is the same as before), and has all the other overhead (start stroke, end stroke,...).

    Ghostscript's -dPDFSETTINGS=/screen do not have any effect here (there are no images to downsample, for example). The increased file size (+48 kByte to be precise) is probably due to Ghostscript re-organizing some of the internal stroking etc. commands to a different order when it interprets the file.

    So there is not much you can do about the PDF file size ...

    • ...unless you convert each of these PDF pages into a REAL image such as PNG:
        gs \
          -o out72.png \
          -sDEVICE=pngalpha \
           L_2lambda_max_1wl_E0_1_zg.pdf
    

    (I used the pngalpha output to get transparent background.) The image dimensions of 'out.png' are 259x213px, the filesize is now 70 kByte. But I'm sure you'll not like the quality :-)

    The output quality is 'bad' because Ghostscript uses a default resolution of 72 dpi.

    Since you said you'd like to have 300dpi, the command becomes this:

    gs \
      -o out300.png \
      -sDEVICE=pngalpha \
      -r300 \
       L_2lambda_max_1wl_E0_1_zg.pdf
    

    The filesize now is 750 kByte, the image dimensions are 1080x889 Pixels.


    Update 2

    Since Curiosity is en vogue these days... :-) ...I tried to bring down the file size with the help of Adobe Acrobat X Pro on Mac.

    You wanna know the results?

    Performing a 'Save as... (PDF with reduced filesize)' -- which for me in the past always yielded very good results! -- created a 1,8++ MByte file (+29%). I guess this definitely puts Ghostscript's performance (file size increase +3%) into a realistic perspective !

    0 讨论(0)
提交回复
热议问题