dskripchenko/php-pdf
A PHP package for generating PDF documents, with support for Laravel applications. Build invoices, reports, and other printable documents programmatically through a straightforward API for creating and customizing PDF files.
Architecture fit. The package positions itself as a pure-PHP, MIT-licensed, zero-composer-dependency PDF toolkit spanning generation (HTML/CSS input, TTF embedding, barcodes, charts), manipulation (read, merge), and compliance/security (AcroForm, PKCS#7 signing, PDF/A, PDF/X). That is an unusually broad surface for a single library, and it maps directly onto several recurring Laravel workloads: invoice/statement rendering, document assembly in order pipelines, and signed document delivery in regulated flows (contracts, HR, finance). Architecturally it is a library, not a service — no daemon, no headless browser, no Ghostscript or Java toolchain — which is the single most attractive property for teams running on shared hosting, restrictive PaaS runtimes, or locked-down enterprise PHP images where installing wkhtmltopdf or Chromium is a change-control event.
Integration feasibility. Composer-installable and framework-agnostic by description, so Laravel fit is a thin service provider/facade wrapper at most. Nothing in the description implies framework coupling. The realistic integration cost sits in three places, not in wiring: (1) HTML/CSS fidelity — pure-PHP HTML renderers historically implement a CSS subset, so existing Blade templates written against a browser engine will need audit and rework; (2) font/subsetting behaviour and the resulting file size and text-extraction quality; (3) the crypto path for PKCS#7, which needs certificate handling, and ideally a timestamp authority for long-term validity.
Technical risk. High, and concentrated in provenance rather than capability. Repository: unknown is disqualifying for a standard due-diligence gate: we cannot inspect commit history, CI configuration, test coverage, open-issue backlog, contributor count, or the identity behind the maintainer. A last-release date of 2026-10-19 is in the future relative to normal reporting windows, which suggests either a scheduling/metadata artefact or a data-quality problem in the source feeding this assessment — either way it must be resolved before the date is used as a health signal. At 11 stars the package is effectively unadopted, so there is no downstream community to absorb a maintainer disappearance, no StackOverflow corpus, and no third-party security review of the signing and PDF/A paths. Signing and archival-compliance code is exactly where "works in the happy path" is insufficient: PDF/A conformance (embedded fonts, output intent, XMP metadata, no encryption) and PDF/X are checker-verifiable, and a claim in a README is not evidence.
Key questions.
openssl, mbstring, gd, zip, iconv? "Dependency-free" needs to be defined precisely.Stack fit. Comfortable. Pure PHP with no composer dependencies means no new runtime artefacts, no container image changes, and no sidecar service in the deployment topology — a materially simpler story than the Gotenberg/Browsershot route, which adds an HTTP hop, a container, and its own failure domain. For a Laravel team already using barryvdh/laravel-dompdf or mpdf, the migration is a driver swap behind an existing boundary rather than a re-architecture. The differentiator versus dompdf is the merge/read, AcroForm, and signing capability that dompdf and mPDF lack and that today usually forces teams to add FPDI (with its licensing friction) or a commercial SDK.
Migration path. Do not call the library directly from controllers or jobs. Define a DocumentRenderer contract with render(InvoiceDto): string and sign(string, Certificate): string, implement DskripchenkoRenderer behind it, and keep the incumbent driver as a second implementation behind the same contract for the duration of the rollout. This costs a day and buys a one-line rollback if CSS fidelity or signing fails acceptance. Treat template rewrites as the real migration cost: budget template-by-template visual diffing rather than a big-bang cutover.
Compatibility. Verify PHP minor-version support against the oldest runtime we still operate, and confirm behaviour on Alpine/musl and on distroless images — pure-PHP libraries that shell out or rely on system font paths fail quietly in slim containers. Confirm the licence is genuinely MIT across vendored code (the description asserts MIT, but in-house-ported renderer cores occasionally carry upstream attribution obligations). For signing, confirm the certificate chain, key format (PEM/P12), and whether an HSM-backed key can be used via an external signer callback; if not, this library cannot serve the regulated-signature use case and should be scoped to unsigned generation only.
Sequencing.
Maintenance. The maintenance risk is bus-factor-one on an 11-star project. There is no realistic prospect of upstream responding to our roadmap, and no community to share the cost of a fix. We should assume we will own any bug we hit, in code we did not write, in the two hardest domains in the library (font/layout and cryptography). That is affordable for rendering; it is a poor trade for signing unless we are prepared to fork and staff it. Contrast with dompdf/mPDF (large user base, known failure modes, active forks) and with Gotenberg (operational complexity but Chrome-grade rendering fidelity and a vendor-neutral exit).
Support. No commercial support, no LTS, no CVE feed. Internal support means reading the source. Escalation path does not exist. For any workflow that touches audit or legal evidence, this needs explicit risk acceptance from the document owner, not just engineering.
Scaling. Generation is CPU- and memory-bound within the PHP worker, the same as dompdf — no worse, but not free. Large HTML documents with embedded TTF subsets and chart rendering will inflate peak memory and can approach memory_limit on default worker sizing; horizontal scale is achieved by queueing (GeneratePdf job on a dedicated queue) and capping concurrency per worker, not by anything the library offers. Merging and signing should be separate, short-lived jobs so a crypto timeout does not hold a rendering worker. Watch output size for PDF/A, where font embedding and no-compression choices can multiply file size and downstream storage/egress cost.
Failure modes. Expect: CSS properties silently dropped rather than errors (highest-risk mode — produces a plausible but wrong document); font fallback producing tofu or non-extractable text in statements that must be searchable; memory exhaustion on large documents; PDF/A validation failures discovered at the archive boundary rather than at generation; signing failures from expired intermediates, missing TSA connectivity, or clock skew, which surface as rejected documents downstream. Mitigation: assert on structural properties in tests (page count, text extraction of key fields, veraPDF pass, signature validity via openssl verification) rather than eyeballing rendered output.
Ramp-up. Low for developers — Composer install plus a facade; the API is conventional. The real ramp-up is domain knowledge: PDF/A and PDF/X conformance rules, PKCS#7 chain and timestamping semantics, and the CSS subset. Budget for one engineer to become the internal owner of document conformance, because that expertise is not transferable from the incumbent browser-based toolchain.
Recommendation. A conditional, scoped trial — not a platform bet. Worth a two-week spike if the driver is deployment constraint (no container, no shell access), the need for in-process merge plus signing, or licence friction with FPDI. Not worth it as a default replacement for a working dompdf/mPDF pipeline, and not admissible for signing or archival compliance until repository provenance, CI evidence, and external conformance validation are in hand. Gate the decision on the provenance questions above; if Repository: unknown cannot be resolved, decline.
How can I help you explore Laravel packages today?