The usual one-liner for shrinking a PDF with Ghostscript is -dPDFSETTINGS=/ebook, and the usual explanation is "150 dpi". If that flag is going into a pipeline that touches customer documents, the full list of what it changes is worth having before release, not after a complaint. So I dumped the settings /ebook expands into and put the presets through a scripted test on self-made samples. Resolution is one change out of three. The other two are how pixels get averaged and a color conversion to sRGB.
Setup: an Apple M4 Mac, Ghostscript 10.07.1, pdfimages (poppler 26.08) and PyMuPDF 1.26.5 for image sizes, macOS text recognition plus Tesseract 5.5.3 (English) for small text. The samples are self-made: a two-page A4 "report" of 2,312,093 bytes with vector text and one 4032×3024 photo placed 12 cm wide (derived from a CC0 image on Wikimedia Commons), the same pages rendered at 300 dpi with noise and blur to look scanned (2,357,639 bytes, not real scanner output), and a one-page small-text sheet. Every number is a single run.
Ebook targets 150 dpi for color and gray images
The preset is a bundle of distiller parameters. For /ebook the dump shows ColorImageResolution 150, GrayImageResolution 150 and MonoImageResolution 300, with /Average as the downsample type for color and gray images and /Subsample for mono. It also sets ColorConversionStrategy /sRGB. For comparison, /screen targets 72, /printer and /prepress target 300, and /default has downsampling switched off for all three image types.
On the report, the photo went from 853 dpi (4032 pixels across 4.72 inches) to 150 dpi, which is 708×531 pixels, and the file dropped from 2,312,093 to 107,991 bytes, down 95.3%. The text is vector, so the savings came out of the photo. On the scan, each page image went from 2481×3508 to 1240×1754 and the file from 2,357,639 to 316,227 bytes, down 86.6%. Effective dpi measured on both outputs matched the preset.
Average downsampling lands near the target
Average makes each output pixel the mean of a block of input pixels. I placed one 2480×3508 image at four sizes, giving 400, 440, 460 and 600 dpi, and ran /ebook on each. The outputs came back at 150, 147, 153 and 150 dpi. Close to the target, not always on it, which matters if a downstream check asserts exactly 150.
There is also a 1.5x threshold: under /printer (target 300) the 400 and 440 dpi copies came through untouched while 460 and 600 dropped to 300, and the 300 dpi scan came out 0.08% bigger under /printer and /prepress.
Inference, not measurement: 147 and 153 look like 440 and 460 divided by 3, and 600 to 150 is a factor of 4, so Average may snap to a whole-pixel block. The 400 dpi case doesn't fit, because 400 divided by 3 is 133 and I got 150. I don't have the rule for that one yet.
The photo lost its ICC profile on the way
Before compression, pdfimages -list reported the photo's color column as icc. After /ebook the same image reported rgb. That lines up with the sRGB line in the dump: the embedded profile is gone, and nothing in the command line hints at it. Whether the pixel values themselves shifted, and by how much, I didn't measure.
I didn't test a CMYK source or a print file, so I can't say what this setting does to one. The same dump shows /prepress using /LeaveColorUnchanged, and passing -dColorConversionStrategy=/LeaveColorUnchanged with /ebook might keep the profile, but I haven't run it on these files. Treat both as leads, not results.
Small text held up at 150 dpi
The other worry is legibility. The test sheet has Chinese and English lines at 12, 10, 8 and 6 pt, scanned look, 300 dpi. It was forced down to 300, 200, 150, 100 and 72 dpi with this command, shown here for 100 (command only, no output pasted; the results are the recognition scores below):
gs -dPDFSETTINGS=/ebook -sDEVICE=pdfwrite \
-dDownsampleColorImages=true -dColorImageDownsampleThreshold=1.0 -dColorImageResolution=100 \
-dGrayImageDownsampleThreshold=1.0 -dGrayImageResolution=100 \
-o out.pdf in.pdf
A threshold of 1.0 removes the slack. At 150 dpi every line from 12 pt down to 6 pt stayed at 99% recognition or better in both languages, with Chinese 6 pt at 99.1%. At 100 dpi Chinese 8 pt fell to 96.3% and 6 pt to 81.3%, while English 6 pt still read at 99.1%. At 72 dpi Chinese 6 pt read 0% and English 6 pt 11.3%; part of the low Chinese score there is the recognizer skipping whole lines. Chinese breaks one step earlier than English. On this one sheet, 150 held for both languages and 100 didn't hold for Chinese.
For a browser-side comparison I ran the scan through ImgIng https://imging.ai/ in a desktop browser, whose eBook tier also targets 150 dpi and skips images already below it. On the scan it produced 637,933 bytes, about twice the Ghostscript /ebook output, with small-text recognition less than 2 points apart. Its runs sent no non-GET request.
Pin the settings you depend on
/ebook is still a reasonable preset. If a check downstream depends on the resolution, pass it explicitly, and decide color handling on purpose instead of inheriting sRGB. Then run pdfimages -list on one output and read two columns, x-ppi and color, which is where both the 147 dpi surprise and the icc-to-rgb switch showed up. The 400 dpi result is still the one I can't explain.
Top comments (0)