Pdf Processor

Hot Take: Most PDF Processors Are Using the Third-Best API Available

2026-06-04

TLDR

Most PDF extraction tools rely exclusively on getTextContent(), which is a lossy, post-processed convenience wrapper over getOperatorList(). Relying on getTextContent() discards structural tags (getStructTree()), explicit path geometry (vector rules), and Marked Content IDs (MCID). Implementing a three-tier API cascade ensures extractors utilize high-fidelity document metadata before resorting to spatial coordinate guessing.

PDF Extraction API	Data Source Type	Structural Fidelity Level	Typical Use Cases
`getStructTree()`	Logical XRef Tree	Tier 1: Semantic Truth	Native tagged Word/InDesign exports
`getOperatorList()`	Raw Paint Commands	Tier 2: Geometric Truth	Vector ruled lines & background fills
`getTextContent()`	Processed Glyphs	Tier 3: Heuristic Guessing	Untagged fallback extraction

Architectural API hierarchy

getStructTree()     # Tier 1: Semantic Ground Truth (MCID Joined)
   │
   ▼
getOperatorList()   # Tier 2: Geometric Ground Truth (Explicit Vector Paths)
   │
   ▼
getTextContent()    # Tier 3: Typographic Text Convenience (Spatial Heuristics)

Rule of thumb: Treat getTextContent() as a fallback spatial heuristic API rather than the sole data source for PDF document structure extraction.

Read this post in the full Engineering Journal →