Pdf Pack Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for PDF ingestion: The reusable value here is not the bundle but the underlying 1tomany/pdf-pack library, which shells out to Poppler for three jobs: read metadata/page count (pdfinfo), rasterize pages to PNG/JPEG (pdftoppm), and extract text ranges (pdftotext). If the roadmap contains document ingestion, search indexing, or OCR prep, this replaces a multi-week internal build with a thin integration layer.
• Roadmap unlock for document-heavy features: Concretely supports invoice/receipt parsing, contract review pipelines, supplier catalog ingestion, LMS slide-to-searchable-content, and "preview thumbnail + page count" in any file-upload UI. These are usually separate roadmap items that collapse into one shared capability.
• Prioritization signal inside the pipeline: The extract API is page-ranged and returns a Generator, so large PDFs can be processed page-by-page rather than loaded whole. That makes per-page cost visible and lets you phase the roadmap — ship thumbnails and metadata first, defer full text search and ML extraction to a later cycle without re-architecting.
• Platform decision: PHP-native vs. JS-side rendering: Choosing server-side Poppler keeps parsing in your PHP deployable and avoids a Node/pdf.js service or a paid SaaS (Adobe Extract, Google Document AI). This is the main strategic fork this package informs.
• Vendor-risk decision: Adopt the library as a dependency, not this bundle. The bundle is a Symfony DI wrapper (autowires ExtractActionInterface / ReadActionInterface from YAML config) and is marked archived, with 1 star and 0 dependents. For a Laravel codebase that wrapper has no direct value — you would write a ~30-line service provider binding the two interfaces to the Poppler client and mirror the YAML in config/. So the real decision is "MIT-licensed Poppler wrapper, self-owned" versus "commercial document API."

When to Consider This Package

Adopt the underlying 1tomany/pdf-pack library when:

• You need exactly the three primitives — metadata, rasterized page images, page-range text. Nothing more.
• You are on Symfony and want zero boilerplate (autowiring, YAML config, MockClient for tests via a one-line config switch). The bundle's genuine wins are the mock client and the swappable ClientInterface tag — both are cheap to replicate in Laravel with a ServiceProvider and a fake binding, so weigh the bundle only if you are actually on Symfony.
• You control the runtime environment and can guarantee Poppler binaries in the image. Pin them in the Dockerfile and document exit-code/error behavior yourself — the README does not cover failure modes.
• You are comfortable owning an unmaintained dependency. MIT + archived means you can fork it in-house with no legal friction, but you inherit bug triage.

Look elsewhere when:

• You are on Laravel and want a supported package. Prefer spatie/pdf-to-image (Poppler/Ghostscript rasterization, actively maintained, Laravel-native) for images, and smalot/pdfparser (pure PHP, no binaries) for text/metadata. Two maintained dependencies beat one archived wrapper.
• You need manipulation, not extraction — merging, splitting, redaction, signing, form filling, annotations. This does nothing there.
• You need streaming/real-time annotation or browser-side preview with zoom/search. Use pdf.js; you will still want thumbnails from the server.
• Volume is high and latency-sensitive. Shelling out to pdftoppm is CPU and memory heavy and blocks a PHP worker. Budget for queue workers (Laravel Queues / Symfony Messenger) or an isolated worker service before committing to the roadmap, and treat "no queue infrastructure" as a scope cost, not a footnote.
• Security posture is strict: untrusted PDFs fed to Poppler binaries require process isolation, timeouts, output size caps, and a memory limit. If you cannot fund that hardening work, a managed extraction API is the safer product choice.
• You are already on PHP 8.3+/Symfony 8 and want long-term support guarantees. The release history is almost entirely "bump the underlying library" plus a rename and a YAML migration — no evidence of a support commitment.

Decision rule: if the roadmap item is "we need PDF text and thumbnails" and you are on Symfony, this is a fast two-day spike. If you are on Laravel, this is a pattern to copy, not a dependency to install — take the interface-plus-factory shape, back it with spatie/pdf-to-image and smalot/pdfparser, and write the mock yourself.

How to Pitch It (Stakeholders)

For executives: "Document ingestion is a shared capability behind several roadmap items — searchable uploads, invoice automation, contract review. Rather than buying a per-page document API or building a parser, we can wrap an existing open-source Poppler toolchain (MIT licensed, no per-page fees, no data leaves our infrastructure) behind a small internal interface. The published wrapper is Symfony-specific and no longer maintained, so we adopt the underlying library and own roughly a week of integration plus a week of hardening — far less than a commercial contract, and it keeps the option to swap in a paid API later behind the same interface if volume or accuracy demands it. The decision I need is a small, capped engineering bet, not a platform commitment."

For engineering: "Three primitives: metadata/page count, page-range rasterization at configurable DPI, page-range text extraction. The design worth copying is the interface-plus-client split — inject ExtractActionInterface / ReadActionInterface, back them with a Poppler client, and swap implementations via config. In Laravel that is a ServiceProvider binding two interfaces plus a config/onetomany_pdfpack.php mirroring the YAML. Keep the MockClient idea: bind a fake in the testing environment so CI never spawns pdftoppm. Hard requirements before we ship: Poppler binaries pinned in the container image, per-job timeouts and memory caps, page and output-size limits on untrusted uploads, extraction on the queue not in the request cycle, and structured logging on non-zero exit codes — the library does not document failure behavior, so that is on us. Extraction responses are generators, so a page-at-a-time pipeline is available if we need progress reporting later."