A downsampling tier is usually labeled by image resolution: 72, 150, 300 dpi. On a scanned page that label hides the real question, because the whole page is one image and the text is just pixels inside it. The number that decides whether a tier is safe is the smallest point size someone still has to read. In a downsampling ladder tested on 2026-11-06, 150 dpi kept 6 pt Chinese and English above 99% recognition accuracy, while 72 dpi pulled even 12 pt Chinese down to 71.0%.
Scope before numbers. The test page is a self-made A4 page image: four Chinese and four English sentences at 12, 10, 8 and 6 pt in one Hei typeface, drawn at 300 dpi with a scan look added (noise, blur, slight rotation) and stored as JPEG, 1,591,319 bytes for the page. It was forced down with Ghostscript 10.07.1 to 300, 200, 150, 100 and 72 dpi, every result was rendered back at 300 dpi so the recognizer sees an enlarged view, and scored each block with macOS text recognition, where accuracy is 1 minus edit distance over character count. English got a second opinion from Tesseract 5.5.3, with only its English model installed. One Apple M4 Mac, one page, one run per step.
gs -o out.pdf -sDEVICE=pdfwrite -dPDFSETTINGS=/ebook -dDownsampleColorImages=true -dColorImageResolution=100 -dColorImageDownsampleThreshold=1.0 -dGrayImageResolution=100 -dGrayImageDownsampleThreshold=1.0 in.pdf
The threshold of 1.0 is deliberate: the stock presets only downsample images more than 1.5 times above the target, so a preset-only ladder would quietly skip steps.
Where the text gave out
Down to 150 dpi nothing broke. The 200 dpi step scored 100% on every block, and 150 dpi only lost a little on 6 pt Chinese (99.1%) while the file went from 624,930 bytes at 300 dpi to 167,933. One oddity I haven't explained: the 300 dpi step (re-encoded, not downsampled) scored 99.1% on 12 pt Chinese, slightly lower than the 200 dpi step. My guess is recognizer noise; I didn't chase it.
At 100 dpi (87,346 bytes) Chinese started to go. 8 pt fell to 96.3% and 6 pt to 81.3%, with errors like 清晰 ("clear") coming back as 清断 and 逾期 ("overdue") as 適期. English 6 pt still scored 99.1% with macOS and 94.3% with Tesseract. At 72 dpi (61,010 bytes) the Chinese blocks scored 71.0%, 41.1%, 46.7% and 0% from 12 pt down to 6 pt. English held at 100% for 12 pt, then dropped to 84.7% at 8 pt and 11.3% at 6 pt; Tesseract gave 99.1, 94.3, 76.0 and 41.1% going from 12 down to 6 pt.
The pixel arithmetic is short: glyph size in pixels is roughly point size × dpi ÷ 72. 6 pt at 100 dpi is about 8 px, at 72 dpi about 6 px, and 8 pt at 72 dpi is back at 8 px. My inference from this one typeface, and it is only that, is that dense CJK strokes start turning into blobs somewhere around 8 px. That would explain why Chinese gave out a full tier before English did.
What the score does not tell you
Two things kept me from drawing a clean curve. At 72 dpi part of the Chinese loss is whole lines the recognizer skipped rather than wrong characters, which probably explains why 10 pt scored below 8 pt. And macOS recognition runs with language correction, so it can guess some words right from context and likely flatters the low steps; Tesseract on English fell earlier and more evenly.
Resolution is not the only knob either. On a separate two-page scanned sample (300 dpi page images, 2,357,639 bytes), two tools that both landed at 72 dpi gave very different 6 pt results: 41.5% for one and 7.6% for Ghostscript /screen. Same dpi, so my guess is the gap comes from encoding; I didn't dig into which settings. The 41.5% came from ImgIng https://imging.ai/ , run in a desktop browser on the same Mac. Its PDF engine isn't a part I worked on, so I'm reading it from the outside. Its tiers are screen 72, ebook 150 (marked as recommended), print 300 and a structure-only option, and images already below a tier's dpi aren't resampled. At 150 dpi that sample came out at 637,933 bytes, more than double iLovePDF's 280,869 and Ghostscript /ebook's 316,227, while 6 pt recognition stayed within a point of both (98.8% against 98.2%). Whether those extra bytes buy anything depends on how you weight the small-text area; I have no test that settles it.
Turning it into tiers
If I were writing the acceptance test for a tier list, the input would be the smallest text the document type carries, not the image's native resolution: fine print on a form, 6 pt table footnotes, 10 pt body copy. The test page needs that size in every script you ship, since CJK and Latin don't fail at the same step. Run the ladder, recognize each step, and keep the lowest dpi that still scores around 99% on the smallest size. On this page that answer was 150 dpi for 6 pt Chinese, while 100 dpi only passes if the smallest text is 8 pt English (100% macOS, 99.6% Tesseract). 72 dpi belongs to a tier labeled for screens and slides, with a note that scans carrying small print shouldn't go there.
The gap I haven't closed is typefaces. This was one Hei face and one noise profile, with no thin-stroked Song or Ming faces, which I'd expect to break earlier. That is the next page I'd add to the ladder before trusting 150 dpi for every document.
Top comments (0)