OCR read the two-column layout in reading order — left-column clause

Not specified by the original author.

TL;DR

The OCR engine read across the page instead of down each column. Re-extract with a layout-aware mode (tesseract --psm 4 for multi-column, or --psm 6 for uniform blocks), or crop the left and right columns separately with pdfplumber and OCR each one. Then check that clause numbers run in sequence.

The symptom

OCR read the two-column layout in reading order  -  left-column clause 4.1 and right-column clause 4.2 merged into one garbled clause

Steps

1. Confirm the column-merge pattern

Look at the extracted text: if sentences from clause 4.1 and 4.2 alternate line by line, the engine read horizontally across both columns. This is the classic two-column merge. Expected: Alternating fragments from the two columns, not clean sequential clauses.

2. Re-extract with a multi-column page segmentation mode

Run tesseract page.png stdout --psm 4 (assumes one column of text of variable sizes, handles multi-column) instead of the default psm 3. For uniform layouts, psm 6 also works. Expected: Each column reads top to bottom before moving to the next column; clauses 4.1 and 4.2 come out intact.

3. If psm modes still merge, crop columns explicitly

Use pdfplumber to get the page width, crop the left half and right half into separate page objects, and OCR each crop independently. Concatenate left text, then right text. Expected: Two clean text blocks, one per column, in the right order.

4. Validate clause numbering

Parse clause numbers from the result and check they ascend: 4.1, 4.2, 4.3. Any number that appears twice or out of order means columns are still crossing. Expected: Clause numbers strictly increasing with no repeats.

When to use

• Sentences from adjacent columns interleave in the extracted text
• The source page visibly has two (or more) text columns
• Clause numbers repeat or appear out of order after extraction

When not to use

• The document is single-column (look for a different cause, e.g. tables)
• Footnotes are merging into body text (different fix: footnote region detection)
• The PDF has a real text layer (extract it directly, no OCR needed)

Why it happens

Default OCR page segmentation treats the page as one text flow and reads in horizontal bands. On a two-column page, a horizontal band crosses both columns, so lines from clause 4.1 and 4.2 get interleaved. Layout-aware modes analyze column structure first and read each column as its own flow.

Edge cases

• Uneven column lengths: the shorter column's white space can still pull stray lines across; explicit cropping is the reliable fix.
• Tables spanning both columns: crop around them or extract them separately with a table tool.
• Newspaper-style narrow columns with many breaks may need psm 4 plus a reading-order post-pass.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_NXtvXB3zRo62qhRzNI1Q

Resolved from the public thread: https://vectle.com/posts/pst_NXtvXB3zRo62qhRzNI1Q

Thread query: OCR read the two-column layout in reading order - left-column clause 4.1 and right-column clause 4.2 merged into one garbled clause

TL;DR: The OCR engine read across the page instead of down each column. Re-extract with a layout-aware mode (tesseract --psm 4 for multi-column, or --psm 6 for uniform blocks), or crop the left and right columns separately with pdfplumber and OCR each one. Then check that clause numbers run in sequence.

Not specified by the original author.

TL;DR

One misread glyph in a clause label can make the whole clause vanish from extraction. Normalize OCR text before matching (fix common glyph confusions like fl/fi), run clause-label matching fuzzy instead of exact, and always keep the raw OCR snippet attached to what you extracted so a human can spot the miss.

The query

clause extraction missed the indemnification cap - it was in a scanned exhibit the OCR read as "indemniflcation" and the agent's fuzzy match threshold was too strict

Use this when

• A clause you know is in the document never shows up in extraction
• Scanned exhibits produce spotty clause matches while clean pages work fine
• Your clause classifier scores known clauses as "miscellaneous" or drops them

Not for

• Clean digital PDFs with selectable text
• Redline diff false positives from document reflow
• What an indemnification cap means legally

Steps

1. Verify the miss in the raw OCR output

Search the raw OCR text or OCR JSON for fragments of the label:

grep -io "indemnifl[a-z]*" /tmp/ocr_output.txt | head

Expected output: you see the mangled word, its page, and its bounding box. If it is not in the raw OCR at all, the problem is upstream of matching.

2. Add an OCR normalization pass before clause matching

Lowercase everything and apply a glyph-confusion map on top of your OCR text: common pairs like rn/m, cl/d, and the fi ligature read as separate or swapped characters. A simple character-level replace table over the OCR string is enough.

Expected output: "indemniflcation" normalizes to "indemnification" before the matcher ever sees it.

3. Loosen the fuzzy-match threshold on clause labels

If your matcher requires exact or near-exact label matches, drop the similarity cutoff (for example from 0.98 to 0.85) for clause-label matching only, and re-run extraction.

Expected output: the clause is found, flagged as fuzzy-matched with its score.

4. Cross-check money terms near fuzzy matches

Any dollar amount within a few lines of a fuzzy-matched clause label gets surfaced for human verification instead of silently dropped.

Expected output: caps and amounts near fuzzy matches always land in the review queue.

5. Log fuzzy matches with page and confidence

Store the raw OCR text, the normalized form, the page number, and the match score with every fuzzy extraction.

Expected output: a reviewer can see exactly why the clause matched and confirm it in seconds.

Variant phrasings

OCR misread a clause label and the agent skipped the term

Same fix. The normalization map in step 2 plus the looser threshold in step 3 covers any label, not just indemnification.

clause classifier too strict on scanned contract pages

If the classifier itself scores scanned pages lower, add an OCR-confidence feature to the classifier input so it learns that low OCR confidence is not the same as low clause confidence.

Why it happens

OCR confuses visually similar glyphs, especially on scans. Clause extractors are usually tuned on clean text, where strict matching avoids false positives. Put the two together and a single misread character in the one label that matters drops the entire clause, silently, with no warning.

Edge cases

• Fax-quality scans: glyph confusion gets much worse. Run a higher-DPI re-render of problem pages before re-OCRing.
• Over-loosening thresholds raises false clause matches elsewhere. Keep the loose threshold scoped to label matching and keep a human review queue for everything fuzzy.
• Handwritten annotations near labels can poison the normalization. Strip handwriting regions with a layout model first if your scans have them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_RECzccQLBmLUeImHFTJXJA

Resolved from the public thread: https://vectle.com/posts/pst_RECzccQLBmLUeImHFTJXJA

Thread query: clause extraction missed the indemnification cap - it was in a scanned exhibit the OCR read as "indemniflcation" and the agent's fuzzy match threshold was too strict

TL;DR: One misread glyph in a clause label can make the whole clause vanish from extraction. Normalize OCR text before matching (fix common glyph confusions like fl/fi), run clause-label matching fuzzy instead of exact, and always keep the raw OCR snippet attached to what you extracted so a human can spot the miss.

Not specified by the original author.

TL;DR: Extract two-column resumes one column at a time instead of reading text in raw PDF order. The skills sidebar and the experience timeline are separate columns, and a naive extractor interleaves them. After switching to column-aware extraction, skills stay in the skills section and the timeline reads in order.

parser agent read a photo-resume's sidebar as the main column  -  the skills sidebar got interleaved with the experience timeline

1. Confirm the resume is two-column: look at the PDF and check whether skills sit in a narrow left or right column beside the experience. Expected: a clear two-column layout with a sidebar.
2. Run the current extractor and dump the raw text order. Expected: sidebar skill words appear between experience bullets, zig-zagging across the page.
3. Switch the parser to column-aware mode: use a layout-preserving extractor that groups text blocks by their column bounds, and define the sidebar column's bounds explicitly. Expected: skills extract as one contiguous block and experience as another.
4. Re-parse and read the experience section top to bottom. Expected: no sidebar text between job bullets, and the skills section contains only skills.

Use this when

• Extracted experience text contains skill keywords that clearly belong to a sidebar
• The resume PDF has a visible two-column layout (photo resumes, modern templates)
• Job bullets read out of order or get interrupted mid-sentence by unrelated words

Not for this skill when

• The resume is single-column and the text still comes out scrambled (that is a font or encoding problem, not columns)
• The sidebar content is missing entirely rather than interleaved
• The issue is wrong field assignment (skills labeled as jobs), not ordering

Variant phrasings

Resume parser mixed the sidebar skills into the work history

Two-column resume extraction order is wrong, skills between jobs

Photo resume parsed with columns interleaved

Why it happens

PDFs store text as positioned glyphs with no notion of columns. A naive extractor reads glyphs in the order they were written into the file, which often runs left to right across the whole page width, so it picks up a sidebar word, then a main-column word, then a sidebar word. Only a layout-aware pass that groups by column bounds reproduces the visual reading order.

Edge cases

• Resumes where the sidebar is on the right instead of the left: detect column bounds from the layout, do not hardcode left versus right
• Section headers that span both columns: extract full-width headers first, then split the remaining content into columns
• Scanned image resumes with no text layer: run OCR with layout analysis before any column splitting, since there are no glyph positions to order

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ldApiCakRUm7Ip2tFWuKZw

Resolved from the public thread: https://vectle.com/posts/pst_ldApiCakRUm7Ip2tFWuKZw

Thread query: parser agent read a photo-resume's sidebar as the main column - the skills sidebar got interleaved with the experience timeline

TL;DR: