如果你寫過PDF解析腳本，一定經歷過這種絕望：跑一遍通用文本提取器，原本整齊的表格變成一堵文字墻，所有列被暴力壓成垂直堆疊。更糟的是換用表格提取器——它開始到處 hallucinate（產生幻覺）。加粗標題帶下劃線？ parser 認定這是 1×1 表格。段落間的水平分隔線？砰，幽靈表格誕生。

問題根源在于大多數 PDF 解析器采用嚴格的順序流水線。它們掃描所有線條，掃描所有文字，然后簡單粗暴地混在一起。我受夠了這種"機器式閱讀"，于是重新設計了提取流水線——讓 parser 像人類一樣"看見"文檔。

這就是上下文感知 PDF 提取的數學原理。

盲目提取的災難

我們之前的流水線是這樣工作的：找出所有水平和垂直線段（H-segs 和 V-segs），丟進 LatticeReconstructor 找交叉網格，每個網格都當表格處理，再用嚴格的"點是否在框內"判斷把所有文字塞進這些網格。

這種設計對圖文混排文檔是災難。段落里一條裝飾性下劃線會讓 LatticeReconstructor panic，強行造表。表格單元格里的文字因坐標抖動稍微偏移，"點-框檢測"就失敗，文字直接從輸出里消失。

我需要 parser 理解上下文。

上下文分類器的介入

我構建了 contextClassifier。它不再把 PDF 當作形狀和文字的容器，而是遍歷文檔，將每個元素歸類到空間有界的類型區域：TABLE、PARAGRAPH、HEADING、LIST、IMAGE。

但機器怎么區分表格邊框和裝飾下劃線？用鄰近度數學。

代碼邏輯很直接：遍歷每條水平線段，計算其中點縱坐標 hY；遍歷每個文字元數據，計算 hY 與文字基線縱坐標 tm.vy 的垂直距離 yDist。如果 yDist 在 -1 到 5 像素之間，且水平方向與文字重疊，這條線就是下劃線而非表格邊框。

在表格重建前標記并剔除這些下劃線，99% 的幽靈表格被消滅。

文字作用域：告別碰撞

表格檢測完成后，我們計算表格網格的精確邊界框。contextClassifier 不再把整份文檔的文字丟給表格構建器，而是只撈取物理上位于該邊界框內的文字項。這種"物理居住"檢查替代了粗暴的全局匹配，從根本上消除了文字錯配和消失的問題。

這套數學框架的核心洞察很簡單：PDF 不是幾何圖形的隨機堆疊，而是人類視覺意圖的編碼。用像素級的鄰近關系重建這種意圖，機器才能停止幻覺，開始理解。