Error Fix: Why the LaTeX PDF Produces Zero Column Splits

TLDR

Bipartite column detection returned 0 column splits on a 2-column LaTeX paper, initially suspected to be caused by math glyph advance width calibration errors. Diagnostic tracing revealed that display-math equation blocks arrive from getTextContent() as single text items ($400\text{px}$ to $500\text{px}$ wide) spanning both columns. Pre-filtering items with vWidth > S * 4 prior to the fallback crossing scan restores accurate column split detection.

Candidate Item Group	Item Width ($vWidth$)	Fallback Crossing Scan Role	Column Detection Output
All Text Items	Includes $500\text{px}$ display math	Crosses every $X$ candidate	0 Splits (Gutter blocked)
Narrow Items Only	vWidth <= S * 4 ($\le 190\text{px}$)	Evaluates paragraph text only	1 Split detected ($X \approx 310$)

---

Technical remediation implementation

// Pre-filter anomalously wide items before executing fallback column crossing scan
export function detectPageColumnsWithMathGuard(textMeta, pageScaleS, viewportWidthPx) {
  // 1. Primary interval merge pass over all items
  const primaryGaps = findIntervalMergeGaps(textMeta);
  if (primaryGaps.length > 0) return primaryGaps;
// 2. Fallback crossing scan: Filter out full-width display math items (vWidth > S * 4)   const narrowItems = textMeta.filter(item => item.vWidth <= pageScaleS * 4);
// 3. Execute crossing scan strictly on narrow paragraph text items   const candidateSplitX = findLowestCrossingCoordinate(narrowItems, viewportWidthPx);   return candidateSplitX !== null ? [candidateSplitX] : []; }

Rule of thumb: Filter out text items wider than $4 \times \text{fontSize}$ before evaluating fallback column crossing scans to prevent display math from blocking gutters.