Html2Pdf Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. wrap for PDF export — Forces the concrete decision: adopt a wrapper bundle, depend on the underlying engine directly (spipu/html2pdf or a modern equivalent), or buy a rendering service. The package itself resolves this quickly: it is a Symfony2 wrapper with no Laravel surface, so the real decision is which engine backs the PDF feature, not whether to install this bundle.
• Feature scoping for document generation — Useful reference when answering "do we ship invoices, statements, tickets, or report exports this quarter?" The bundle demonstrates the template → HTML → PDF shape of the feature, which is enough to size the work even though the code won't be adopted.
• Framework/runtime roadmap — Flags PDF generation as a known migration hazard. If the same output is produced by legacy Symfony2 code somewhere in the org, this is a concrete item to inventory before a Laravel or modern-Symfony consolidation.
• Vendor-risk register — 2 stars, 0 dependents, no maintenance signals. A clean entry for "do not adopt" that lets the PM justify owning the PDF pipeline internally rather than inheriting an abandoned dependency.
• Architecture guardrail — Justifies mandating a PdfRenderer-style interface so any PDF engine (dompdf, Snappy/wkhtmltopdf, Browsershot/Chromium, Gotenberg service) can be swapped without touching feature code. This is the durable product decision the package motivates.

When to Consider This Package

Consider it only as reference material, not a dependency:

• You are studying a legacy Symfony2 codebase and need to understand how its PDF generation was wired (config tree for orientation, format, margins, fonts; service definitions; the thin HTML2PDF factory).
• You are porting a Symfony2 PDF feature to Laravel and want the behavior and configuration shape to replicate behind a Laravel service provider — not the bundle.
• You are prototyping and are comfortable that the real deliverable is spipu/html2pdf (or an alternative engine) wrapped in ~40 lines of your own code.

Look elsewhere, or reject outright, when:

• The target stack is Laravel — there is no service provider, facade, or config publishing; Composer will not cleanly resolve it against PHP 8.1+ and there is no auto-discovery. Installing it yields dead Symfony plumbing.
• You need maintenance, security patching, or an SLA — near-zero community, no release cadence; every bug becomes yours.
• Output is customer-facing or brand-critical — fidelity, Unicode/RTL, fonts, PDF/A, encryption, and digital signatures all need an engine with a real support story.
• Volume or latency matters — TCPDF-lineage rendering is synchronous, CPU- and memory-heavy; you will need queues, worker isolation, and memory/timeout tuning regardless of which wrapper you pick.

How to Pitch It (Stakeholders)

To executives: This package is not a strategic dependency and should not appear on the roadmap as one. It is a small MIT-licensed Symfony2 convenience wrapper around an older HTML-to-PDF engine, with 2 stars and no dependents. Its only real value is as a reference for how a PDF-export feature is shaped — templates in, PDF out. If PDF generation (invoices, statements, exports) is on the roadmap, treat this as a sizing artifact and budget a short spike to evaluate a maintained engine or a managed rendering service instead. The recommended product decision: do not adopt; standardize on an owned, swappable PDF pipeline.

To engineering: Do not composer require this in a Laravel app. Port the behavior, not the code. Read its configuration tree and service factory, then rebuild the equivalent as a Laravel service provider bound to an interface (PdfRenderer) with a config/pdf.php for orientation, format, margins, and fonts. Pick the engine on fidelity and operational fit — dompdf for simple documents, Snappy/wkhtmltopdf for richer layouts, Browsershot/Chromium or Gotenberg for high-fidelity or isolated rendering. Whatever you choose, keep the contract stable (HTML/Blade in, binary or stored file out) and add contract tests on page count, text extraction, and font rendering before cutover.

To the team running legacy: If a Symfony2 system still uses this bundle, isolate it behind the same interface, capture its templates and config, and plan extract-and-replace rather than port-and-maintain. The bundle's value is the wiring pattern, which you can reproduce in a few dozen lines.