# Why your PDF text extraction is garbled, out of order, or empty, and how to fix it

> Source: https://netray.co/troubleshoot/pdf-extraction-garbled-text
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: On-Prem AI Troubleshooting

## Short answer

Garbled PDF extraction almost always comes from using a text-layer extractor on a document that does not have the kind of text layer it expects: scanned or image-based PDFs need OCR, multi-column layouts need layout-aware extraction to preserve reading order, and ligature characters need Unicode normalization. Match the extraction method to the actual document type, and route scanned engineering drawings to a vision model instead of text extraction entirely.

## Error Title

PDF text extraction produces garbled or out-of-order text

## Error Signature

extracted PDF text has words run together or in the wrong order

## Alternate Signatures

- ligatures render as boxes or missing characters in extracted text
- multi-column PDF extracts columns interleaved line by line
- scanned PDF returns empty or gibberish text

## Category

rag-retrieval

## Stack

- huggingface
- transformers

## Affects

Any RAG ingestion pipeline handling mixed PDF sources: scanned documents, multi-column layouts, and typeset technical documents.

## Quick Fix

### Fastest path to clean extracted text

**Steps:**

Check whether the PDF has a real text layer by attempting a simple text extraction; if it returns empty or near-empty text, the PDF is scanned images and needs OCR, not text extraction.

For scanned documents, run OCR and validate output quality on a sample before batch processing the full corpus.

For multi-column layouts, use a layout-aware extraction library or model that detects column boundaries and reading order, rather than a naive extractor that reads left-to-right across the full page width.

Normalize ligature characters (fi, fl, ffi, ffl) and other Unicode substitutions during post-processing.

For engineering drawings or documents where meaning is carried by spatial layout rather than linear text, route extraction through a vision-language model instead of forcing text extraction to handle content it was never designed for.

## Symptoms

- Extracted text has words or sentences run together with no spaces, or spaces inserted in the middle of words
- Reading a multi-column document produces text where lines from different columns are interleaved out of order
- Common letter combinations like fi, fl, or ffi are missing, replaced with boxes, or rendered as unrelated characters
- A PDF that opens and displays fine visually extracts as empty or near-empty text
- Engineering drawings or diagrams extract as scattered fragments of dimension labels with no coherent structure

## Causes

### The PDF is a scanned image with no real text layer, and the extractor is not running OCR

**Likelihood:** most-common

**Explanation:** Many PDFs, especially older documents, faxes, or scanned paperwork, contain only a rasterized image of each page with no embedded text at all. A standard text-extraction library looks for a text layer, finds none, and returns empty or minimal output, which is often mistaken for a bug rather than the expected result for an image-only document.

**Fix:** Detect scanned documents by checking for near-empty extraction results, then route them through an OCR engine before chunking, and manually spot-check OCR output quality since accuracy varies significantly with scan quality.

**Commands:**

- python -c "import fitz; print(len(fitz.open('doc.pdf')[0].get_text().strip()))"

### Multi-column layout is extracted in raw left-to-right, top-to-bottom order instead of true reading order

**Likelihood:** common

**Explanation:** A naive text extractor processes text objects in the order they appear in the PDF's internal structure or by simple coordinate sorting across the full page width. For a two or three column layout, this interleaves lines from different columns, producing text that reads as nonsense even though every individual word extracted correctly.

**Fix:** Use a layout-aware extraction tool that detects column boundaries and extracts each column fully before moving to the next, or a document AI model trained on layout understanding.

### Ligature glyphs are not correctly mapped back to their constituent characters

**Likelihood:** occasional

**Explanation:** Many PDF fonts render common letter pairs like fi, fl, ffi, and ffl as single ligature glyphs for typographic quality. If the extraction library's font-to-Unicode mapping does not handle these glyphs, they extract as missing characters or unrelated codepoints, silently corrupting any word containing them.

**Fix:** Apply Unicode normalization and a known ligature substitution map as a post-processing step on all extracted text, and spot-check a sample for common words that frequently contain these ligatures.

### Engineering drawings and diagrams are being forced through text extraction instead of a vision model

**Likelihood:** occasional

**Explanation:** Drawings, schematics, and diagrams encode meaning through spatial arrangement, symbols, and dimension lines, not linear prose. Text extraction pulls out scattered labels and dimension numbers with no relational structure, which is technically correct extraction but useless for answering questions that depend on understanding what those labels refer to.

**Fix:** For documents where diagrams carry the primary information, use a vision-language model to describe or extract structured information directly from the rendered page image, rather than relying on the underlying text layer alone.

## Diagnostics

### Check if extraction returns meaningful text length for a supposedly text-based PDF

**Command:** python -c "import fitz; d=fitz.open('doc.pdf'); print(sum(len(p.get_text()) for p in d))"

**Interpretation:** A near-zero character count for a multi-page document strongly indicates a scanned, image-only PDF that needs OCR rather than a bug in the extraction code.

### Visually compare extracted text order against the rendered page for a multi-column document

**Command:** python -c "import fitz; print(fitz.open('doc.pdf')[0].get_text('blocks'))"

**Interpretation:** Inspecting the block-level output with coordinates reveals whether blocks from different columns are being read in an interleaved order; layout-aware extraction should group and order blocks by column first.

### Search extracted text for common ligature-affected words

**Command:** python -c "import re; t=open('extracted.txt').read(); print(len(re.findall(r'o ce|of ce', t)))"

**Interpretation:** Matches suggest ligature characters were dropped or mis-mapped during extraction, confirming a ligature normalization issue rather than a content problem.

## Prevention

- Automatically classify incoming PDFs as text-based or scanned before choosing an extraction method, rather than applying one extractor to everything.
- Run OCR quality checks on a sample of each new scanned document source before ingesting it at scale.
- Use a layout-aware extraction library for any document source known to use multi-column formatting.
- Apply Unicode normalization as a standard post-processing step on all extracted text, regardless of source.
- Route diagram-heavy document types through a vision model pipeline from the start, rather than discovering the failure after ingestion.

## When To Escalate

If your corpus includes a large volume of low-quality scans, handwritten annotations, or complex engineering drawings where even good OCR and vision models struggle with domain-specific symbols and notation, this becomes a document digitization and vision-model fine-tuning project rather than an extraction library swap, and is worth scoping with dedicated evaluation before committing to a single extraction approach across the whole corpus.

## Faq

### How do I know if a PDF needs OCR without opening every file manually?

**Answer:** Run a quick text-extraction pass across the corpus and flag any document where extracted character count per page falls below a low threshold; pages below that threshold are very likely scanned images needing OCR.

### Does OCR accuracy matter enough to pay for a commercial engine over open-source Tesseract?

**Answer:** For clean, modern scans, open-source OCR is often good enough. For low-quality scans, unusual fonts, handwriting, or documents where accuracy directly affects compliance or safety decisions, commercial OCR engines or vision-language models typically produce meaningfully fewer errors and are worth the cost.

### Can a single extraction pipeline handle both scanned and native-text PDFs?

**Answer:** Yes, if it first classifies each document, or even each page, by whether it has a usable text layer, then routes scanned pages to OCR and text-layer pages to standard extraction. Trying to force one method to handle both reliably produces exactly the garbled or empty output this page describes.

### Should engineering drawings be chunked and embedded like regular text documents?

**Answer:** Generally no, at least not from raw text extraction alone. Drawings usually need a vision-capable model to generate a textual description or extract structured data first, and that generated description is what gets chunked and embedded, since the original spatial information does not survive a text-only pipeline.

## Search terms

PDF text extraction garbled, PDF OCR RAG, multi-column PDF extraction, ligature extraction error, scanned PDF RAG, PDF layout extraction, engineering drawing vision model, PDF ingestion pipeline

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json