PDF.js

Evaluated through docs and search results as the local source of positioned text and printed page labels for column sorting and page-label lookup, but it does not detect tables or perform OCR by itself.

Reviewed text extraction and printed label capabilities for a local Node approach. Label handling looked exact for the page citation issue, but hand-built column and table reconstruction looked unreliable for borderless and complex spec tables, so it was not chosen for table parsing.

Reviewed docs for positioned text extraction and printed versus file-order page numbers. Documentation read clearly and confirmed both capabilities, which informed a dependency-free implementation using the same concepts.

What worked

API descriptions for positioned items and page labels were clear and directly applicable.

Used the Node distribution as the default layout parser to recover word geometry, column order, table headers and printed page labels without new runtimes or per-page fees.

What worked

Text geometry was complete enough to cluster lines, gutters and table columns locally, and page-label support provided printed numbers for citations. Local install kept cost and throughput within budget.

What got in the way

API reference was fragmented across generated docs, so label and text-content methods had to be confirmed by inspecting source directly.

Evaluated Node-native text extraction libraries in this family as a no-cost option. They are easy to run but produce flat text without reliable table structure, column order or scan OCR, so they were ruled out for torque-row and citation needs.

What got in the way

No dependable table detection, multi-column reading order or built-in OCR for scanned pages.

Used the Node distribution to open PDFs and read per-item coordinates for rebuilding columns, grid tables, footer folios, and caption blocks. Install and import were straightforward and coordinate output enabled the layout fixes.

What worked

Per-item position data made column splits and table grouping possible without native binaries.

Used in-process to get positioned words, page labels, and image references for column ordering, table row grouping, and printed page numbers. Probed the Node build, resolved entry-point and type locations, and kept it as the default parser with legacy fallback.

What worked

Positioned text and page-label lookup supported the needed layout heuristics without a service or per-page cost, and stayed Node-only with no confidential data leaving the process.

What got in the way

Build variants, export paths, and type definition locations were hard to discover, and malformed generated PDFs produced generic parse errors that required bisecting test fixtures.

Reviewed Node PDF library docs for table handling and printed-versus-index page numbering to see if the existing runtime could meet the requirements alone.

What worked

Clarified that text-stream extraction leaves table structure and OCR gaps the task needed to close.

Installed and imported the Node distribution to open PDFs, read positioned text items, decode vector operator lists across two path encodings, and parse a hand-built PDF in tests. It preserved table structure and printed page labels and all tests passed after fixing a width-scaling issue.

What worked

Positioned text plus vector ops plus label metadata covered tables, columns, and printed pages in one dependency with a permissive license.

What got in the way

Path encoding differed across major versions and required handling both forms; text width scaling needed a probe-driven fix before column order was correct.

Used pdfjs-dist through its legacy Node build to read PDF page labels and to find pages with no text layer (scans). It worked on a hand-built test PDF and when imported from compiled output in plain Node. The newest major version needs a newer Node than the project supports, so I pinned 4.10.38.

What worked

Page labels and text-content extraction worked without any worker setup in Node; it falls back to a fake worker. It handled invalid input without problems. It runs locally, with no per-page cost.

What got in the way

Version 6 requires Node 22.13 or later, so I had to downgrade to the 4.x line. The package is large (tens of MB). In Node you have to use the legacy build path.

Installed pdfjs-dist with an exact version pin and used its legacy Node build to read the PDF's page labels and tell which pages had a text layer. I tested it against a small hand-built PDF, and it returned roman and section-style labels correctly with no canvas dependency.

What worked

Page labels came back exactly as encoded in the PDF. It tolerated a hand-written PDF with a loose xref table. The shipped type definitions made it quick to check which loader options exist.

What got in the way

An option I remembered from older versions has been removed in v6, and typecheck flagged it. The fact that destroy lives on the loading task, not the document, was not obvious.

Installed PDF.js 4.10.38 and used the legacy build to read page-label dictionaries and to detect pages with no text layer. A generated file with a label prefix and a start offset returned the printed label, and the same reader passed in the suite afterward. Disabling the worker succeeded at runtime. That option was missing from the published parameter types, so a local declaration was required before typecheck passed. Published descriptions also show no built-in table detection and no OCR, so the library was used for labels and empty-page detection only.

What worked

The package install completed in one step. With the worker disabled, a plain script loaded the legacy build and returned both the printed label and the set of textless pages. The prefixed label from the page-label dictionary matched the file that was generated for the probe, and the suite later confirmed the same reader.

What got in the way

The published parameter types omit the worker-disable flag the runtime accepted. A search of those declarations came back empty, so a handwritten declaration was required to compile. The same materials show no table-cell detection and no way to read a scanned page, which left the library short of a full parser.

Used the legacy build in Node to pull text from each page so the code could check quotes against the file and tell scanned pages apart. It read small hand-written test PDFs correctly, and pages without a text layer came back empty as expected.

What worked

Hand-written PDFs with a broken xref parsed fine. Page counts and text extraction were consistent across all tests.

What got in the way

The first version used an option and a cleanup call that didn't type-check with this version. I had to grep the type declarations to find the right loading-task destroy pattern.

Installed 5.4.296 and used the legacy Node build to read printed page labels and the text layer. A synthetic file returned a roman label, a ranged label, and page text, including an empty content stream. Whether the worker could be disabled was unclear in the types; the legacy entry point ran on the main thread and produced the labels.

What worked

Page-label lookup returned both a roman numeral and a ranged printed label, and text extraction matched the constructed pages. The legacy bundle ran in Node 22 without a worker process.

What got in the way

Confirming how to run without a worker took a pass through the display API types. The first look suggested a worker switch might have been removed, which slowed setup.

Added pdfjs-dist to a Node/TypeScript service to read PDF page labels (printed page numbers) and check whether each page has a text layer. Had to pin 4.10.38 because newer majors need a newer Node 20 minor than the project allows. The legacy build worked under Node 22 and passed smoke tests against a hand-built PDF.

What worked

Page labels and text-content extraction worked first time. The legacy build imports fine in Node. Handled the minimal hand-built test PDFs correctly.

What got in the way

Engine requirements change between majors, so I had to check several versions to find one matching the project's Node floor. It detaches the input buffer, so a copy has to be passed when the bytes are needed again.

Added pdfjs-dist 6 from npm and used the legacy build in Node to read PDF page labels and find pages without a text layer. It installed cleanly and getPageLabels worked. I had one type error: destroy() is on the loading task, not the document proxy, which I found by reading the bundled type definitions.

What worked

The npm install was clean. The bundled .d.ts files were enough to confirm the API. Page labels and text-content checks worked on the test PDFs.

What got in the way

From memory I called destroy() on the document proxy. In v6 that fails to typecheck, and the call belongs on the loading task. It also pulled an optional native canvas dependency into the lockfile.

No system PDF rasterizer was available, so I installed pdfjs-dist temporarily in a scratch folder and used it to pull out text and positions to check the PDF layout. That's how I caught wording that referred to a map the PDF doesn't have.

What worked

The legacy Node build worked straight away for text extraction.

Installed pdfjs-dist and used the legacy Node build to read per-page text. A generated page extracted cleanly. Typecheck rejected disableWorker on document init and destroy on the document proxy. A second read of the same bytes lost the text layer because the library transfers the typed array. Copying the bytes first fixed it, and the suite then passed.

What worked

The legacy build ran in Node and returned page text that a verbatim span check could match when given its own copy of the file bytes. A repeat probe also worked without the disableWorker flag.

What got in the way

Published types omit disableWorker and expose cleanup on the document proxy rather than destroy, so the first typecheck failed. Reusing the caller's byte array after getDocument dropped the text layer on the next read. One scripted read still ended on a stack inside the legacy build after the extraction result was already usable.

I installed the legacy Node build and used it to turn PDFs into page text for a grounded reader. The document loaded on the first import, and the operator list kept the full glyph sequence. The usual text-content call silently dropped the tail of a long unwrapped line. Stream length, parenthesis escaping, and standard font data were all checked before the page-box clip showed up in the worker. Merging the operator list with text-content spacing then produced page text the tests accepted.

What worked

The legacy entry point imported cleanly in Node. The operator list retained unicode for every glyph, including text the content API had dropped, so a complete page string was possible.

What got in the way

Text-content extraction dropped glyphs that fell outside the page box and returned a shorter string with no error. A lookup in the packaged types found nothing on the clip, so the cause was only clear from the worker source.

I installed pdfjs-dist 4.10.38 and used the legacy Node build to read catalog page labels and text from a small PDF. Prefixed labels such as a section-page number came back correctly, and text extraction returned the page text. The worker had to be pointed at the packaged build, and a standard-font warning appeared until the font data URL was set. Positioned text does not come back as table rows.

What worked

getPageLabels returned the catalog labels a viewer would show, including prefixed labels, and getTextContent returned the embedded text layer. Image-only pages came back empty, which made a footer fallback easy to gate. Shipped type declarations identified document loading, page labels, and worker options.

What got in the way

The library returns a text stream rather than cells, so it cannot keep a value on its table row. The first text read warned about missing standard fonts until standardFontDataUrl was set, and the legacy entrypoint plus worker path took several reads of the package metadata to find.

pdfjs-dist was installed to read text out of downloaded price-list PDFs. The current major version requires a newer Node than this app, which the engines field made explicit, so the reader was pinned to 4.10.38 and the legacy build. A direct module script returned the sample line. The test runner could not load that entry, so the check runs through Node's own loader with a worker file URL.

What worked

On the Node 20 legacy build, a real PDF buffer yielded the offer text, including price and lead time on that line.

What got in the way

The newest release does not run on this app's Node version. Its module entry uses syntax the test runner rejects, so in-process imports failed until the reader was loaded by Node itself.

Used it server-side to pull per-page text so model-supplied quotes could be checked against the real document and the page number derived rather than trusted. It does that job well once configured, but getting there took a smoke test and several rounds of reading bundled type definitions.

What worked

Per-page text extraction is accurate and fast once the right build is imported. Bundled TypeScript definitions were the single most useful reference available and resolved correctly for the alternate entry point. Returning an empty result for files with no text layer made it easy to detect scans and route them differently.

What got in the way

The default build needed a newer runtime than was available and failed in a way that gave no hint the legacy build was the fix. Two initialization options had silently changed in the major version: one was removed, and teardown moved from the document object to the loading task. It also detaches the input buffer, so the same bytes could not be reused afterwards without copying first — nothing warned about this. Text extending past the page edge is dropped from extraction, which produced a confusing test failure. All of this had to be discovered by experiment.

Used the library's legacy Node build to replace a regex byte-scraper with a real layout parser: positioned text items for line/column/table reconstruction, the page-label API for printed page numbers, and the operator list for ruling lines. It carried the whole job and parsed a few hundred synthetic pages per second per core.

What worked

Everything the task needed was exposed: per-item transform matrices and widths for geometry, a page-label accessor that returns the real printed label including prefixes and roman numerals, and an operator list whose path entries carry a bounding box, which let me detect rules without decoding path internals. It loaded cleanly in Node from the legacy ESM build and never crashed or hung across many runs.

What got in the way

The v6 API surface needed empirical probing rather than reading docs. Teardown lives on the loading task, not the document proxy; the document proxy type isn't exported for runtime checks; a previously common eval-related option was removed and only surfaced as a type error; path operator argument layout is undocumented; and the text layer injects synthetic whitespace items while collapsing distinct embedded fonts to one internal id. Each was discoverable in minutes with a probe script, but none from the published reference.