Engineering Journal
Pdf Processor
Pdf Processor

The Empty Quadrant: A Three-Part Series on the Design Space of Frontend PDF Extraction

2026-05-30

TLDR

PDF extraction engines occupy four distinct quadrants along two primary architectural axes: Execution Environment (In-Browser vs. Server-Side) and Processing Strategy (Probabilistic ML vs. Deterministic Geometry). The Ginexys PDF Processor fills the previously unoccupied Deterministic-Structural-Frontend quadrant by combining raw operator vector parsing, baseline-proximity underline filtering, and off-thread Web Worker execution without shipping server dependencies or ML model weights.
Extraction QuadrantPrimary Technology StackKey TradeoffIdeal Use Case
Server-Side ML ModelsPython, LayoutLM, LayoutParserHigh server cost, slow turnaroundUnstructured scanned documents
Browser Canvas Viewerspdfjs-dist Canvas RendererRigid non-reflowable absolute textVisual print-preview rendering
Browser Text-Only ParsersNative PDF.js getTextContent()Zero table/border vector awarenessSimple single-column text scraping
Deterministic FrontendCTM Operators + Geometry WorkerZero ML weights, $100\%$ Browser-nativeStructured multi-column PDF export

The three-part architecture series

Part 1: mapping the 2x2 design matrix

Part 2: eight architectural invariants

Part 3: borrowed math, original composition

Rule of thumb: Combine vector CTM operator parsing with Web Worker isolation to fill the deterministic-structural-frontend PDF extraction niche.
Read this post in the full Engineering Journal →