Mpdf Port Bundle Laravel Package

Technical Evaluation

Framing note: tfox/mpdf-port-bundle is a Symfony2 bundle, not a Laravel package. It is a thin DI wrapper around the mPDF rendering library. In a Laravel context, "leveraging" this package means extracting its pattern (container-scoped renderer, externalised config, factory seam) and reimplementing it on the maintained upstream mpdf/mpdf — not installing the bundle itself.

• Architecture fit: The bundle's only transferable value is a clean separation between engine configuration (tempDir, fontDir, fontdata, default page format/margins) and rendering call sites, exposed through a factory so application code never instantiates mPDF directly. That idiom maps directly onto a Laravel service provider + config file + facade/interface. All Symfony-specific artifacts (MpdfPortBundle class, Extension/Configuration, services.yml) are non-portable dead weight.
• Integration feasibility: Installing alongside Laravel 10/11 is effectively blocked — Composer constraints target Symfony 2.x / PHP 5.x-era transitive requirements and will fail dependency resolution. A homegrown equivalent using upstream mpdf/mpdf is 1–3 engineering days (singleton binding, config, PdfRenderer interface, one call site), with the real effort in CSS/font fidelity and memory profiling.
• Technical risk:
  • Abandonment — Bitbucket-hosted, 0 stars, 0 dependents, no maintainer, no PHP 8 compatibility, no security response. Read-only reference material.
  • Licensing — mPDF is GPLv2 (commercial licence available). Must be cleared before code is written for SaaS/distributed products.
  • Security surface — mPDF renders attacker-influenceable HTML and may fetch remote resources; older versions carry CVEs. Pin only current upstream with remote-image loading disabled/allow-listed.
  • Lock-in — low, since it is only a wrapper (the one genuinely favourable risk trait).
• Key questions:
  1. Is PDF generation core to revenue or ancillary export?
  2. What are monthly document volume and p95 document size (pages, images, CJK/RTL)?
  3. Do we need forms, encryption, signatures, PDF/A, or tagged accessibility output?
  4. Is GPLv2 acceptable in our distribution model, or do we need the commercial licence?
  5. Who owns the HTML/CSS templates — design or engineering?
  6. Is there any legacy Symfony2 estate this was originally written for, or is this purely a catalogue artifact?
  7. What is the correctness SLA (regulatory retention, invoicing) versus cosmetic fidelity?

TPM summary: No-go on adopting the package; go on the pattern, implemented directly on upstream mPDF behind an abstracted renderer.

Integration Approach

• Stack fit: Not a dependency fit — Symfony bundles have no consumption path in Laravel (no bundle registration, no services.yml autoloading, no DI extension lifecycle). Vendoring and rewriting it is strictly worse than building clean. It is a good design reference for the config/renderer seam.
• Migration path:
  1. Archive, don't install. Read-only clone; capture config defaults (page size, margins, font paths, temp-dir handling) as a specification document — that document is the deliverable.
  2. Adopt upstream mpdf/mpdf at current stable; verify PHP 8.2/8.3 support and run the security advisory check before it enters the lockfile.
  3. Recreate the wrapper idiomatically: MpdfServiceProvider binding a configured instance or PdfRenderer interface as a singleton, config/pdf.php, and interface injection at call sites.
  4. Bind to an interface, not the concrete class — PdfRenderer::render(HtmlDocument): BinaryString. Highest-leverage decision; converts a future engine swap into a config change.
  5. Queue rendering from day one if documents exceed ~10 pages or include images; retrofitting async is materially more expensive.
• Compatibility: Target PHP 8.2+ and Laravel 10/11. Watch font handling — mPDF needs a writable tempDir and font cache; CJK/RTL fonts add tens of MB per generated file. Validate against production fonts, not defaults. Any legacy Symfony2 consumer requires a behavioural port with golden-file diff tests against old output.
• Sequencing:

Operational Impact

• Maintenance: The package itself is unmaintained and should not be on any critical path. Operational ownership shifts to the internal wrapper and to tracking upstream mpdf/mpdf releases. Budget a recurring line item for periodic upgrade + golden-file revalidation, since a patch release can silently change pagination on archived documents. Pin the minor version.
• Support: No upstream support channel for the bundle. Internal support = one owner for the renderer + templates. Escalation for rendering defects goes to the upstream mPDF project or the commercial licence vendor if purchased.
• Scaling: mPDF is synchronous, in-process, pure PHP — no Chromium, no Node, no outbound call, which keeps infrastructure cost near zero and keeps customer financial data in-app. But memory and latency scale with page count and image count, so it must run in bounded queue workers with explicit memory ceilings and timeouts, not inline in web requests beyond small documents. Horizontal scale is just more workers; the constraint is per-job footprint, not throughput architecture.
• Failure modes:
  • OOM/timeout on large or image-heavy documents → per-job memory limit, chunking, or async email delivery instead of "download now".
  • Font-cache/temp-dir exhaustion on shared hosts → dedicated writable temp path, cleanup job.
  • Silent layout drift after upstream patch → golden-file tests gating upgrades.
  • SSRF/remote-resource fetch from untrusted HTML → disable or allow-list remote images.
  • Licensing exposure if GPLv2 obligations are unmet in a distributed/on-prem product → resolved in Phase 0.
• Ramp-up: Low for the wrapper (1–3 days for a Laravel engineer), moderate-to-high for the real work — print-oriented HTML/CSS (tables, floats, absolute units; no flexbox/grid), font embedding, and memory profiling. Design must deliver print CSS, not web layouts. Treat templates as versioned code with golden-file tests from the first sprint.