pdf-extract

pdf-extract is a Rust library for pulling text and content out of PDF documents. Given the raw bytes of a PDF, it parses the document structure, resolves the fonts and character encodings each page uses, and reconstructs the readable text — handling the many quirks (Type1 encodings, CFF fonts, Adobe CMaps, Unicode normalization) that make PDF text extraction genuinely hard.

Rather than shelling out to an external binary, it does the work in-process with a small, focused API. This makes it a practical building block for search indexing, document pipelines, and any Rust application that needs to read the words inside PDFs. It is authored by a longtime Mozilla graphics engineer and builds on the lopdf parser plus a set of font/encoding helper crates.

What You Get

• Simple extract_text / extract_text_from_mem entry points returning plain text
• Font and encoding handling for Type1, CFF, and CMap-based documents
• Unicode normalization so extracted text is clean and comparable
• A pure-Rust implementation with no external binary or system dependency
• WASM-compatible parsing via lopdf’s wasm_js feature

Common Use Cases

• Indexing PDF documents for full-text search
• Feeding PDF contents into data pipelines, NLP, or LLM workflows
• Converting archived PDFs to plain text for analysis
• Extracting text server-side or in WebAssembly without a native toolchain

Under The Hood

Architecture — src/lib.rs drives extraction: it uses lopdf to parse the PDF object graph, then walks each page’s content stream operators, tracking the current font and text state. Glyph codes are translated to Unicode using the document’s encoding — Type1 encodings, CFF/CID fonts, and Adobe CMaps are decoded via helper crates, with fallbacks to bundled core-font tables in core_fonts.rs, glyphnames.rs, and zapfglyphnames.rs. encodings.rs holds the encoding maps, and a Python helper (glyphlist-export.py) generates the glyph-name tables.

Tech Stack — Pure Rust (edition 2018) layered on lopdf (with wasm_js), plus adobe-cmap-parser, type1-encoding-parser, cff-parser, postscript, euclid, encoding_rs, and unicode-normalization. log provides diagnostics.

Code Quality — There is a real test suite under tests/ (with sample PDFs via test-log/ureq dev-dependencies), and the code is organized so the large generated glyph tables are isolated from the extraction logic. PDF’s inherent messiness means some edge cases remain, but the crate is widely depended upon (~3M downloads).

API Design — Deliberately small: the primary surface is extract_text/extract_text_from_mem, so getting text out of a PDF is a one-liner. Lower-level access to the parsed document is available for callers who need more control.