Can OCR Handle Two Column Documents Correctly?
By Schema LawPublished Updated
OCR can handle two-column documents when it finds the gap between the columns and reads the left one to the bottom before it starts the right. It goes wrong when the gap is narrow, crooked or crossed by a heading. Then it reads straight across the page and splices unrelated lines together.
What is reading order and why does it break?
Reading order is the sequence in which the words on a page are written into the output. A person reads a two-column page down the left column, then down the right. Software has to work that sequence out from a picture, and when it guesses wrong the words are all correct but the sentences are not.
That is what makes a column error different from an ordinary misread. Every word may be spelled perfectly. A spell check finds nothing. A search for a single name still works. What breaks is anything longer than a line: a quotation, a clause, a phrase search, a comparison against another draft.
Here is a small two-column page and the two ways it can come out.
The page:
The Tenant shall pay rent The Landlord shall keep the
on the first day of each roof and outer walls in good
month without deduction. repair at its own expense.
Read down each column (right):
The Tenant shall pay rent on the first day of each month
without deduction. The Landlord shall keep the roof and
outer walls in good repair at its own expense.
Read across the page (wrong):
The Tenant shall pay rent The Landlord shall keep the on
the first day of each roof and outer walls in good month
without deduction. repair at its own expense.The wrong version contains every word of the original. It also appears to say the landlord keeps something "on the first day of each roof". A phrase search for "first day of each month" now finds nothing on a page that plainly contains it. In a large set, that is a missed document.
You will see this on a deposition transcript printed in columns, and on a discovery response that quotes one. A subpoena attachment in two columns fails the same way. Before you search for a phrase you expect to use at trial, confirm the seam between the columns so the hit is one passage and not two sentences glued together.
How does OCR decide where a column ends?
Before it reads any letters, OCR software divides the page into blocks. It looks for rivers of white space, and a tall, unbroken vertical strip of white is taken as a gutter between columns. Each block is then read on its own, and the blocks are put in order. Break the white strip and the blocks merge.
Some engines let the operator state the layout instead of leaving it to be detected. Tesseract, an open-source engine, is a clear example. Its documentation on improving the quality of Tesseract output says that by default it "expects a page of text" when it segments an image, and it lists alternative page segmentation modes, one of which tells it to "Assume a single column of text of variable sizes". The setting exists because layout detection is a guess that can be wrong.
These are the things that hide or break a gutter:
| On the page | What it does to column detection |
|---|---|
| Narrow gutter, or text set close to a centre rule | The gap looks like an ordinary space between words, so lines join across it |
| Skewed scan | The white strip is no longer vertical, so it looks shorter and broken |
| Heading, caption or table that spans both columns | The page has to be split into a full-width zone and column zones, in the right sequence |
| Footnotes set full width under two columns | Notes can be attached to the wrong column or read in the middle of the body |
| Stamp, sticker or handwriting in the gutter | The mark bridges the gap |
| A column that continues on the next page | Each page is read alone, so the join between pages is yours to check |
Columns and tables are easy to confuse, and the software confuses them too. Two columns of prose should be read down. Two columns of a table should be read across, a row at a time. A defined-terms list, with the term on the left and its meaning on the right, is really a table. The guide to OCR on exhibits with tables deals with that side of the line.
Two-column documents lawyers meet most often
Most two-column pages in a legal file are transcripts, printed legal sources, policies and bilingual agreements. Each has its own trap, so it helps to know which kind you are holding before you convert it.
- Condensed deposition transcripts. Four small pages on one sheet make two columns and two rows, each with its own line numbers. The correct order runs page by page, not across the sheet. The guide to making deposition transcripts searchable covers them in detail.
- Case reporters, codes and law review articles. Printed reporters and annotated codes are set in two columns with headnotes, running headers and footnotes that cross the page. Page-break markers inside a column matter for pin cites.
- Insurance policies and standard terms. Small type and narrow gutters are common, and so are endorsements that switch back to a single column part way through the file.
- Bilingual contracts. Two languages run side by side, and clause 4 on the left is meant to sit beside clause 4 on the right. Reading down the left column and then the right is correct for prose but separates each clause from its translation. Decide which you need before you judge the output.
- Side-by-side comparisons. A document showing old wording on the left and new wording on the right is a table in disguise, and should be handled as one.
Checking and repairing column order after conversion
Check column order on every two-column page before you quote from it or search it. The test takes under a minute a page: find where the left column ends in the output and confirm that the top of the right column follows it.
- Find the seam. Note the last few words at the foot of the left column and the first few at the head of the right. In the output, the second should come directly after the first.
- Search for a phrase that wraps. Pick three or four words that run over a line break inside one column. Search the output for them. A hit means lines in that column are still joined to each other.
- Check full-width items. Confirm that the heading comes before both columns and that footnotes come after them.
- Check where the layout changes. Go to any page that switches between one column and two, since detection is decided page by page.
The export you choose changes what you are checking. Plain text shows the order most plainly, because there is nothing else in the file. In Schema Law the Word export is built from headings, paragraphs, lists and tables, with each source page starting a new page. It does not recreate a two-column layout, so the text arrives as one column in the order it was read. The searchable PDF export places each page's hidden text as lines running from the top of the page down in reading order, not under the individual words. Search that file by phrase to check order, and do not rely on dragging a selection across one column. The post on whether OCR keeps formatting lists what else carries over.
If the order is wrong, pick the repair that matches the damage:
- One block is out of place. If a whole column or a footnote landed in the wrong spot but reads correctly inside, cut and paste it in the Word file.
- Lines alternate left, right, left, right. Do not untangle this by hand. Crop the page image into one picture for each column, save them as PNG or JPEG files, and convert them separately. Each picture is now a one-column page.
- The scan is crooked. Fix that first, because a tilted gutter is a common cause. The guide to running OCR on a crooked scan covers it.
- It is a table. Export it as a table and check it row by row.
No tool gets every layout right, so test with your own hardest page. Schema Law's free plan takes one document a day of up to three pages, which is enough to try a transcript sheet or a policy page and run the four checks above. The three-step outline on the homepage shows the upload and export flow.