Pdf Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. assemble for document generation. PDF output (invoices, statements, reports, certificates) is a commodity capability. This package represents the "assemble from a legacy open-source library" option — a thin Symfony bundle over PHPPdf. It is only defensible if you already own PHPPdf-era templates; it is not a credible greenfield choice against modern renderers (Gotenberg/Browsershot, Dompdf/mPDF, or a managed SaaS).
• PHP 8 upgrade gating. The package's only stated reason to exist is being "fixed for PHP 7." PHP 7.4 reached end of life in November 2022, so the fork's headline value is already out of date for any team on a supported runtime. If this dependency is in the tree, it is a blocker in your PHP 8.x upgrade plan — a concrete line item for the platform roadmap and security/compliance review, not a vague risk.
• Framework-fit decision (Laravel vs. Symfony). This is a Symfony bundle: service definitions, bundle registration, Symfony-era component assumptions. On a Laravel codebase it delivers no service provider, no config publishing, no container wiring — you would be integrating the underlying PHPPdf library by hand. That converts a "just install it" task into custom glue code you own forever.
• Vendor and dependency-risk register entries. 0 stars, 0 dependents, and a single late-2023 maintenance release are adoption and bus-factor signals. There is no community to triage bugs, no security response process, and no commercial entity behind it. For anything customer-facing or regulated, that is a supportability decision, not a technical preference.
• Roadmap sequencing for legacy reports. If PHPPdf output exists in production, this package frames the real decision: keep the renderer alive for another cycle, or fund a migration to a renderer with an active maintainer, HTML/CSS fidelity, and PDF/UA accessibility support. Migrations are cheaper when scoped as "replace the renderer behind one interface" than when triggered by an emergency PHP upgrade.
• Use cases where it is genuinely plausible. Internal, low-stakes, low-volume documents with existing XML/XSL-FO-style templates; pure-PHP rendering where you cannot ship external binaries (wkhtmltopdf/Chromium) into the runtime; air-gapped environments where a managed SaaS is not allowed.
• What it does not support. Anything requiring layout fidelity from HTML/CSS, high-throughput rendering, accessibility-tagged PDFs, or a support contract. Choosing this package implicitly defers those requirements to a later migration.

When to Consider This Package

Consider it only when all of the following hold:

• You already have PHPPdf-based templates and PDF output in a Symfony application in production.
• Your infrastructure is pinned to PHP 7.x and there is no funded upgrade this cycle.
• The documents are internal or low-stakes, with no accessibility, archival, or regulatory requirements.
• Volume is modest and latency is not a product concern.
• You accept ownership: you will fork, pin, and patch it yourself, and you can absorb that cost without a maintainer to escalate to.
• MIT licensing is acceptable for your distribution model (it is permissive — the license is not the problem; maintenance is).

Look elsewhere when any of the following hold:

• You are on Laravel. Wrong-framework dependency with no integration layer; evaluate Dompdf, mPDF, Browsershot, or Gotenberg directly.
• You are on PHP 8.x or planning it. A PHP 7 compatibility fork is the opposite of what you need.
• This is a new build. Zero dependents means zero field validation; you would be the first production user.
• Documents are customer-facing or regulated (invoices, contracts, statements, anything audited). You need a maintainer, a CVE path, and ideally PDF/UA support.
• You need HTML/CSS layout fidelity, complex paged media, or high volume.
• You want a support relationship or SLA. None exists here.
• Cost of ownership matters more than time-to-first-PDF. The install is cheap; the exit is not.

How to Pitch It (Stakeholders)

To executives: This is a maintenance-only library that wraps an abandoned PDF engine, patched for a PHP version that is itself end-of-life. It has no meaningful adoption — zero dependent packages and no community — which means no one else is finding and fixing its bugs, and we would be on our own for security issues. I do not recommend adopting it for any new capability. If it is already in our stack, treat it as a tracked liability that gates our PHP 8 upgrade and fund a renderer replacement behind our existing template interface rather than a rewrite.

To engineering: Treat it as legacy-only. If we must keep it, pin the exact version, isolate every call behind a PDF-renderer interface, and add a contract test suite over the output so a future swap is mechanical. Do not let it spread into new services. In parallel, spike two replacements — a headless-Chromium renderer for fidelity and a lightweight PHP renderer for constrained runtimes — and pick based on document complexity, not installation ease.

Bottom line for the roadmap: Not a strategic dependency. It supports one narrow decision — how to keep legacy PDF output alive until we migrate — and it argues for scheduling that migration rather than deferring it.