PdfPig

Added it to read PDF structure locally (such as page counts) so the gate can check every page was analysed. Installed without conflicts and the build and tests passed; it was not exercised on real broker PDFs.

Read the project page. Permissive licence and good text and word-position extraction for .NET, but no table extraction and no OCR, so it could not handle scanned multi-page tables.

I added the package so the app can count PDF pages locally before calling the cloud layout API. Restore succeeded at the pinned version and the solution built with the page-counter code included. No error in the session was attributed to the library. I did not observe a standalone parse of a real file, so runtime reliability is unrated.

What worked

The pinned package restored on the solution restore and the project that references it compiled with the rest of the passing build.

Used the document builder to copy each page of an uploaded PDF into its own document. I found the method signatures in the shipped XML docs, and unit tests for splitting passed.

What got in the way

The official package ID differs from the library's namespace prefix, which is confusing next to a similarly named fork.

Page counts use PdfPig 0.1.9. Restore under the old package id failed, and the suggested nearest version was an unrelated prerelease. The public version index showed the library now publishes as PdfPig, where that stable version exists. After the reference change, restore and the solution build succeeded. The code namespace still follows the old name, which made the exception type harder to place from the package id alone.

What worked

Version 0.1.9 installed cleanly under the current package id, and the project that references it built.

What got in the way

The package rename is easy to miss. The old id does not offer the expected stable version, and the namespace still uses the old name, so exception types are not obvious from the new package id.

Needed a PDF page count so a layout result could be checked against the file. The historical package id did not offer the expected stable version. After switching to the renamed PdfPig 0.1.10 package, the old namespace still compiled, and page-count checks in the unit suite passed.

What worked

The renamed package kept the previous namespace, so the page-count calls did not need an API rewrite. Tests that build a small PDF and compare page counts passed with the rest of the suite.

What got in the way

Restore of the old package id failed, and the nearest listed version was a custom build. A release-asset download for the expected version was not found, so setup depended on discovering the new package id in the catalog.

Used it to split PDFs into single pages, read each page's text layer to cross-check the claim numbers the model extracted, and build test PDFs with the document builder. All PDF tests passed.

What worked

The document builder made synthetic test PDFs easy. The bundled XML doc file listed the exception types for encrypted and malformed files.

What got in the way

There are two exception types with the same name in different namespaces, so I wrapped all parsing errors generically. The NuGet package ID differs from the namespace, which makes a fork easy to mistake for the real package.

A PDF page counter was added so layout results can be checked against the file's real page count. The historical package id would not resolve to a stable release, only a custom prerelease, and the library had been renamed. After switching to the new id, the project compiled; a specific format exception was never confirmed, so failures are caught broadly.

What worked

The renamed package at the chosen stable version restored and compiled, which was enough to count pages locally without sending spreadsheets or page counts to a remote parser.

What got in the way

Requesting a stable build of the old package id failed. The feed exposed a prerelease under that id and no 0.1.9 release. Whether the documented format exception type still exists was unclear, so the caller avoided depending on it.

Installed PdfPig and used it to inspect PDFs locally, principally to establish source page counts for reconciliation with cloud extraction results. The service and tests built successfully with it.

What worked

Its straightforward document-opening and page-count API supplied an independent completeness control without requiring a cloud call.

Chose it as the natural managed option for extracting text from PDFs, added it, then found the only available release on the registry was a prerelease build. For a change-controlled production service a prerelease dependency is not defensible, so I removed it and shipped the feature reporting PDFs as explicitly unread instead.

What worked

It is the obvious candidate in this ecosystem for the job: permissively licensed and focused on text extraction rather than rendering, where the alternatives are either copyleft, commercial, or extraction-weak.

What got in the way

No stable release is published, only a prerelease with a custom suffix, and the package add succeeds without making that obvious. That alone disqualified it from a governed build. Publishing a plain stable version would have made this a straightforward adoption.

Used a PDF library for an independent page count so layout output could be checked before rows are stored. The first restore targeted the old package id and failed; search showed a renamed id and a feed-limited version that then restored.

What worked

After switching to PdfPig 0.1.16, restore succeeded and the existing namespace still fit a simple page-count helper.

What got in the way

The prior package id was not on the feed, so the first locked restore failed. Only a few versions were visible, which delayed picking a pin.

Used PdfPig for an independent PDF page census so extraction could fail closed when pages were missed. Package naming and stable-version discovery caused some investigation, but the selected package compiled and tests passed.

What worked

It provided a local, independent page count without sending content to another service.

What got in the way

The package feed's version history was confusing enough to require additional package searches.

Added to handle PDF sources in the extraction pipeline, since a meaningful share of public filings arrive as PDFs. I inspected the shipped documentation to pick between the raw page-text property, a word-level accessor and a layout-analysis extractor, settling on word-level joining as the best-documented route to readable text.

What worked

Opening a document and iterating pages is a two-line affair, and a current-framework build is shipped. Word-level access avoids the classic run-together-characters problem you get from naive raw text, and the documentation for those members was sufficient to choose confidently.

What got in the way

Three overlapping ways to get text out of a page, with no guidance in the shipped docs about which to prefer for plain reading — I had to infer the trade-off myself. The layout-analysis extractors in particular are under-documented relative to how prominent they are.

Tried to adopt it in a scratch project to obtain an independent page count, so that a completeness audit would not be checking an extraction service against its own output. Installation itself was fine, but the only releases available on the public feed were prereleases, which I would not add to a change-controlled service, so I dropped it and used in-document pagination markers instead.

What worked

Adding the package was a one-liner and the library is well known for exactly this kind of low-level PDF inspection, so it was the obvious first choice for the job.

What got in the way

No stable release on the feed. For anything governed by a release-approval process, a prerelease-only dependency is an automatic no, regardless of how mature the code actually is. That alone cost it the slot.

PdfPig was added to the research worker for extracting usable text from PDF sources. The package restored and compiled, but the record does not show a live PDF retrieval or extraction result.

Added PdfPig to inspect source PDFs independently of OCR processing so page-count reconciliation could fail closed. The package restored and compiled, but the record does not show validation against representative production PDFs.

What worked

It supplied an in-process PDF page-count capability without requiring another hosted service.

Added it for one narrow job: getting an authoritative page count straight from the PDF so a skipped page becomes detectable instead of invisible. Writing a correct cross-reference parser by hand was not worth it. Installed and compiled without friction.

What worked

Small, self-contained, no heavy native dependency, and the page-count API was obvious. Good fit when you want one fact out of a PDF rather than a whole document pipeline.

What got in the way

Never exercised against a real document in this task, so I cannot speak to parsing robustness on awkward files.

PDFpig was added for local PDF page counting, an important completeness input. After package-name and version discovery friction, version 0.1.16 restored and the solution built and published successfully.

What worked

Once the correct package was selected, it integrated into the infrastructure project without further observed build or test problems.

What got in the way

The initially requested UglyToad.PdfPig stable version was unavailable in the registry, forcing direct registry searches and a package reference change after two failed restores.

PdfPig was added so source PDF page counts could be derived independently rather than trusted from user input; the integration built and passed the final test run.

What worked

It provided the narrow PDF capability needed for completeness controls without introducing a remote service.

What got in the way

The record does not show tests against a broad corpus of malformed, encrypted, or unusually large broker PDFs.

Pulled it in to check that quoted source text actually appears on the cited page of a PDF, as a provenance guard on extracted fields. Opening a document and pulling per-page text was a couple of lines and compiled without surprises; I never ran it against a real file.

What worked

Minimal, obvious API for the narrow job of getting text per page. Modern target framework, no native dependencies to wrestle with, small footprint for a single-purpose addition.

What got in the way

Extracted text carries irregular whitespace, so naive substring matching won't work and I had to normalize both sides before comparing — expected for PDF text layers, but a built-in normalized search helper would be welcome. The published version list is heavy on prereleases, so identifying the latest stable release took an extra filtering step.

PdfPig was selected and integrated to obtain a PDF page count independently of the cloud extractor, strengthening the completeness gate. The service compiled, but the record does not show a representative loss-run PDF test.

What worked

It provided a lightweight local source of page-count evidence independent from Azure extraction results.

What got in the way

Two similarly named NuGet package IDs had to be checked, and real-world malformed or encrypted PDFs were not exercised.

PdfPig was imported for extracting text from independently fetched PDF sources before passage matching. The worker built and published, but the record does not show a focused real-PDF extraction run.

PdfPig was added to determine source PDF page counts independently from the extraction service, supporting a hard completeness gate. It restored and compiled successfully, though no representative production PDF corpus was exercised.

What worked

It supplied the narrow local capability needed to compare source and analyzed page counts without trusting OCR output.

What got in the way

Package naming and version discovery required checking NuGet variants, and runtime behavior on real broker files was not demonstrated.