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.

```text
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