Laravel Php Pdf Laravel Package

Product Decisions This Supports

• Feature enablement: Server-side PDF generation and digital signing inside Laravel apps — invoices, contracts, certificates, HR/legal documents, compliance artifacts. The package is a thin, config-driven integration over dskripchenko/php-pdf.
• Build vs buy: Adopting this avoids building the plumbing for signer resolution, font families/faces, and signature-config wiring yourself. v1.5.0 specifically expands the "buy" case: pluggable signing.signer and fonts.provider bindings mean fewer custom service-provider hacks.
• Enterprise/regulated roadmap: The new signing.signer binding (container binding or class resolving to a Signer/CmsSigner) unlocks CryptoPro CSP, PKCS#11 tokens, HSMs, and cloud KMS without touching application code. This is the strategic unlock for eIDAS-style or regulated-industry signing workflows — a roadmap-level capability, not just a config tweak.
• Document fidelity / brand quality: fonts.provider lets you supply families not listed in config (e.g., Liberation fonts with Arial / Times New Roman / Courier New aliases), which matters for legally-expected typography and branded output. The font-face fix (bold/italic/bold-italic previously silently rendered as regular) removes a real, user-visible defect in generated documents.
• Detached signature workflows: Pdf::signDetached() now works with CmsSigner (php-pdf 1.20+), supporting architectures where the signature is stored separately from the document — audit trails, archival, and verification pipelines.
• Upgrade decision: This is a low-risk, feature-positive release, but it hard-bumps the upstream constraint to php-pdf ^1.18. Confirm your installed php-pdf version and run signing/font regression tests before rollout.

When to Consider This Package

Adopt when:

• You are on Laravel and need PDF generation plus configurable digital signing — especially where the signing key may live in a certificate file, a PKCS#11 token, an HSM, or a cloud KMS.
• You want configuration over custom code for signers and fonts, and you value that swapping the signer source requires no application changes.
• You need detached CMS signatures for archival or audit-trail requirements.
• You need brand- or spec-accurate typography (Arial / Times New Roman / Courier New aliases) without shipping font binaries or writing a provider.
• Your team is comfortable pinning to upstream php-pdf and tracking its releases.

Look elsewhere when:

• You need a full PDF authoring/editing suite (form filling, annotations, redaction) or heavy HTML-to-PDF templating (DomPDF, Snappy/wkhtmltopdf, Browsershot are better fits).
• You are not on Laravel — the value here is the container/config integration.
• You require certified compliance (PDF/A, PDF/UA) as a hard guarantee; verify upstream capabilities explicitly before committing.
• You are pinned below php-pdf ^1.18 and cannot upgrade — v1.5.0 will not install.

How to Pitch It (Stakeholders)

To executives: This release turns signed-document generation into a configuration decision rather than an engineering project. We can now point the same code at a local certificate, a hardware token, an HSM, or a cloud KMS by changing a binding — which is the difference between "we can sign PDFs" and "we can serve regulated enterprise customers." It also fixes a visible quality bug where bold text rendered as regular in branded documents. Cost is a version bump, not a rewrite.

To engineering: v1.5.0 adds two extension points — signing.signer (resolved once, replaces the configured certificate/key for Pdf::sign(), ->signed(), Pdf::signatureConfig(), and Pdf::signDetached()) and fonts.provider (asked for families not listed in fonts.families). It fixes per-face font resolution (bold/italic no longer collapse to regular, with fallback to regular when unconfigured) and fixes a TypeError in signDetached() with CmsSigner. It requires php-pdf ^1.18 (was ^1.16), and signDetached() + CmsSigner needs php-pdf 1.20+ or it fails with a clear message. Small surface area, testable, and the upgrade path is explicit.

Risks to flag: Dependency on upstream php-pdf maturity and release cadence; document fidelity and legal admissibility must be validated per jurisdiction; and the font-face fix may change output of existing documents — worth a visual regression pass.