The first time I ran OCR on a screenshot of a table, the characters came out right and the result was useless: the whole table had collapsed into one long run of text, rows and columns gone. That's when it clicked — OCR is misnamed by "recognising text". Reading the characters is step one; the hard and genuinely useful part is step two: rebuilding the layout.
Reading and rebuilding are two different engineering problems. Reading is "what character is this" — the model hands you a pile of text boxes, each with a string and a confidence. At that point you have scattered blocks of text; which line they sit on in the original, whether they're the same paragraph, whether they're the same column of a table — the recognition output doesn't directly contain any of that.
Rebuilding layout leans on the geometry between boxes. ImgIng does it from box overlap, line height, horizontal spacing and vertical gaps, to recover the visual rows, paragraphs and table columns. This isn't the recognition model's job, it's a separate reconstruction layer after it: which boxes on one baseline count as a row, how much gap counts as a new paragraph, how many horizontally-aligned boxes count as columns. However accurately it read the characters, if this layer is wrong the output still collapses.
Only after rebuilding does output mean anything. There are four: copy-with-layout keeps the original rows and columns; TXT keeps rows by newline and separates table columns with Tab; Markdown emits a table when the column structure is stable; and coordinate JSON carries each block's position and confidence. Four, because downstream wants different things — Excel wants Tab-separated, a document wants a Markdown table, post-processing wants coordinate JSON. All of these are products of the layout step; recognition can't give them.
One detail I got bitten by: why Tab-separated columns and not spaces. Spaces already exist in the text — between characters, between words — so using them as a column delimiter breaks the moment content contains a space. Tab almost never appears in body text, so it's a clean column boundary; pasted into Excel each Tab jumps one cell and the columns line up. That unglamorous choice is exactly what the layout layer has to worry about — the recognition model doesn't care where you paste it next.
The counter, so I don't oversell it: layout reconstruction is rule-based geometry, so merged cells spanning rows, nested tables, arbitrarily complex table relationships push past the rules. ImgIng scopes those out and flags row-spanning merges and low confidence to check by hand. That boundary confirms the point: rebuilding layout is a hard, independent problem, not "gets automatic once reading is accurate".
So when you evaluate an OCR tool, don't just check reading accuracy — that's table stakes. What separates them is how well they rebuild the layout and whether they hand you structured output you can use directly. Reading is step one; rebuilding layout is where the real difficulty, and the real value, is.
Top comments (0)