Pdf Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on document rendering. This bundle is a thin Symfony DI wrapper around the DocRaptor API (a hosted PrinceXML renderer). It is a buy decision dressed as a build decision — the real vendor commitment is DocRaptor, not this bundle. Any review of it should be a review of DocRaptor's pricing, SLA, and data-processing terms.
• Invoice / ticket / statement generation for a legacy Symfony 2.x application: server-side HTML+CSS → PDF with print-grade fidelity (page breaks, headers/footers, CSS paged media) that DomPDF and wkhtmltopdf handle poorly.
• "Premium PDF" quality bar for a roadmap item. If a product requirement is "our PDFs must look like the web UI," DocRaptor's Prince engine is a legitimate evaluation candidate and this repo is a 30-minute proof-of-concept, not an architecture choice.
• Vendor-lock-in and data-egress posture. PDF generation typically means shipping customer PII (names, addresses, line items, sometimes health/financial data) to a third party. That is a compliance decision that belongs above the PM's pay grade — this bundle's existence should trigger that conversation, not settle it.
• Dependency lifecycle / technical-debt triage. 0 stars, 0 dependents, last release April 2015, Symfony 2-only constraints. This is effectively a public-but-private bundle — a reference implementation someone forgot to archive. It supports the decision not to adopt it, and supports a roadmap line item to migrate any existing usage.
• Not a Laravel decision. Despite the framing, this is a Symfony2 bundle with Symfony\Component\HttpKernel-era service definitions. It contributes nothing to a Laravel roadmap; the equivalent decision there is "DocRaptor PHP SDK vs. spatie/laravel-pdf vs. self-hosted Gotenberg."

When to Consider This Package

Consider it only if all of the following are true:

• You are maintaining an application already pinned to Symfony 2.x (2.6–2.8 era) and cannot upgrade.
• You are already a paying DocRaptor customer, or you are explicitly running a one-week spike to evaluate Prince-quality output.
• You need HTML/CSS fidelity — multi-page tables that break cleanly, running headers, TOC generation — that local PHP renderers handle badly.
• You are comfortable treating the code as a fork-and-own artifact: vendor it into your repo, pin it, and accept full maintenance. Do not expect upstream fixes; there is no upstream.
• Document volume is low enough that per-document SaaS pricing is trivial against engineering time.

Look elsewhere if any of these apply:

• Any modern Symfony (3.x through 7.x) or Laravel. Use the official docraptor/docraptor PHP client directly — the bundle's value-add is a service definition and a config tree, roughly an afternoon of work you'd rewrite anyway. For Laravel, spatie/laravel-pdf or barryvdh/laravel-dompdf; for modern Symfony, knplabs/knp-snappy (wkhtmltopdf) or mpdf/mpdf.
• You need self-hosted or air-gapped rendering, or cannot send documents to a US-hosted third party. Use Gotenberg (headless Chromium in Docker) or a Prince XML license — both avoid SaaS egress.
• Cost sensitivity at scale. Per-document SaaS pricing dominates unit economics for high-volume billing runs; a self-hosted Chromium renderer is nearly free at volume.
• Any team with a "no unmaintained dependencies" policy. A 2015 last-release with zero dependents and zero stars will fail any reasonable supply-chain or CVE-triage gate, and it has no security-response path.
• PHP 8.x projects. The composer constraints and the API surface it targets predate PHP 7 entirely; expect fatal errors, not warnings.

How to Pitch It (Stakeholders)

To executives: "There is a small, abandoned open-source helper that connects an old Symfony app to DocRaptor, a paid document-rendering service. It is not a platform; it is roughly 200 lines of configuration glue published in 2015 and untouched since, with no users and no maintainer. I recommend we treat it as a prototype tool only — useful to demo premium PDF quality to a customer or stakeholder in an afternoon, but not something we build a billing or invoicing pipeline on. The strategic decision in front of us is not 'adopt this package,' it's 'are we willing to send customer documents to a third-party renderer, and pay per document for the privilege?' If the answer is yes, we can get there with DocRaptor's own supported SDK in a day. If no, we should budget a self-hosted renderer. Either way, no engineering capacity should be spent maintaining a 2015 bundle."

To engineering: "Don't take a dependency on this. It's a Symfony 2.x DI wrapper over the DocRaptor REST API — no rendering logic, no tests worth inheriting, no upgrade path. If we need DocRaptor, use docraptor/docraptor and wrap it in our own service with a PdfRendererInterface so we can swap in Gotenberg or mpdf later without touching call sites. If someone has already vendored this into a legacy app, treat it as fork-and-own: copy the config, pin the version, and open a ticket to replace it before the next PHP/Symfony upgrade. And to be explicit — this is not a Laravel package and cannot be used as one."

To the sponsor of the PDF initiative: "The 30-minute demo is real value; the dependency is not. Fund a one-week spike that renders our three hardest documents through DocRaptor and through a self-hosted Chromium renderer, and decide on fidelity, data-handling, and cost-per-document. Skip the bundle."