Wk Pdf Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for document generation: whether to ship invoices, statements, receipts, packing slips, compliance reports, or customer-facing PDF exports. This package only answers "how do we render HTML to PDF" — it does not answer templating, storage, delivery, or archival, which are the larger product surfaces.
• Build vs. buy on the rendering layer: the package is a thin Symfony service-container wrapper around the wkhtmltopdf binary. The real buy decision is the binary and its operational profile (native dependency, font packs, headless rendering, sandboxing), not this wrapper. Expect to build the wrapper yourself in under a day; budget the decision around the engine.
• Framework fit is a decision input, not a detail: despite being filed under a Laravel/PHP search, this is a Symfony bundle (WkPdfBundle). In Laravel you would either pull in the Symfony bundle machinery, re-implement the ~single-service glue natively, or use a Laravel-native alternative. This materially changes the "buy" calculus toward "don't."
• Roadmap sequencing for print/export capability: choosing an engine now sets a multi-year constraint on design. wkhtmltopdf runs on an old QtWebKit fork — no CSS Grid, partial/fragile Flexbox, no modern JS. Any roadmap item that assumes "designers hand us a web page and we print it" is not supported here.
• Vendor and supply-chain risk assessment: 0 stars, 0 dependents, single maintainer, last release Sept 2023. This is a "copy the 150 lines into your codebase" candidate, not a dependency candidate. That is itself a decision output worth recording.

When to Consider This Package

Consider it only if all of the following hold:

• The project is Symfony, not Laravel, and is already standardized on bundle-based service wiring.
• You have existing print templates authored for wkhtmltopdf (page-break CSS, -webkit- print quirks, header/footer via --header-html). Rewriting them for a Chrome-based renderer is a real, quantified cost you've decided to defer.
• You need legacy compatibility — long-lived templates, PDF/A-adjacent archival output, or signed documents that must not shift layout between releases. Rendering determinism is a legitimate reason to stay on a frozen engine.
• Your volume is low-to-moderate and batch-oriented (nightly statement runs, on-demand invoices), where a subprocess-per-document model is operationally acceptable.
• You are willing to vendor the wrapper or accept single-maintainer risk with a pinned binary version.

Look elsewhere if:

• You are on Laravel. Use spatie/laravel-pdf (Browsershot/headless Chrome), barryvdh/laravel-dompdf for simple documents, or knplabs/knp-snappy / laravel-snappy if you specifically need the wkhtmltopdf engine with a maintained, widely-adopted wrapper (orders of magnitude more dependents).
• You need modern CSS fidelity — flex/grid layouts, web fonts, CSS variables — or JS-executed charts.
• You need high concurrency or low-latency rendering; wkhtmltopdf forks a heavy process per document. Gotenberg (HTTP-based, containerized) is the better operational shape for that.
• You need accessibility-tagged PDFs, PDF/A conformance, or form fields — none of this is wkhtmltopdf's strength.
• You can't tolerate a dependency with 0 dependents and no recent release.

How to Pitch It (Stakeholders)

For executives — the one-line version: "We looked at a small open-source PDF-rendering wrapper for our document features. It's a thin convenience layer over a legacy rendering engine, it's built for Symfony rather than our stack, and it has a single maintainer and no adoption. Recommendation: adopt the capability, not the package."

The decision: PDF output (invoices, statements, customer reports) is a real product need with a long tail. The rendering engine choice is the durable decision; the wrapper is a commodity. We should standardize on a headless-Chrome-based renderer (via a maintained Laravel package or a Gotenberg service) so that product and design can ship document templates using the same CSS and component library as the web app, rather than maintaining a parallel print-only design system.

Why not this package: it targets Symfony, it has zero downstream users, and its last release was September 2023. The code it saves us is roughly a day of work; the risk it introduces — an unmaintained dependency on an unmaintained engine, pinned to a native binary — is disproportionate to that saving.

The cost we're accepting: headless Chrome is heavier per render (memory, cold-start). We mitigate with a warm container and a small render queue. For a moderate document volume this is a rounding error against the engineering cost of maintaining print-specific templates.

Ask: approve the engine direction (headless Chrome / Gotenberg) and a small spike to benchmark render latency and memory at our expected peak volume before we commit the template migration to the roadmap.