表格 OCR 結構：為何我寧願取得文字框，而非以 Tab 分隔的文字

Should an OCR engine hand back a table, or just word boxes and let the caller build the table? OCR is not my area, so I read it as a caller would: I cut columns out of one set of word boxes through three interfaces. Short version: I'd rather get boxes. Setup: tesseract 5.5.3, English pack, three clean tables I generated (63, 63 and 45 cells), and one browser OCR tool. Every number below belongs to those samples.

Plain text has already lost the columns

First interface: text only. I grouped tesseract's boxes into rows, joined each row's words with single spaces, and split on whitespace. Cell accuracy was 16%, 33% and 84% on the three tables. Cells here contain spaces: Steel Thermos, Power Bank, a full name, a report title.

Second interface: the engine inserts a tab wherever the space between two words exceeds 1.0 times the median word height, and the caller splits on tabs. That gave 84%, 100% and 91%, the same as cutting the boxes myself at that threshold, because it is the same decision.

A tab freezes a threshold the caller can't move

The difference shows up when the caller can move the threshold. With boxes in hand I swept it from 0.4 to 2.0 times word height, scoring each setting against the ground-truth cells.

for k in (0.4, 0.6, 0.8, 1.0, 1.2, 1.5, 2.0):
    cells = [cut_row(r, k * med_h) for r in rows]
    print(k, score(truth, cells))

On the bordered score table, 0.6 gave 100% against 84% at 1.0. On the borderless quote table, 0.6 to 1.2 gave 100% and 1.5 dropped to 11%. The merged-header table sat at 91% across most of the range. The 1.0 was fixed in advance and 0.6 turned up afterwards on the same samples, so it is no recommended value. It only shows that a fixed number costs something on some tables, and behind a tab-only interface nobody finds out.

The same tool flipped which separator works

For the browser tool I used ImgIng (https://imging.ai/) on a desktop, the default Professional model, and copied out the text. On the three Chinese tables all 171 cells came back right, and rows mostly came back right too: 9 lines for a 9-row table on five of the six clear images and 10 on the sixth, with no tuning on my side.

Columns were looser. The score and quote tables have 7 columns, and tabs split most rows into only 2 to 6 cells. I rescored four of the tables by splitting the text two ways.

The better rule flips between the Chinese and English version of the score table. A script that consumes this text has to pick a rule before it sees the table. That doesn't make it worse than tesseract, since the two work differently, and I can't see why the separators fall where they do. I only looked at its copy and TXT output, so what I say is about that channel. It runs only in a desktop browser, doesn't read Korean, and numbers still need checking by eye.

What only the pixels know

Boxes don't contain everything. Ruling lines live in the pixels. Run straight on the bordered score table, tesseract found 1 of 63 cell texts; after I painted the lines white, 62 of 63. For a photo of a table taken at an angle, rotating the image was not enough on the borderless sheet: 0% to 11% after rotation, 86% to 92% after rotation plus a perspective fix. Those photos are my simulation, not real shots. The same simulated shots came out of the browser tool as one scrambled line each, and its page offers only 90-degree rotation, so I had no way to give it a hint.

That points to two stages. Pixel evidence such as lines and perspective belongs before recognition. Geometry from boxes belongs after it, where the code can see every box at once.

Slope is a number you get from all the boxes

In the middle panel the right end of each row has drifted from the left end, so the same row is cut in two and 9 rows become 18. The right panel subtracts an estimated slope from every y first, and 9 rows come back.

What I'd ask an engine to return

Boxes with confidence in input pixels, word height, and the skew estimate if it has one. Structure assembly then runs where thresholds can be tuned and failures told apart: a header glued into one string might be a recognition or a gap problem, and text can't say which.

I haven't tested a learned table-structure model, which could use cues that boxes lose. The samples are clean, English-only for tesseract, and no spreadsheet program was involved.