Mapping the 2x2 of Frontend PDF Extraction (And the Empty Quadrant)

TLDR

Browser-based PDF processing architectures map onto a $2\times2$ design space defined by Execution Mode (Backend vs. Frontend Browser-Native) and Structural Strategy (Deterministic Geometry vs. Machine Learning Models). While backend engines (pdfplumber, Camelot) and visual canvas viewers (pdf2htmlEX) populate three quadrants, the Deterministic-Structural-Frontend quadrant remained empty until modern Web Worker CTM operator pipelines filled the gap.

Quadrant Category	Representative Stack	Engineering Tradeoff
Backend Deterministic	pdfplumber, Camelot, PyMuPDF	Requires server infrastructure / API costs
Frontend Visual Canvas	pdf2htmlEX (WASM)	Absolute <div> positions; zero semantics
Frontend ML Inference	transformers.js + LayoutLM	Heavy model weights ($6\text{MB}+$); slow inference
Frontend Deterministic	CTM Operators + Geometry Workers	Zero ML weights, 100% Browser-native structure

---

Technical comparison matrix

// Baseline PDF.js extraction used by 95% of naive implementations:
// Fails on multi-column papers, tables, and structured document reflow
const pdf = await pdfjsLib.getDocument(bytes).promise;
let text = '';
for (let i = 1; i <= pdf.numPages; i++) {
  const page = await pdf.getPage(i);
  const content = await page.getTextContent();
  text += content.items.map(it => it.str).join(' ') + '\n';
}

Rule of thumb: Combine vector operator list parsing with browser Web Workers to execute deterministic structural PDF layout extraction without server dependencies or ML model weights.