Diego Santos

My first move on any document is to check whether there is a text layer at all, because that single fact determines which tool you need. A PDF draws characters at coordinates. When it was produced from a word processor, those characters are usually accompanied by enough information to reconstruct reading order and fonts. When it was produced by scanning, there are no characters at all, only an image of them, and the file is a picture of a document. It opens, it prints, and every selection returns nothing. So the first tool is a text layer detector, and running one before attempting extraction saves an afternoon. Reading order is the problem when a layer does exist. A multi-column document stores text in whatever order it was drawn, which is often not the order it should be read. Extraction tools reorder using column detection, and the heuristics are imperfect. If you need guaranteed order, you need a layout-aware parser rather than a fast one. Tables are harder still, and worth being honest about. Recovering a table means identifying cell boundaries from the position and spacing of fragments, and a table with merged cells or a shaded header defeats a lot of that. For anything that has to be accurate, check a sample of rows against the original rather than trusting the whole extraction. Embedded objects are the part people forget. Attachments, annotations and form field values all live inside the file, and a tool that extracts only visible text silently drops them.