The Hidden Trap of PDF-to-Markdown Conversion: How Two-Column Papers Get Squashed into "Text Soup"

Why does PDF-to-Markdown always fail on two-column papers?

Many people think PDF-to-Markdown is just "extracting text"—until they throw a two-column academic paper into a converter and get something like this: column A line 1, column B line 1, column A line 2, column B line 2... On the surface, the Markdown has headings, paragraphs, and lists all in place, but the reading order has been completely shattered.

A developer recently ran into this trap while building a PDF-to-Markdown API. He fed the converted documents into a RAG (Retrieval-Augmented Generation) pipeline, and the retriever started citing sentences stitched together across two columns—chunks that were technically perfectly valid but semantically complete gibberish.

This failure mode is insidious and devastating: it doesn't throw errors, it doesn't drop characters, it just quietly scrambles the author's argument structure into a mess. The core of the problem isn't OCR—it's the loss of layout semantics.

RAG (Retrieval-Augmented Generation) is a technical architecture that combines information retrieval with large language model generation. Its typical workflow: first, split documents into semantically coherent text chunks and build a vector index; when a user asks a question, the system retrieves the most relevant chunks and feeds them as context to the language model to generate an answer. RAG's effectiveness depends heavily on chunk quality—if a chunk itself is cross-column scrambled gibberish, the retriever will faithfully recall it, and the model will generate seemingly reasonable but actually absurd answers based on the wrong context. This is exactly why PDF layout parsing errors get amplified in RAG pipelines: the error occurs at the very upstream, yet contaminates the entire downstream chain.

Tagged PDF is a type of document that embeds a logical structure tree into the PDF file structure. Ordinary PDFs only record "a certain character is drawn at a certain coordinate," while tagged PDFs additionally use tags (such as P, H1, Table, Figure) to describe the logical roles and reading order of content, typically generated by typesetting software during export or added post-hoc through OCR/layout analysis tools. For document converters, a tagged PDF is essentially a built-in "official reading order manual" that can be adopted directly without guessing the layout. But in reality, a large number of academic PDFs are generated by tools like LaTeX and don't retain complete tags, so this signal—though reliable—is not common, and can only serve as a priority item in a hybrid strategy rather than the sole dependency.

Why geometric constraints always "lie"

The developer's initial fix was intuitive: split the page down the middle by x-coordinate, with the left side going to column A and the right side to column B.

This approach worked well on standard two-column body text, but reality quickly slapped it down:

• Cross-column figures: a figure spanning both columns has its caption torn in half down the middle;
• Wide tables: tables with merged cells that cross the centerline end up with scrambled row-column relationships;
• Mixed layouts: a single-column abstract followed by two-column body text renders the fixed centerline strategy useless.

"Geometry deceived me in a new way every single time," the developer wrote in his summary.

The fundamental problem with fixed-coordinate splitting is that it assumes the layout is regular, while real academic PDFs have layouts that change from page to page and even block to block. Using a single vertical line to summarize an entire page's reading logic is doomed to collapse on complex layouts.

Layout Analysis is a core task in the document intelligence field, referring to identifying text blocks, images, tables, headers and footers, and other regions from page images or PDF coordinate information, and inferring their logical relationships and reading order. Common methods include projection-profile-based splitting, connected-component-based segmentation, and in recent years, deep learning-based region detection models (such as the LayoutLM series). The whitespace gutter detection discussed in this article belongs to the classic projection approach: inferring column boundaries by analyzing the distribution of whitespace in the vertical direction of a page. Understanding this helps recognize that geometric splitting and machine learning-based layout analysis are not mutually exclusive—whitespace gutter detection can be seen as a lightweight, interpretable heuristic rule, falling back to conservative strategies when the rules fail, which forms a cost-robustness tradeoff against heavier model-based approaches.

What actually works: whitespace gutter detection + fallback flow + explicit hints

After multiple rounds of trial and error, the approach that finally worked was a hybrid strategy with three layers:

1. Detect column boundaries from whitespace gutters

Instead of fixing the split position, scan the page for vertically continuous whitespace regions—the "white gutters" between columns. Only when the gutters form a stable vertical band across the page is a multi-column structure determined to exist.

The advantage of this method is adaptivity: single-column pages have no stable gutters, so they naturally won't be incorrectly split; two-column pages typically have gutters running through most of the body text height, making detection reliable.

2. Fall back to single-column flow when no stable gutters exist

When a page has cross-column figures, full-width headings, or irregular layouts, the vertical gutters get interrupted. At this point, don't force column splitting—fall back to single-column reading order instead. This sacrifices some precision in within-column ordering but avoids the worst cross-column scrambling.

3. Prioritize respecting the PDF's built-in reading order hints

If the PDF is tagged, it already encodes the reading order defined by the author or generation tool and should be adopted directly. The reality is that tagged PDFs are far rarer than ideal, but when they exist, they are the most reliable signal.

Layout is semantics: advice for document pipeline builders

This pitfall leads to a more fundamental realization: a PDF is not text with coordinates—it's a visual argument about "how ideas relate to each other." When you flatten it into Markdown, you're not extracting text—you're reconstructing the author's intent. Every column, every sidebar, every quotation is a decision about "what should be grouped together."

For those building document processing pipelines, the developer's advice is straightforward: test with dirty data. Specifically:

• Papers with cross-column figures;
• Tables with merged cells;
• Pages with multi-column footnotes.

"Beautiful PDFs are easy; the messy ones are the real spec."

The converter was ultimately released as part of a PDF-to-Markdown tool, with whitespace gutter detection and fallback logic built in, available for pipelines with similar needs to call directly.

Key takeaways

• The core challenge of two-column PDF-to-Markdown is reading order reconstruction, not text recognition;
• Fixed x-coordinate splitting fails on cross-column figures, wide tables, and mixed layouts;
• A hybrid strategy of whitespace gutter detection + single-column fallback + tagged PDF hints is more robust;
• Test sets should include "dirty" samples such as cross-column figures, merged-cell tables, and multi-column footnotes.