Fpdi Fpdf Laravel Package

Product Decisions This Supports

• PDF generation & document assembly roadmap. This package exists only to pin compatible versions of FPDI (page import from existing PDFs) and FPDF (PDF writer). It informs the decision of whether to build invoice/statement/certificate/report generation in-house or route it through a maintained rendering stack.
• Template-overlay features. The FPDI capability it wraps is specifically "import pages from a designer-produced PDF and overlay dynamic content" — the classic pattern for branded invoices, policy documents, payslips, shipping labels, and compliance notices where design owns the template and the app owns the data.
• Document composition features. Merging generated covers + customer-supplied attachments + appendices into one PDF; adding "PAID", "DRAFT", "CONFIDENTIAL" stamps; page numbering and Bates numbering on third-party PDFs.
• Build vs. buy. Adopting this is effectively "buy" (consume open source) — but because it is archived, you are really deciding to own a frozen dependency. The real build/buy decision is: (a) FPDF/FPDI as the engine, (b) a modern PHP renderer (mPDF/TCPDF/Dompdf/headless Chrome via Browsershot), or (c) a managed API (DocRaptor, PDFMonkey, Gotenberg).
• Tech-debt and supply-chain decisions. Whether to remove the metapackage from composer.json, replace it with explicit, auditable version constraints, and pin a PHP-version-supported writer. This feeds dependency-review, SBOM, and procurement/security questionnaires (an archived dependency is a standard finding).
• Support-cost and risk-register entries. Last release February 2020, archived upstream, low adoption (~95 stars) — a clear "unsupported" flag for the platform risk log and for any customer-facing durability commitments.
• Migration sequencing. If a legacy service already depends on it, its removal is a small, well-bounded ticket that unblocks PHP 8.x upgrades and vulnerability scanning — good candidate for a maintenance sprint rather than a roadmap item.

When to Consider This Package

Only as a legacy stopgap. Reasonable if you maintain an existing application already written against FPDF 1.x-era APIs, running an older PHP runtime, and you need FPDI + FPDF co-existing without hand-resolving constraints. Even then, prefer declaring setasign/fpdi and setasign/fpdf directly with explicit constraints — you get the same result with a visible, auditable dependency graph.

Consider the underlying FPDI library (not this wrapper) when the core requirement is importing pages from existing PDFs: overlaying data onto supplied templates, merging, stamping, re-ordering pages. That is FPDI's specific strength and it remains a legitimate choice.

Look elsewhere when:

• New greenfield features. Use a maintained writer: mPDF, TCPDF, Dompdf (with barryvdh/laravel-dompdf for Laravel ergonomics), or headless Chrome via Browsershot/Puppeteer for CSS-accurate layouts.
• Complex layout, modern CSS, or design-team-owned templates. HTML/CSS-to-PDF wins over FPDF's coordinate-based drawing almost every time.
• High volume or performance-sensitive paths. Rendering at scale wants a dedicated service (Gotenberg, a Lambda-based renderer) rather than in-process PHP rendering that blocks a request worker.
• Compliance-grade output. PDF/A archival, tagged/accessible PDFs, digital signatures, encryption/permissions — this package's stack does not cover these well, and the historical FPDI_Protection add-on is a separate commercial/legacy concern.
• Support or patching guarantees. Archived in 2020 means no security fixes and no PHP 8.2+/8.3+ guarantees. If procurement or your security team requires a maintained dependency or vendor SLA, this fails the bar.
• Font/CJK-heavy or Unicode-critical documents — legacy FPDF font handling and subsetting is a recurring source of defects.

Licensing caveat worth verifying: the MIT license here covers only the Composer metadata file. Confirm the license terms of FPDI and any FPDI add-ons you actually rely on before shipping in a commercial product.

How to Pitch It (Stakeholders)

For executives (one line): This is not a PDF engine — it is a three-line Composer convenience file that locks two older PDF libraries together, and it was abandoned in 2020. We should not adopt it; if it is already in our stack, removing it is a few hours of engineering and reduces our dependency and security-review risk.

For engineering leadership: Treat this as a dependency-hygiene item, not a feature decision. Recommendation: remove setasign/fpdi-fpdf from composer.json and declare setasign/fpdi / setasign/fpdf (or the chosen modern renderer) explicitly so versions are reviewable, patchable, and visible to scanners. Low effort, no product behaviour change expected, but it clears a standing finding in security questionnaires and SBOM reviews.

The actual decision to escalate: which PDF stack we standardise on for the next 12–24 months — legacy FPDF/FPDI for page-import/overlay work, an HTML-to-PDF renderer for design-owned templates, or a managed rendering service for scale. That choice affects design handoff, performance headroom, accessibility/archival requirements, and support cost; it deserves a short technical spike and an ADR rather than an ad-hoc per-ticket choice.

Framing to avoid: don't position this as "we're removing a PDF library." Position it as "we're removing an unmaintained wrapper and making a deliberate, documented choice about our document-rendering platform." The first sounds like churn; the second sounds like ownership.