Extract Document Text
Reads a source document page by page, so the values a form needs can be located rather than guessed.
Overview
Every filled form starts as somebody else's document. A prior appraisal, an invitation to bid, a carrier declaration page, a purchase contract, a letter that arrived as a phone photo of a printout. The values the form needs are in there somewhere. Getting them out starts with reading the document.
Normally this is where you would have to care what kind of file you sent. A digitally produced PDF carries its text inside the file; a scan carries only a picture of text, with no readable characters in it at all. That difference is invisible to anyone looking at the page and it usually decides whether a document can be used.
Here it doesn't, because every page is read the same way: rendered as an image and read from the image. A twelve-page contract with a scanned appendix bolted onto the end is not two problems. It is one document, read page by page, and what comes back is keyed to the page it came from.
What It Does
| Capability | What it means for you |
|---|---|
| Scans and digital files, one path | There is no separate route for a scan, so a photocopied appendix is as usable as a typed page and you don't have to know which you sent |
| Read page by page | Each page is read on its own, so a mixed file needs no splitting and no sorting first |
| Answers stay traceable | Text comes back keyed to its page number, so a value can be traced to where it was found |
| Watermark removal runs first | Pages go through watermark removal before they are read, so an overlay it can handle is gone before anyone tries to read through it |
| Resolution set per workspace | How finely pages are rendered is a setting on your workspace, so a workflow full of dense small print can be turned up |
| Word and RTF included | Those are converted first and then take exactly the same path, so they behave like a PDF rather than a special case |
When This Runs
Nothing selects this. Reading the sources is part of preparing a fill — it happens to every uploaded source document, before any field is written, and neither you nor the agent decides to invoke it.
What is decided, by the file's type, is which route it takes:
- PDFs, Word documents and RTF files are read page by page. Word and RTF are converted to PDF first, and from there they are indistinguishable from a PDF.
- Images — a photographed page, a screenshot — are read as a single unit. They work as sources, but there are no page numbers to key the result to.
- Spreadsheets, CSVs and plain text never come through here at all. They are read as text or as rows, which is the point: flattening a rent roll into prose would destroy the structure that makes it useful. See Read Spreadsheet Records.
Photographs and diagrams are a different problem entirely — those go to Extract and Place Images.
Inputs and Outputs
Takes: a source document — a PDF, a scan, or a file converted to one.
Returns: the document's text, keyed by page number.
Pages that produce nothing are left out of the result rather than returned as blanks. That includes a page that genuinely is blank and a page whose reading failed, which come back identically — so an unexpected gap in the page numbers is worth a look rather than an assumption.
Example
A contractor uploads a 40-page invitation to bid published by a city housing agency. Pages 1 to 14 are the agency's digitally generated solicitation. Pages 15 to 40 are an appendix — prevailing wage schedules and a site sketch — scanned from paper at some point in the last decade and reused ever since.
Nothing about that mix needs handling. All 40 pages are rendered and read the same way, and the text comes back keyed to the page it came from — so the solicitation number and the wage schedule are each traceable to their own page rather than arriving as one undifferentiated block of text.
Two of the appendix pages are blank separator sheets. They produce nothing, so they are simply absent from the result — the page numbers jump, which is the only signal that they were there.
Limits
- Reading is not understanding. This step produces the words that were on each page. Working out which word is the insured's name and which is the producer's happens during filling, not here.
- A failed page looks like an empty one. If reading a page doesn't work, that page comes back empty and the rest of the document continues. Nothing marks it as having failed rather than having been blank.
- Encrypted files are not handled. A password-protected PDF has no path through this step and surfaces as a generic failure, not as a prompt for the password.
- Images give up their page structure. A photographed page is read as one piece, so nothing ties a value back to a page number the way a PDF does.
- It does not extract images. Photos, logos, sketches and signature graphics are a separate operation.
FAQ
Can it read scanned PDFs?
Yes, and it takes no special handling on your part. Every page is read from a rendered image of that page, so a scan and a digitally produced page go through exactly the same step. A file that is partly one and partly the other needs no splitting.
Do I need to run this before filling a form?
No. Reading the sources is part of preparing a fill and happens on its own. This page documents what that step does, not a button you press.
What about Word documents, images and other formats?
Word and RTF files are converted to PDF first and then read exactly like a PDF. Images are read too, but as a single unit rather than page by page. Spreadsheets, CSVs and plain text take a different route entirely, because reading rows and columns as prose would lose the structure that makes them worth having.