Mpdf Port Bundle Laravel Package

Product Decisions This Supports

Feature and roadmap decisions this evaluation unlocks

• Document-generation roadmap: invoices, receipts, statements, payslips, contracts, packing slips, compliance reports, and exportable analytics — every feature where a customer expects a downloadable, print-correct PDF rather than a browser print dialog.
• Build vs. buy vs. wrap decision on PDF rendering: this package answers the "wrap an existing open-source renderer behind our DI container" branch. It is a thin Symfony2 service wrapper around mPDF, so the real decision is do we adopt mPDF as our rendering engine, and how much glue do we own — not whether to adopt this bundle.
• Engine selection criteria: mPDF's genuine differentiators are server-side HTML→PDF with strong CJK/RTL/Indic script support, running headers/footers with {PAGENO}/{nbpg} page tokens, watermarks, barcodes, bookmarks, and auto-generated tables of contents. That maps directly onto invoicing, multi-language statements, and long policy documents.
• Known product ceiling: mPDF predates flexbox/grid and supports roughly CSS 2.1. That is a product constraint — it determines whether design hands us print-ready HTML or we need bespoke templates, and who owns template authoring.
• Strong-fit use cases: variable-data documents repeating headers across dozens of pages, batch generation (monthly statements for thousands of accounts), archival template-driven PDFs, and documents needing page numbering plus a TOC.
• Poor-fit use cases: marketing collateral, pixel-perfect brand brochures, designer-iterated layouts in Figma, heavy webfont subsetting, or anything needing modern CSS layout.
• Operating model implications: mPDF is pure PHP and in-process — no Chromium, no Node runtime, no outbound service call. That makes PDF export cheap to ship early and self-hosted, and it keeps customer financial data in our own application (a compliance argument). It also caps per-document latency and memory, which shapes whether we promise "download now" or "we'll email it to you."
• Reversibility: choosing an engine now sets a template-authoring contract with design and a golden-file testing story that gets expensive to unwind later. The mitigation is binding to our own PdfRenderer interface from day one.
• Catalogue caveat that is itself a decision input: this artifact is a Symfony2 bundle with 0 stars, 0 dependents, and no maintenance activity. It is not a Laravel dependency. Treat it as a design reference, not a candidate package.

When to Consider This Package

Consider the underlying engine (mPDF — not this bundle) when:

• Documents are structured and data-driven — line items, addresses, totals, tables — rather than art-directed layouts.
• You need non-Latin scripts (Chinese, Japanese, Arabic, Hebrew, Thai, Devanagari) in the same pipeline. This is mPDF's strongest argument and where dompdf and many alternatives fall over.
• You need running headers/footers with correct page counts, watermarks, and bookmarks without hand-writing a PDF library.
• You need batch throughput in a plain PHP worker (queue job, artisan command) with no external binary or container — attractive for on-prem or enterprise deployments where shipping a browser is not viable.
• Documents are small to medium (a few dozen pages) and PHP-FPM memory budgets can absorb the renderer.
• You want a permissive-enough licensing path for your distribution model: mPDF is GPLv2 with a commercial licence available from its maintainer — clear this before writing code.

Do not adopt this specific package when:

• You are on Laravel. The name is literal: it is a Symfony2 bundle relying on Symfony\Component\HttpKernel\Bundle\Bundle, Extension/Configuration, and Resources/config/services.yml. Laravel's container understands none of that. There is no consumption path — installing it alongside Laravel 10/11 will conflict on symfony/* transitive constraints and fail Composer resolution. Use mpdf/mpdf directly behind your own service provider.
• You need maintenance assurance. Zero stars, zero dependents, Bitbucket-hosted, no PHP 8 evidence, no security response. Treat it as unmaintained reference material.
• You need modern CSS. Reach for headless-Chrome rendering (Gotenberg, Browsershot, Puppeteer) or a commercial engine.
• You want the vendor to own rendering correctness — accessibility tagging/PDF-UA, digital signatures, ZUGFeRD/Factur-X e-invoicing. Those are the managed-service buy options (DocRaptor, PDFreactor).
• You are already standardized on dompdf with simple documents — migrating buys you little.
• You are on a legacy Symfony2 estate — the one scenario where the code itself, not just the pattern, might still make sense. Confirm that estate actually exists before spending time on it.

Minimum due-diligence gates before any mPDF commitment:

1. Licence review — GPLv2 obligations versus the commercial licence, against our distribution model (SaaS vs. redistributed on-prem).
2. Confirm current upstream mPDF declares PHP 8.2/8.3 support and passes a security advisory check before it enters the lockfile.
3. Benchmark one real production statement at production size — pages, embedded images, CJK/RTL fonts — for fidelity, latency, and peak memory.
4. Decide where rendering runs: inline request versus queue job. Retrofit is expensive.
5. Confirm who owns templates: design as HTML/CSS assets, or engineering as code.

How to Pitch It (Stakeholders)

To executives (30 seconds) "We need to produce invoices and statements as PDFs. There are two ways to buy that: pay per-document licensing to a hosted rendering service, or render in-process in PHP. The second keeps infrastructure cost near zero and keeps customer financial data inside our own application, which matters for compliance. The engine that makes that possible — mPDF — is mature open source with genuinely good multilingual and page-layout support. The specific package in front of us is only a small Symfony convenience wrapper for it, and it is unmaintained with no users: it is not usable in our Laravel stack. My recommendation is to adopt the engine, not the wrapper. One to three days of our own integration code gives us the same result without putting a dead dependency on the critical path of billing documents."

To engineering

• Do not install this package. It is a Symfony2 bundle; it cannot register in Laravel. Use upstream mpdf/mpdf at the current stable release, with a PHP 8.2+/Laravel 10/11 compatibility and security-advisory check before it hits the lockfile.
• Extract the pattern, not the code. The bundle's one good idea is separating engine configuration from rendering call sites. Recreate it idiomatically: a MpdfServiceProvider binding a configured renderer as a singleton, a config/pdf.php for fonts/temp dir/margins/defaults, and a facade or injected interface at call sites. Its config defaults are worth capturing as a short spec document — that document is the real deliverable.
• Bind to an interface, not the concrete class. PdfRenderer::render(string $html, array $options): string. This is the single highest-leverage decision, because it turns a future engine swap (mPDF → Gotenberg/Browsershot) from a refactor into a config change.
• Isolate rendering in a queued job from day one if documents exceed roughly ten pages or embed images. Set an explicit memory ceiling and timeout; mPDF's footprint scales with page count and image count. Retrofitting async later is materially more expensive.
• Treat templates as code: version them, golden-file diff them, and pin the mPDF minor version so a patch release cannot silently change pagination on already-archived documents. If any legacy Symfony2 output exists, run a golden-file comparison as the behavioural port test.
• Design contract: HTML must be print-oriented — tables, floats, absolute units, no flexbox or grid. Get design to hand us print CSS, not a web layout.
• Risks to log: mPDF is GPLv2-family (licence decision is a gate, not a detail); mPDF renders attacker-influenceable HTML and can fetch remote resources, so disable or allow-list remote image loading and never pin an old release; the wrapper itself is abandoned, which is why we are not using it.

Recommendation: No-go on this package. Go on mPDF as the v1 engine behind our own thin PdfRenderer abstraction, shipped first behind a queue job and a feature flag, with a documented exit ramp to a headless-Chrome renderer if design requirements escalate.