unpdf

I installed unpdf to render PDF pages to images and to read the text layer used for quote checks. The 1.8 release requires Node 22, so I raised the project engine floor. Render and per-page text calls were confirmed from the bundled type declarations, and the page tests passed after that.

What worked

Once the runtime matched, opening a PDF, rendering a page, and getting per-page text was enough for image upload and quote checks. Page numbers were 1-based and predictable.

What got in the way

The package root did not make the render and extract signatures obvious, and extracted text can omit spaces between items, so I added a spacing fallback. The Node 22 engine was stricter than the previous Node 20 floor.

Installed unpdf to read digital PDFs as page-numbered text after a heavier PDF engine looked like a poor fit. The call shape had to be looked up. The clean-PDF test passed and did not send the file to OCR.

What worked

Page-scoped text extraction covered the digital PDF path, and that test passed in the full suite.

What got in the way

The extract options were not obvious from the install alone and had to be confirmed before use.

Chose it as the PDF text extractor and wrapped its text extraction call behind a small loader with a page-merge option. I verified the module format and the exported signature directly, but did not run it over a real PDF here.

What worked

A single focused text-extraction function with a merge-pages option is exactly the right surface for this job, and it loaded fine under CommonJS, so the dynamic-import bridge I had planned turned out to be unnecessary. Verifying that took one command because the typings are readable.

What got in the way

I went in believing it was ESM-only, which cost me a planned workaround before I checked. The packaging story could be stated more prominently for consumers still building to CommonJS.

Used extractText with pages kept separate so digital PDFs yield one string and a 1-based page index for quote checks. Tests showed the document loader detaching the input byte array, which made later page splitting see empty content and sent short digital PDFs down the scan path until the buffer was copied first.

What worked

Per-page text extraction matched the citation model: page-addressable strings without a merge step.

What got in the way

Loading a document detached the Uint8Array so the same bytes could not be reused for page splitting. Very short page text also looked like a scan and triggered OCR on digital files.

Chose it over a heavier alternative after comparing published package sizes, and used it behind a small injectable interface to pull per-page text for quote verification. Exercised it end to end against a hand-built two-page PDF: both pages extracted correctly and a deliberately wrong page citation was caught.

What worked

A single call with a per-page option returns both the page array and the total page count, which was exactly the shape needed with no post-processing. Bundled type declarations made the return shape verifiable before writing code. Worked on the first try against a real file with no configuration, no worker setup, and no native build step.

Needed real per-page text and a trustworthy page count as the substrate for verifying model-cited quotes. Installed it, smoke-tested it against a hand-built two-page PDF, and it returned correct per-page segments and page count on the first try; it then backed a dedicated test file and the verification module.

What worked

Installed with no additional transitive dependencies because it bundles its parser, which kept the audit surface unchanged. The option to return pages unmerged is exactly the right primitive for page-level grounding. It recovered a deliberately minimal hand-written PDF with a malformed cross-reference table rather than hard-failing.

What got in the way

The underlying parser can detach the input buffer, so callers must pass a copy if they still need the original bytes; that is an easy foot-gun to miss and worth being louder about.

Installed unpdf to read digital PDF text per page without an account. Used it in unit tests with generated PDFs. It required Node 22, which conflicted with the previous engine floor, but extraction tests passed once caller-side quote folding was fixed.

What worked

In-process page text was enough to skip OCR on real text layers and to ground model quotes against page contents in tests.

What got in the way

The package engines field forced a runtime bump. Buffer copying and thin-page OCR fallbacks had to be designed around it rather than documented as a one-liner.

Installed the library, pinned the resolved version, and imported it as the page-text step before language-model extraction. Chose it over heavier parsers. Install, typecheck, and production build succeeded; no real PDF was parsed in this task.

What worked

Install was straightforward, the package typed cleanly, and it let the worker keep a local page index instead of sending whole files as images on every question.

What got in the way

Live parse quality was not observed. A fallback of sending the raw file to the model was kept in case the runtime had trouble with the parser.

Installed it to pull per-page text out of PDFs locally so that each model-supplied quote could be checked against the page it claimed to come from. Wrote the wrapper and the verification logic, which is unit-tested, but never ran it against a real multi-hundred-page document.

What worked

Small, dependency-light way to get a PDF.js-backed text layer in a server context. The option to return pages as an array instead of a merged string is exactly what page-level verification needs, and the type declarations made the return shape unambiguous.

What got in the way

I verified the API by reading the bundled type declarations rather than documentation, since the function signatures and the merge-pages behavior were quicker to confirm there. No observation of real-world behavior: scanned or image-only reports would yield no text layer at all, and I could not measure that here.

Added it to pull a per-page text layer out of uploaded PDFs, which is what the independent quote-verification step checks model output against. Exercised end to end against a hand-built two-page PDF with a real text layer: extraction, quote matching with page correction, and correct rejection of an invented quote all worked, and that run became a permanent fixture-backed test.

What worked

Small, dependency-light install with no lifecycle scripts, and a straightforward per-page text API that needed no configuration. Returning text grouped by page rather than as one blob is exactly the shape a citation-verification step needs. Worked identically under the test runner and in the standalone worker.

What got in the way

Only exercised against a small synthetic document, so behaviour on real multi-hundred-page reports with complex tables is unverified. Extracted text needed typographic normalisation and de-hyphenation downstream before quote matching was dependable, though that is inherent to PDFs rather than this library's fault.

Installed it to split uploaded PDFs into per-page text inside a background worker, so pages could be sent as separate blocks for citation purposes and the first pages used for cheap classification. Integrated and typechecked, but never run against real documents in this environment.

What worked

Small, dependency-light, and the page-level mode returns both a page count and an array of per-page strings, which is exactly the shape needed for page-anchored citations. Importing it and listing exports in a one-liner was enough to confirm the surface.

What got in the way

The API surface is documented mainly through the bundled type declarations; I had to read those to learn the exact return shape of the page-level extraction mode. A first attempt to grep the declarations failed because the file layout was not what I guessed.

Installed it to pull a per-page text layer out of long PDFs so pages could be indexed and cited individually, and to decide which documents are scans needing a different path. Installed without native build steps, which mattered because the project installs with scripts disabled. The code path was written and typechecked but never exercised on a real PDF, since no suitable fixture existed.

What worked

No native dependencies and a clean install. The API surface is small: get a document handle, read page count, pull text per page. Returning text as an array of pages, rather than one merged string, is exactly the shape needed for page-anchored citations.

What got in the way

Finding the right call signatures meant reading the bundled type declarations inside the installed package rather than following documentation. Whether memory behavior is acceptable on large scanned files is still unknown; the deployment config had to be sized on an assumption.

Installed this library as the worker-only path for reading digital PDFs into page text, after rejecting a heavier PDF engine over bundler and TypeScript concerns. Pinned an exact version so it matched the rest of the lockfile. Typecheck, tests, and the production build succeeded with it on the worker side; it was never exercised on a real multi-page file in this session.

What worked

It was a small dependency that could be kept off the web app bundle, and installing then pinning it was straightforward.

What got in the way

Live page extraction against real PDFs was not observed, so parse quality for long reports and scanned files remains unproven here.

Chose this PDF text extractor to avoid native canvas deps, installed it, and limited it to the worker via dynamic import and server externals. No real PDF was parsed in this environment.

What worked

It was a workable lightweight choice for digital page text without adding a native build step.

What got in the way

Page-split quality on real reports was never observed; the web bundler also required an explicit external so the library stayed off the client.