Searchable PDFs and OCR

A scanned PDF is a photograph wearing a document's clothes: it renders, but nothing can select, search, extract, or index it. POST /lmkit/v1/pdf-ocr fixes the document itself: it recognizes each scanned page and overlays the text INVISIBLY over the page image, so the document looks pixel-identical and starts behaving like text. Its read-only sibling, POST /lmkit/v1/document-ocr, recognizes the same pages but returns the text per page instead of producing a file, for when you want the words, not a better PDF.

1The overlay, precisely#

The output page shows the original scan; beneath the pixels sits a text layer aligned to the recognized words. Selection, copy, search, extraction, and indexing all work, and because the visible layer IS the original image, OCR mistakes cost searchability on a word, never visual fidelity. Recognition uses the server's configured OCR engine; languages narrows the recognition alphabet when you know the corpus, and detect_orientation straightens pages scanned sideways before reading them.

2Page policy: what deserves recognition#

Real batches mix scanned and digital pages, so which pages to OCR is a policy, not a loop you write:

• text_page_handling: skip pages that already carry selectable text (the default, and the idempotent choice: running OCR twice does not double the text), or force recognition everywhere, for documents whose existing text layer is garbage.
• text_detection_strategy: what "already carries text" means. Judge by PDF text-rendering OBJECTS (structural, strict) or by whether any text is EXTRACTABLE (looser). The distinction matters for documents with invisible or degenerate text layers.
• page_range scopes the pass, so re-processing one bad page never touches the rest.

3Output engineering#

The rebuilt file's weight and lifespan are choices:

• Compression: image_encoding picks JPEG (small) or lossless Flate for the page images, with jpeg_quality as the dial; binary_image_encoding picks CCITT Group 4 fax compression (the right answer for black-and-white scans) or Flate for bitonal images.
• pdf_version: the output can target plain PDF versions, or emit PDF/A-1b or PDF/A-2b directly, collapsing scan-to-archival into one call; the PDF/A chapter covers the standard, and its validator proves the result.
• save_options: a full document rewrite (default), with an option to strip encryption and security handlers from the output.

The response reports per-page results, so a batch pipeline can route pages that recognized poorly to review instead of trusting the whole file blindly.

4Which OCR door to use#

The server exposes recognition in three shapes; choosing well avoids double work:

And often you need NONE of them explicitly: extraction, classification, and the rest of the document endpoints already OCR scanned input as part of ingestion. Reach for pdf-ocr when the DOCUMENT must carry its text forward: archives, delivery to third parties, and viewers.

5Stated plainly#

• The overlay makes the scan itself searchable without changing a visible pixel, and page policies make the pass idempotent and re-runnable.
• Compression and version knobs turn "a searchable PDF" into "the searchable PDF your archive wants", including direct PDF/A output.
• One engine, three doors: fix the file, take the text, or let ingestion handle it; the right door is the one matching what downstream actually consumes.