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

dearN picture dearN · Aug 7, 2012 · Viewed 21.7k times · Source

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 printing a pain in the rear. So I tried using ghostscript to do the following:

gs \
  -dNOPAUSE -dBATCH \
  -sDEVICE=pdfwrite \
  -dCompatibilityLevel=1.4 \
  -dPDFSETTINGS="/screen" \
  -sOutputFile=output.pdf \
    L_2lambda_max_1wl_E0_1_zg.pdf

However, now my 1.4MB pdf is 1.5MB large.

What did I do wrong? Is there some way I can check the resolution of the pdf file? I just need 300dpi images, so would anyone suggest using convert to change the resolution or is there someway I could change the image resolution (reduce it) with gs, since the image is very grainy when I use convert

How I use convert:

 convert \
     -units PixelsPerInch \
      ~/Desktop/L_2lambda_max_1wl_E0_1_zg.pdf \
     -density 600 \
      ~/Desktop/output.pdf

Example File

http://dl.dropbox.com/u/13223318/L_2lambda_max_1wl_E0_1_zg.pdf

Answer

Kurt Pfeifle picture Kurt Pfeifle · Aug 7, 2012

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 !