# Document OCR: How Software Maps a Page Before Reading It

- Author: Schema Law (https://www.schemalaw.com/)
- Published: 2024-03-29T00:34:18Z
- Updated: 2026-10-11T19:22:20Z
- Category: OCR basics
- Canonical: https://www.schemalaw.com/blog/document-ocr

> Document OCR maps a page into regions before it reads any letters. See how layout analysis works, what word coordinates record, and how to test software.

Document OCR is recognition that treats the whole page as a document. Before it reads a single letter, the software maps the page into regions such as paragraphs, headers, tables and pictures. Plain character recognition turns shapes into letters. Document OCR also records what each block is and where on the page it sits.

That mapping step is called layout analysis. A wrong letter is a small, local fault. A wrong region moves a paragraph, swallows a footnote or turns a fee table into a run of loose numbers.

## What makes document OCR more than character recognition?

Character recognition answers one question: which letter is this shape? Document OCR answers three more. Which marks on the page are text at all? Which lines belong together as a block? What kind of block is each one? The output is a structured page, with text sorted into labeled, positioned pieces.

Consider one page of a fictional commercial sublease between Ferris Cold Storage, Inc. and Maddox Produce Co. It has a running header with the document title, a body paragraph, a small table of monthly charges, a footnote, a page number, two signatures and a notary seal.

Hand that page to software that only recognizes characters and you get every word it could find, top to bottom, as one stream. The header becomes the first line of the paragraph. The table becomes "Month Base Rent CAM January 6,200 410". The seal contributes a few stray letters.

Hand it to document OCR and you get something closer to this:

| Region | Type | What happens to it |
| --- | --- | --- |
| Top strip | Page header | Kept apart from the body, or marked so it can be dropped |
| Main block | Body text | Read as one paragraph |
| Grid in the middle | Table | Read cell by cell, with rows and columns kept |
| Small type at the bottom | Footnote | Read after the body, not in the middle of it |
| Centered number | Page number | Marked as such |
| Two scrawls | Signatures | Treated as pictures, not forced into letters |
| Round mark | Seal or stamp | Treated as a picture, with any legible words read separately |

The letters may be identical in both results. What differs is that the second result knows which letters go together. Every useful export depends on that: a Word file with real paragraphs, a spreadsheet with real columns, a search highlight that lands on the word.

When a vendor describes its product as document OCR software, or uses terms like "document understanding" or "layout-aware", this is the capability being claimed. The label is not regulated, so judge the output and not the name.

## How does document OCR divide a page into regions?

Document OCR divides a page by looking for the visual cues a reader uses without noticing: bands of white space, ruled lines, changes in type size and the alignment of text edges. It groups nearby marks into lines, lines into blocks, and then decides what each block is. Recognition of the letters comes afterwards.

The steps, in the order most systems run them:

1. **Separate ink from paper.** The software decides which pixels are marks and which are background. Shadows, punch holes and dark scan edges can be mistaken for content at this point.
2. **Find the page's orientation and tilt.** Is the page upright, sideways or upside down, and by how many degrees is it skewed? Everything later assumes level lines.
3. **Find the white space.** Wide vertical gaps suggest columns. Wide horizontal gaps suggest breaks between blocks. Narrow, regular gaps are the spaces between lines.
4. **Find ruled lines.** Horizontal and vertical rules point to tables, form boxes, signature lines and the separator above footnotes.
5. **Group marks into lines and blocks.** Marks on a common baseline become a text line. Lines with similar spacing, width and type size become a block.
6. **Label each block.** Text, table, picture, or something to ignore. Position and size help: a short block at the very top is probably a header.
7. **Order the blocks.** The software decides which block a person would read first, second and third.
8. **Read each text block.** Only now are characters recognized, block by block.

Step 7 is its own subject. The post on [what reading order is and why it breaks](https://www.schemalaw.com/blog/can-ocr-handle-two-column-documents#what-is-reading-order-and-why-does-it-break) covers how software sequences columns and what the errors look like.

### Rules, models and settings

Older engines carry out these steps with fixed rules about gaps and lines. Systems built on a trained model look at the whole page and propose regions directly. Neither approach is immune to an unusual page, and the post on AI OCR explains [what model-based systems do differently](https://www.schemalaw.com/blog/ai-ocr-for-lawyers#what-do-model-based-systems-do-differently).

Some engines let the operator say what kind of page to expect. The documentation for the open-source Tesseract engine, in its guide to [improving the quality of OCR output](https://tesseract-ocr.github.io/tessdoc/ImproveQuality.html), states that "by default Tesseract expects a page of text when it segments an image" and lists alternative page segmentation modes for inputs such as a single column, a single line or sparse text. A product built on an engine like that has made a choice about those settings for you. That is one reason two products can map the same page differently.

A third approach skips automatic mapping altogether. A person draws the regions once on a template and the software reads only those boxes on every matching page. That is [zonal OCR](https://www.schemalaw.com/blog/what-is-zonal-ocr), and it suits fixed forms far better than varied correspondence.

## Region types on a legal page: body text, headers, tables, signatures, pictures

Document OCR sorts each region into a type because each type needs different handling. Body text is read as running prose. Headers and footers are set apart. Tables are read as a grid. Signatures, seals and photographs are kept as pictures. A region given the wrong type is processed the wrong way from then on.

A legal page can pack many kinds of region onto one sheet. A checklist of what to expect:

| Region type | Legal examples | Correct handling | If mistyped |
| --- | --- | --- | --- |
| Body text | Clauses, numbered paragraphs, recitals | Read as paragraphs in order | Rarely mistyped; more often split or merged |
| Heading | Article titles, "WITNESSETH", captions | Kept as a separate short block | Glued to the paragraph below |
| Header or footer | Case number, document title, firm name, "Page 4 of 19" | Marked as repeating furniture | Inserted into a sentence that crosses the page break |
| Marginal text | Pleading line numbers, Bates numbers, fax banner | Kept out of the body | Numbers scattered through the text |
| Footnote | Citations, definitions | Read after the body of its page | Read as part of the last paragraph |
| Table | Fee schedules, payment histories, exhibit lists | Read as rows and columns | Flattened into lines of loose figures |
| Form field | Checkboxes, blanks, labeled boxes | Label kept with its value | Labels and answers separated |
| Signature | Wet-ink signatures and initials | Kept as an image | "Read" as nonsense characters |
| Stamp or seal | Filed stamps, notary seals, "RECEIVED" | Image, with any clear text read | Stamp text dropped into the body |
| Picture | Photographs, site plans, logos | Kept as an image | Specks of invented text |

Tables get a second pass of their own, because finding the grid is harder than finding the table's outline. The post on [how OCR finds a table on a scanned page](https://www.schemalaw.com/blog/scanned-pdf-to-excel#how-does-ocr-find-a-table-on-a-scanned-page) explains ruled and unruled tables.

Two region types deserve a lawyer's particular attention.

**Marginal text.** Pleading paper with line numbers down the left edge, and productions with a Bates number in a corner, put text exactly where layout rules expect a column. Good layout analysis isolates it. Poor analysis threads "14 15 16" through your quotation.

Separate the caption from the body on a pleading, or a search for the allegation runs into the exhibit stamp. Read the party names in the caption, then the claim in the first numbered paragraph. A box drawn too wide drags the stamp into that claim, and the highlight sits on the wrong line.

**Signatures and stamps.** The right outcome for a signature is that the software declines to read it. If your converted text shows a string like "/ilLf~" where a signature sits, the region was treated as text. That is harmless in a searchable PDF and a nuisance in a Word file.

## Coordinates: how document OCR records where each word sits

Document OCR records position as a bounding box: the smallest upright rectangle that encloses a word, line or block, written as numbers measured from a corner of the page image. Those numbers tie each piece of recognized text to the spot it came from, which is what lets software highlight, redact or check it.

Boxes nest. A page contains blocks, a block contains lines, a line contains words, and each level has its own rectangle.

Formats for OCR results write this down in slightly different ways. One open format, hOCR, stores results as HTML. The [hOCR specification](https://kba.github.io/hocr-spec/1.2/) describes itself as "an open standard for representing document layout analysis and OCR results as a subset of HTML", and defines a `bbox` property whose four values run "left top right bottom", measured in pixels from the top-left corner of the image. A word on a scanned lease might be recorded like this:

```
<span class="ocrx_word" title="bbox 412 1306 548 1342">Maddox</span>
```

Read it as: the word "Maddox" occupies a rectangle that starts 412 pixels from the left edge and 1,306 from the top, and ends 548 from the left and 1,342 from the top. It is 136 pixels wide and 36 tall. On a page scanned at 300 dots per inch, that is a word a little under half an inch wide, about four and a third inches down the sheet.

Another format, ALTO, serves the same purpose. The Library of Congress, which maintains it, titles its page for the standard [ALTO: Technical Metadata for Layout and Text Objects](https://www.loc.gov/standards/alto/).

### What coordinates make possible

- **Search highlights.** A searchable PDF can place each hidden word under its picture so the highlight covers it.
- **Redaction by search.** A tool that redacts every occurrence of a name needs to know where each occurrence is.
- **Click to verify.** Review software can jump from a line of extracted text to the place on the scan it came from.
- **Rebuilding layout.** Word and spreadsheet exports use positions to decide indents, columns and cell boundaries.

### What to know before relying on them

Coordinates are measured against one particular image. Rotate, crop, straighten or resample the page afterwards and the numbers no longer point at the words.

Not every tool keeps or exposes coordinates. Some use them internally and export only text. Others position text by line or by page. If your work depends on word positions, for redaction or for pinpoint highlights, ask to see them in the output before you commit. Schema Law's exports are described on the homepage by what they contain: the JSON export, for example, holds each page's text and tables. Look at a real export from any tool to see what position data, if any, comes with it.

## What goes wrong when page regions are drawn in the wrong place?

When regions are drawn wrongly, correct letters end up in the wrong place. Blocks merge that should be separate, one block splits into several, a region gets the wrong type, or a region is missed and its text vanishes. These faults are easy to overlook because every individual word still reads correctly.

| Fault | What you see in the output | Typical cause on a legal page |
| --- | --- | --- |
| Two blocks merged | A sentence that jumps topic midway; column text interleaved line by line | Narrow gutter between columns; skewed scan |
| One block split | A paragraph broken into fragments, sometimes reordered | Wide gaps inside justified text; a stamp across the paragraph |
| Header absorbed | "Case No. 24-CV-0193 Page 7" in the middle of a sentence | A sentence that runs across a page break |
| Footnote absorbed | Citation text spliced into the body | No rule above the footnote; similar type size |
| Table read as text | Numbers in a row with no column meaning | Unruled table; light or broken rules |
| Text read as table | Ordinary paragraphs chopped into cells | Tab-aligned text, signature blocks, addresses side by side |
| Picture read as text | Short bursts of nonsense characters | Signatures, seals, hatching on plans |
| Text read as picture | A passage simply absent from the output | Text on a shaded background; reversed white-on-black headings; very large or very small type |
| Region missed | Margin note, handwritten date or stamp text missing | Content near the edge; faint ink |

### The fault that costs most: missing text

A garbled word invites a second look. A missing paragraph does not, because nothing on the output page marks the hole. Shaded boxes are the usual culprit in legal documents: a warning notice in a consumer contract, a highlighted clause, a form's gray instruction panel. The software classes the shaded area as a picture and reads none of it.

You catch this by counting, not by reading. Compare the number of paragraphs, numbered clauses or table rows on the scan with the number in the output. If clause 11 is followed by clause 13, go and look.

### Why a skewed page multiplies the damage

Layout analysis leans on straight white gaps. Tilt the page two or three degrees and the gutter between columns stops being a clean vertical band. Lines from the left column start to align with lines from the right. Software that straightens the page first depends on how well that step went. If a batch of scans went through the feeder crooked, expect region faults across the whole batch and consider rescanning before you spend time on corrections.

## Judging document OCR software by its layout handling

Judge document OCR software on your hardest layouts, not on a clean letter. Nearly any tool reads a single-column typed page. The differences show on pleading paper, dense tables, pages with stamps, footnoted briefs and forms. Pick a small set of such pages and inspect where each tool put the text.

### Build a test set of ten pages

Use real pages from closed or non-sensitive matters, or pages you are permitted to upload. Include:

1. A two-column page, such as a reported decision or a statute printout.
2. A page of line-numbered pleading paper.
3. A page with at least two footnotes.
4. A ruled table of figures.
5. An unruled table, where columns are set by spacing alone.
6. A page with a filed stamp or exhibit sticker over or near text.
7. A signature page with a notary block.
8. A government or court form with boxes and checkmarks.
9. A page with a shaded or boxed notice.
10. A page where a sentence runs over a page break under a running header.

### What to look at in each result

Read for position, not spelling.

- **Is each paragraph whole and in order?** Check the first and last words of three paragraphs against the scan.
- **Did headers, footers and line numbers stay out of the body?** Search the output for the page number or case number and see where it lands.
- **Are footnotes after the body text of their page?**
- **Do tables keep their rows and columns?** Count rows on the scan and in the output.
- **Is anything missing?** Count numbered clauses. Look for the shaded notice.
- **What happened to signatures and stamps?** Nonsense characters, a clean omission, or a kept image are three different behaviors.

Score each page pass or fail on each line and compare tools on the totals. Ten pages and six questions give you sixty observations, which says more than a vendor's sample. These questions cover layout only. The general method, with an answer key for names and numbers, is in the section on [running your own test on real documents](https://www.schemalaw.com/blog/what-is-the-best-ocr-for-lawyers#running-your-own-test-on-real-documents).

### Check it in the format you will use

Layout faults show differently in different exports. A searchable PDF hides them, because you still see the original picture. Word and Excel expose them at once. Test in the format your work needs.

In Schema Law you can see the parsed result page by page on screen and check it against the original before you export, as the [how it works section of the homepage](https://www.schemalaw.com/#how-it-works) describes. The free plan accepts one document a day of up to three pages, enough to try a few of your hardest pages at no cost. Whatever tool you test, the method is the same: difficult pages, your own eyes, and a count of what moved or went missing.

## Try it on a real document

Upload a scanned PDF and export it as Word, a searchable PDF or plain text on the free plan. Your documents are never used to train an AI model. [Start free](https://www.schemalaw.com/api/auth/google)