terpstra-209 makes filled PDF forms searchable

The fork now captures answers entered into PDF form fields, not just the document's visible text.

intakesearch

Many legal forms store completed answers separately from the page text. That can leave a signed intake form, questionnaire, or filing looking almost blank to a chat assistant or document-extraction workflow.

terpstra-209 closes much of that gap by pulling non-empty form-field names and values from each PDF page alongside its ordinary text. The normal text extraction remains available if form-field access fails. There are limits: flattened forms and unusual widgets still depend on what the PDF reader can expose, and extracted labels may be technical field names rather than the labels visible on the form.

So what Legal teams handling completed PDFs should care because a form's answers can now become usable evidence and context instead of disappearing from search and chat.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from terpstra-209/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date

cf0b9277 fix(pdf): extract AcroForm field values, not just drawn page text terpstra-209 2026-08-26 ↗ GitHub

SHA	Subject	Author	Date
`cf0b9277`	fix(pdf): extract AcroForm field values, not just drawn page text	terpstra-209	2026-08-26	↗ GitHub
commit body extractPdfText only read page.getTextContent(), which is content-stream text - it never sees a filled-but-unflattened PDF form, since the values live in annotation field data (fieldName/fieldValue), not on the page itself. A PDF viewer that fills a form without flattening it (e.g. macOS Preview) produces exactly this: pdftotext reads the field values, but Mike's extractor returned the page as if it were blank, regardless of which LLM read it downstream. Now also read page.getAnnotations() per page and append any non-empty field values as a `[Page N form fields]` block. Annotation reads are wrapped in their own try/catch so one page's failure doesn't blank out already-extracted text for the rest of the document. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

commit body

extractPdfText only read page.getTextContent(), which is content-stream
text - it never sees a filled-but-unflattened PDF form, since the values
live in annotation field data (fieldName/fieldValue), not on the page
itself. A PDF viewer that fills a form without flattening it (e.g. macOS
Preview) produces exactly this: pdftotext reads the field values, but
Mike's extractor returned the page as if it were blank, regardless of
which LLM read it downstream.

Now also read page.getAnnotations() per page and append any non-empty
field values as a `[Page N form fields]` block. Annotation reads are
wrapped in their own try/catch so one page's failure doesn't blank out
already-extracted text for the rest of the document.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-1415.md from inside the repo you want the changes in.

⬇ Download capture-thread-1415.md