Pdf Pack Laravel Package

Product Decisions This Supports

• Build vs. buy for document ingestion: pdf-pack gives us page-count/metadata, per-page text extraction, and JPEG/PNG rasterization behind one small API, so the "buy" side of the decision is a Composer install plus a Poppler install rather than a six-week parsing project. It directly unblocks LLM/RAG ingestion work without committing us to a vendor contract.
• Roadmap sequencing for a "Document Intelligence" line: the package covers the lowest-value, highest-annoyance layer (getting bytes out of a PDF). That lets us schedule differentiation work — chunking strategy, retrieval quality, review UX — instead of scheduling PDF plumbing.
• Framework standardization: v0.9.0 merged the Symfony bundle into the main repository, so one dependency and one version line now serve both Laravel and Symfony services. For a mixed PHP estate this is a real consolidation win: one package to vet, patch, and track.
• Scope boundary on OCR: the package extracts text from digital-native PDFs and rasterizes pages, but does no OCR. That is a product decision we should make explicitly — rasterize here, hand images to Tesseract/Textract, rather than quietly assuming scanned documents will work.
• Async pipeline design: per-page \Generator output maps cleanly onto queued jobs and chunked page ranges, which supports a roadmap item like "large PDFs don't time out or OOM the worker" without new infrastructure.
• Vendor-risk decision: 4 stars and 0 dependents means no ecosystem validation. That is an argument for adopting it behind our own interface, not an argument against using it.

When to Consider This Package

Adopt when:

• The workload is digital-native PDFs where pdftotext output is acceptable, and you may also need page images for visual checks or multimodal models.
• The team is PHP/Laravel (or Symfony) and already carries symfony/process transitively — the dependency footprint is genuinely one package plus three CLI binaries.
• You can install and pin Poppler in your base image and CI (poppler-utils; brew install poppler locally).
• You want to standardize on one PDF layer across Laravel and Symfony services and are willing to write a thin Laravel service provider and facade — the in-repo Symfony bundle is a usable blueprint for that wiring.
• You are optimizing for time-to-first-result on an internal tool or an AI preprocessing spike, and can accept a small, single-maintainer project.

Look elsewhere when:

• You need OCR, handwriting, or scanned-document support — go to Tesseract, Textract, or a document-AI API.
• You need structured extraction (tables, forms, key-value fields) — Tabula/Camelot-style tooling or a commercial parser.
• You need high-throughput batch processing at scale; per-invocation CLI process spawn is a real cost, and Python tooling is the better-studied path.
• Your runtime cannot own system-level dependencies (shared hosting, restricted PaaS) — a hosted API is the lower-risk answer.
• You require vendor support, SLAs, or a large contributor base. There are no dependents and effectively no community to lean on; you are adopting the maintainer, not the market.
• You need native Laravel ergonomics out of the box — there is still no auto-discovered provider, config stub, or queue example. Budget for that work or pick a package that ships it.

How to Pitch It (Stakeholders)

For executives: "We can start extracting text and page images from PDFs for our AI features in days, not months, using an MIT-licensed PHP library with one dependency. It's the ingestion layer under document Q&A and summarization — the part that isn't differentiated for us, so buying it as open source is the right call. Cost is engineering time plus a standard Linux package in our container image; no license fees, no vendor lock-in, and the code is small enough that we could fork it if the maintainer walks away. The honest caveats: it's a young project with one maintainer and almost no community, and it does not handle scanned documents — those need an OCR step we'd add later. My recommendation is to adopt it behind our own internal interface, which keeps the switching cost to a day if we ever need to replace it."

For engineering: "pdf-pack wraps pdfinfo, pdftoppm, and pdftotext through Symfony Process. Three capabilities: page count/metadata, per-page text extraction, per-page rasterization to JPEG or PNG. Results stream per page via \Generator, so we can hand pages straight to a job or an LLM chunker without holding the whole document in memory. Two integration paths — instantiate PopplerClient directly for prototypes, or build a container of ClientInterface via ClientFactory for anything we intend to test. As of v0.9.0 the Symfony bundle lives in this repo, which gives us a first-party reference for service registration and configuration to port into a Laravel provider; there's no reported API change, so it's a packaging move, not a rewrite. Three things we must handle ourselves: fail fast at boot if the Poppler binaries are missing rather than at first request; pin Poppler in the Docker base image and CI; and process in bounded page ranges per job with a process timeout, since the CLI tools aren't something we should assume are concurrency-safe. Wrap it in our own PdfExtractor contract so tests mock our interface instead of shelling out, and so the underlying library stays swappable."