PdfParser

Pulled in a pure-PHP PDF text extractor to get per-page text, used as the ground truth for checking whether a quoted snippet is actually printed on the page it claims. Integrated behind a small reader interface so tests could substitute fixed text; never exercised against real supplier PDFs in this environment.

What worked

Installed cleanly with no system dependencies, which matters for a pipeline that has to run on a plain application server. Per-page access is the right granularity for evidence checking, and the API was simple enough to wrap behind a one-method seam for testing.

What got in the way

Extracted text is lossy in ways you must defend against yourself — words broken across spans, inconsistent whitespace, unicode quote and dash variants — so any substring match needs a normalization layer written by hand. There is also no signal distinguishing a page with no text layer from a page that genuinely has no text, which matters a lot when the difference decides whether a scanned document is trusted; I had to infer it.

Pulled in to read the embedded text layer out of clean PDFs, which powers a free deterministic check that an extracted value literally appears in the source, and to supply a page count. Installed without fuss and behaved sensibly on malformed input during a wiring check rather than throwing.

What worked

Installed with no transitive conflicts and the API for opening a document and pulling text is about as small as it could be. Degrading gracefully on unparseable bytes mattered here, since half the expected inputs are photographs with no text layer at all and the code path has to fall through quietly. Page counts came essentially for free alongside the text.

What got in the way

Only exercised on synthetic and malformed input in this task, so its behavior across real-world supplier PDFs with unusual encodings is untested from my side.

Installed and wrote an adapter around it for the fast path of a three-tier extraction pipeline: PDFs that already carry a text layer are read in pure code, with no OCR binary and no extra container. Page-level access let me attach per-page provenance to the extracted text.

What worked

Pure-language implementation with no system binaries was exactly what the deployment constraints needed. The parse-to-document-to-pages API is small and obvious, and page-level text access made provenance mapping easy. Installed cleanly with no conflicts.

What got in the way

Failure behavior on encrypted or malformed files is not clearly documented, so I wrapped all calls defensively and translated anything thrown into a domain exception rather than relying on a documented error type. Memory behavior on large scanned files is also under-documented. I never ran it against a real PDF in this environment, so none of this is observed.

Chose and installed this as the PDF text-layer extractor behind a small interface of my own, specifically because it is pure PHP and needs no system packages or container image change in a locked-down environment. Installed cleanly and the page-level API was simple to wrap, but I never executed it against a real PDF because the test suite could not run.

What worked

Pure-PHP with no system dependency is the decisive property under image-freeze constraints, and the version pins into the lockfile like any other library. The object model exposes pages individually, which let me attribute extracted values to a page number without extra work.

What got in the way

It only reaches documents that already carry a text layer — genuinely scanned pages are out of scope, which I had to handle as an explicit failure state rather than a fallback. Quality on column-heavy layouts is the usual trade against a native extractor, and I had no way to measure it here. Capability score reflects fit under constraints, not observed extraction quality.

Chose it as the text-layer extractor specifically because it is pure library code with no external binary or sidecar, which the deployment constraints effectively required. Wrapped it behind a small extractor that takes raw bytes and a content type and returns text plus a truncation flag, and covered that wrapper with unit tests that passed.

What worked

Installing it was a single dependency add with no system packages, no sidecar container and no new deployment artifact — decisive given a locked-down registry policy. The parse-from-string entry point meant the extractor never needed a temp file or a database round trip, which kept it unit-testable. The only runtime prerequisite was a compression extension that was already present.

What got in the way

It only reads an existing text layer, so scanned and photographed documents yield nothing and must be routed to manual handling — an inherent scope limit rather than a defect, but it meant the pipeline could not cover a large share of real inputs. I also only exercised it against small synthetic fixtures, so behaviour on large or malformed real-world files is unproven.