From Coordinates to a Spreadsheet

FlyingMouse Format’s PDF-to-Excel path makes a hidden difficulty visible: a PDF may show a table without containing a spreadsheet model. This chapter explains how the project infers rows, columns, cells, merges, and page continuity from native text or OCR evidence, then decides whether the result is trustworthy enough for an XLSX workbook. The reader’s practical judgment is not whether the output has a familiar spreadsheet extension, but whether the geometry and confidence evidence support the cells that were created.

A PDF page contains clues, not necessarily cells

A spreadsheet stores rows and columns directly. A PDF often stores words at positions and lines as drawing elements. A human sees a table because the words align, the borders connect, and the page repeats a visual pattern. A converter must infer that pattern. It has to decide which words belong to the same row, which positions represent recurring columns, whether a line is a table border, and whether a blank space is intentional or merely part of the page layout.

FlyingMouse Format begins by distinguishing two kinds of page evidence. A native PDF page can expose text items and their coordinates through PDF.js. A scanned page has no usable text layer, so the project renders it and uses OCR blocks that include text, bounding boxes, and confidence information. These inputs are not equivalent. Native coordinates generally provide stronger evidence about the characters; OCR adds a recognition step whose errors can affect both the text and the geometry. The workbook path keeps that distinction attached to the page model.

The core pipeline is therefore not “read PDF, write XLSX.” It is closer to “collect evidence, infer a table, test the inference, and choose how much of it to publish.” That is the same boundary-management idea seen in PDF-to-Word, but here the destination’s grid makes wrong structure especially dangerous. A misplaced sentence in a document may be noticed during reading. A shifted amount or quantity in a spreadsheet can look orderly while changing the meaning of a record.

flowchart LR A[PDF page] --> B{Text evidence} B -->|Native coordinates| C[Words and positions] B -->|OCR blocks| D[Recognized text and confidence] C --> E[Rows, anchors, lines, and cells] D --> E E --> F[Continuation and merge checks] F --> G{Confidence and table gate} G -->|Supported| H[XLSX table sheet] G -->|No table or weak evidence| I[Raw sheet and warning]

The diagram shows why OCR is not simply a switch that makes every PDF equivalent to a native one. The two routes feed a common model, but their evidence carries different uncertainty. A table can be geometrically coherent and still contain OCR errors. A native page can contain accurate words but no explicit table semantics. The pipeline must account for both.

Turning lines, anchors, and words into cells

For bordered tables, vector lines provide a strong starting point. Horizontal and vertical segments can be normalized and grouped into connected components. Their positions produce candidate row and column boundaries.