Searchable text in a generated PDF: print drivers versus screenshots

Half of the PDFs on a typical production line are searchable and half are not, and the difference was decided before either file existed. When a report is printed from an application, the words reach the PDF driver as text with coordinates and stay text. When a report is captured as a screenshot, the file holds only pixels, and every searchable word has to be recovered afterwards by OCR, with errors. This guide explains where the text in a PDF actually comes from, how many pixels OCR needs to recover a character from a captured page, and how to generate inspection reports so the words stay words and the pictures stay pictures.

Why does a printed PDF have searchable text while a screenshot does not?

Search lives in the file, not in the picture: a report printed through a driver keeps its words as text objects with coordinates, while a screenshot delivers one bitmap that contains no characters for a search to match.

A PDF stores a page as a list of drawing instructions. Text is real data: which glyph from which font, drawn where, at what size. Your viewer's search box matches that data directly, which is why Ctrl+F finds a serial number instantly and why you can select a sentence and paste it into an e-mail.

A screenshot has none of that. It is a rectangle of coloured dots with no characters in it, so there is nothing for the search box to match, nothing to select and nothing to copy. This is also why the belief that a PDF printer 'runs OCR on the page' is wrong: no OCR happens, because no OCR is needed. The words were never pixels in the first place.

How does a print driver turn application text into PDF text?

An application drawing through a print pipeline classifies every element before it leaves the program, so character strings travel to the driver as glyph codes with a font and a position, and the driver records them as text operators rather than painted pixels.

When a program draws for print, it sorts every element by type. Character strings go out as text calls: which font, which characters, which position. Photographs, camera frames and icons go out as bitmaps. A PDF driver translates the first kind into text-showing operators with a subset of the font embedded, and the second kind into image objects.

The consequence is resolution independence. The glyphs are stored as outlines, so a viewer renders them fresh at every zoom level, and a 600 dpi office printer draws them sharper than a 150 dpi one from the same file. The split is exactly what a good report wants: words as words, pictures as pictures, each stored in its native form.

What happens to the text when a report is captured as an image?

A capture freezes the page into pixels before any driver sees it, so the PDF holds a single bitmap with no character codes, and every word that was on screen now exists only as a pattern of dots.

Capture tools — a screenshot utility, a grab-the-panel method, a print path that rasterizes first — all do the same damage: they turn characters into dots before a driver can record them as text. The PDF then contains one image object and, at most, an OCR layer added later. Selection and copy die at the moment of capture, and zoom quality is capped by the capture resolution.

Which path your tool takes is not always obvious, so test rather than assume. Generate one page, run the three checks at the end of this guide, and you will know within a minute whether your toolkit preserves text or buries it. Where a library documents that it writes text elements directly, that is the path that keeps the words.

How many pixels does OCR need to recover text from a captured page?

Treat 30 to 50 pixels of character height as the working range for reliable OCR, call anything below about 20 pixels unreliable, and expect a 12 pt label captured at the usual 96 px/in screen scale to measure only around 11 pixels of cap height.

The height that matters is the height of the character in the image, and it is fixed at the moment of capture, not when the page is placed on paper. Two short formulas cover it:

The 0.7 factor is typical of the sans-serif fonts used in user interfaces, where cap height runs near 70 percent of the point-size em.

Worked example. A 12 pt label on a desktop screen at 100% scaling: most desktops draw 1 pt as 96/72 = 1.333 px, so em = 12 x 1.333 = 16 px, and cap height = 0.7 x 16 = 11 px. That is far below the 20 px floor, which is exactly why OCR on captured panels and HMI screens disappoints.

To lift that label to a 30 px cap height, the capture must scale by 30 / 0.7 / 16 = 2.7x. A 1,280 x 800 panel then becomes 1,280 x 2.7 = 3,456 px wide and 800 x 2.7 = 2,160 px tall. Uncompressed at 24 bits per pixel, one page weighs 3,456 x 2,160 x 3 bytes = 22.4 MB. The same page stored as text holds roughly 2,000 characters plus a font subset — call it 30 KB — so in this example the rasterized version costs about 700 times the storage for worse fidelity.

Paper fit tells the same story. A 1,280 px capture stretched across the 7.5 in of printable width on a Letter page lands at 1,280 / 7.5 = 171 dpi, well under the 300 dpi commonly specified for printed records. At 300 dpi, that same capture must shrink to 1,280 / 300 = 4.3 in wide.

The same pixel-height arithmetic decides whether a camera can read printed characters at all, which is the subject of the guide to minimum font size for OCR. Whole-image limits are not the binding constraint: a typical cloud OCR service accepts images from 50 x 50 px up to 16,000 x 16,000 px, so a 3,456 x 2,160 page passes the door check while its 11 px characters still fail the read.

When is OCR on a rendered page good enough?

OCR is a recovery step for pages you can no longer regenerate, not a generation method: it behaves on clean, high-contrast captures and misreads low-resolution screens, busy backgrounds and stylized fonts.

Use it for archives you cannot rebuild: scans of old shipments, printouts from machines that are gone, reports from software you can no longer run. Expect the classic confusions — 0 and O, 1 and l and I, 5 and S — and control the inputs you can: even contrast, no skew, and crops that carry only the text region. Cropping the text out of a busy page before reading is its own discipline; the detection-to-OCR pipeline guide walks through it.

When a text layer already exists but reads wrong, trace whether the file was born from text or from an image before touching preprocessing. The PDF OCR corruption walkthrough shows how to find the true source of the characters first.

The same split between stored source and rendered view runs through all automation tooling. Turning a legacy PLC program file into searchable text is likewise a structured extraction task, not an OCR afterthought.

How should a vision system generate searchable inspection reports?

Generate the report by writing text elements and embedding images as separate objects: verdicts, serial numbers, measurements and decoded code strings become selectable PDF text, the camera frame stays a picture beside them, and OCR never enters the process.

Every device on the line already outputs the words you need. A fixed code reader transmits the decoded string, normally with the symbology and a read grade, as characters over its interface; a smart camera returns verdicts, measurements and coordinates the same way. The report code writes those characters straight into the text layer. How the bytes arrive is a framing question — ASCII barcode data framing in the PLC receive buffer covers the traps. Browse fixed code readers and smart cameras, both filtered in the same camera finder.

Prefer a PDF library that writes text elements to scripting a printer driver. A library call is a versioned interface; a virtual printer is an installation that updates, breaks and disappears. If you must keep printing front panels, verify with the three checks below that your driver path preserves text before building on it.

A reader that feeds a text-first report needs results you can log, not exotic optics. The LS-CRD-0028 is specified at 2560 x 2048 resolution, 30 fps and up to 60 codes/s:

Compact M12-mount readers cover close-range stations: the MV-ID3013PM-12M-WBN uses a 12 mm focal length, and the MV-ID813M-05S-WBN-SR a 4.9 mm focal length with white light:

On the inspection side, the MV-SC5060XM-08M-WBN pairs a 6 MP mono sensor with an 8 mm focal length over GigE:

Store the frames with their metadata so the report stays lean: archiving inspection images to cloud storage and saving consecutive camera images without code cover the storage side. Report generation inside HMI and SCADA packages fails the same way for the same reasons, and the fault usually sits in the report engine rather than the PDF — a report printed before it has finished loading being the classic case.

What breaks the text layer even when the source is text?

Three failure modes are common: an export option that draws glyphs as outlines, an intermediate capture or flattening step that rasterizes the page, and fonts shipped without the maps that let copied characters match what is printed.

Outlines first. Some drivers and design exports offer to draw glyphs as vector curves. The page looks identical and prints identically, but curves are drawings, so search and selection stop. If a formerly searchable export goes quiet, look for that option first.

Rasterization second. Some workflows flatten a page to guarantee nothing can be recovered — deliberate and correct for redaction, expensive when it happens by accident through a compose or stamp step.

Mapping third. Text can select cleanly yet paste as gibberish when the file lacks a working unicode map from glyph codes to characters. The fix belongs where the PDF is made: embed subset fonts with correct mapping, then paste-test one string before releasing the template.

How do you test a PDF for searchable text before you archive it?

Three checks take under a minute in any PDF viewer: search for a string you can see on the page, select and copy it into a plain text editor, and zoom to 400 percent to see whether the letters re-render sharply.

Each check diagnoses a different failure. A search that finds nothing means there is no text layer at all. A copy that arrives as wrong characters means the encoding maps are broken. A zoom test that turns blocky means you are looking at a bitmap, because real glyphs re-render sharply at any magnification.

Use a real serial number from the run as the search string rather than a common word; that is the same expected-string discipline used to verify OCR output, described in OCR verify mode. Run the three checks on one page of every report template you release, and again after any viewer, driver or library update.

The decision, then: for every report you still control, write the words as text and embed the images as images. For pages that exist only as pixels, OCR is the recovery path, sized by the pixel-height arithmetic above. If you are building or upgrading the station that feeds those reports, start from the camera finder, configure the rest in the system configurator, or reach us through the contact page. Related guides on report and image handling sit under the systems topic page.