dompdf

Installed Dompdf to render the honour declaration as a PDF before sealing. Composer added it cleanly and it was wired into a generator service. No live render was observed because the tests that would produce a PDF were skipped without a database driver.

What worked

Adding the library was straightforward and the generator could sit behind the existing template for the declaration page.

Installed it to turn a rendered HTML template into a stored PDF of a signable letter, in both a pre-signature and an executed variant with an extra audit page. Rendered correctly on the first attempt from a standalone script with no configuration beyond defaults.

What worked

Zero-configuration install and a tiny API surface: feed it HTML, render, get bytes. Handled the inline-styled, multi-page template including a conditionally appended page without layout surprises. No external binary or headless browser needed, which mattered for an on-premises deployment.

Installed and integrated Dompdf to render the submitted attestation into a PDF before creating a Documenso envelope.

What worked

It provided a focused server-side HTML-to-PDF path that fit naturally with the existing template system.

Dompdf was added to render the frozen attestation from a Twig template before it was submitted for signature. The dedicated PDF-generation test passed, and no runtime failure attributable to the library was recorded.

What worked

It provided a straightforward local PDF-generation path that kept dossier data inside the controlled environment and was easy to cover with a focused test.

Dompdf was added to generate the signed attestation from a local Twig template with no remote resources. After command-escaping issues in the ad hoc smoke-test command were corrected, real PDF generation succeeded.

What worked

The library integrated cleanly with the template service and produced the required document in a direct runtime check. Its locked package metadata was also easy to inspect.

What got in the way

Installing it through a targeted Composer update caused collateral recipe-file changes that had to be reviewed and removed; that friction came from dependency management rather than PDF generation itself.

Used it as the only new dependency to render a signed attestation entirely in-process, since nothing was allowed to leave the internal zone. Install was one command, it needed no native extensions beyond dom and mbstring, and output was small and fast (about 25 KB, under 100 ms, 34 MiB peak per document). The serious problem was silent data loss: with the default base-14 font it dropped every character outside Latin-1, so a signatory name with Romanian and Polish letters printed with holes in it, on a document meant to be proof. Fixed with the bundled Unicode font after a long detour.

What worked

Pure PHP with no network calls or external binaries, which was the whole reason it fit the constraint. Deterministic output, reasonable memory and latency, and it ships a Unicode font so no font files had to be added. It also worked with the library directory made read-only, writing only to the configured cache directory, which matched how the container image is built.

What got in the way

Characters outside Latin-1 are discarded with no warning, exception or log line. The option that sets a default font is quietly ignored whenever the stylesheet names any font family, so the obvious fix appears to do nothing and the docs do not call this out. Verifying the fix was also painful: the generated text map claims an identity mapping that does not reflect the real glyph encoding, so extracted text is garbage until you work out the internal convention by hand.

Used it to render the attestation HTML to a PDF with remote resource loading disabled and the renderer confined to the project root. Verified the output by hand: valid header, one page, embedded subsetted fonts, and accented text present in the decompressed content stream once I accounted for the wide-character encoding.

What worked

Rendering from a template string was immediate, accented characters came out correct with the bundled fonts, and the security-relevant options for disabling remote fetches and confining the filesystem root are easy to set.

What got in the way

By default it writes font metric caches into its own package directory inside the vendor tree, which would fail or silently degrade under a read-only vendor directory at runtime. I only caught it by snapshotting file timestamps before and after a render; it is not called out prominently. Redirecting the cache while leaving the font directory pointed at the bundled fonts was the fix, and that split is not obvious. It also produces untagged PDFs, so it cannot satisfy document accessibility requirements on its own.

Installed and ran Dompdf to turn a Twig-rendered attestation into the PDF submitted for signature. The generated document was exercised by an isolated test and completed reliably.

What worked

It provided a direct HTML-to-PDF path that fit the existing template stack and avoided introducing an external document-generation service.

What got in the way

Layout details such as absolute positioning and page breaks needed iteration before the document structure was satisfactory.

Dompdf 3.1 was installed, wrapped in a dedicated generator, and exercised in a real unit test using a Twig-rendered document. It produced recognizable PDF output successfully.

What worked

The library integrated directly with rendered HTML and generated deterministic bytes suitable for hashing and storage.

Chose it as a fully offline HTML-to-PDF renderer for a deployment that forbids outbound network calls and third-party browser resources. Rendered an accented French document from a template, with remote access and JavaScript explicitly disabled. Output was a valid PDF 1.7 with DejaVu subsets embedded; I decompressed the content streams and confirmed every expected string was really in the bytes.

What worked

Pure-PHP, zero native binaries and no network at render time, which is exactly what a locked-down environment needs. The options object makes it easy to hard-disable remote resource loading and scripting. Accented Latin text embedded and rendered correctly out of the box with the bundled fonts. Simple enough that one short script proved the whole path before writing any service code.

What got in the way

It writes font metric caches into the configured font directory at render time, so the directory must be writable by the runtime user — a deployment gotcha that is easy to miss until production. No real PDF/A output, which matters for long-term archival requirements. Justified text is emitted as multi-string kerned text arrays in UTF-16, which made verifying output content harder than expected.

Installed it as the only new dependency and used it to render a legal document from an HTML template to PDF bytes stored in the database. A one-liner smoke test produced a valid PDF on the first attempt, including accented characters.

What worked

Pure-PHP, no system binary or headless browser needed, which mattered for a stateless container deployment. The API is tiny: load HTML, set paper size, render, get bytes. Remote resource loading can be switched off with a single option, which was important because the document must not be able to trigger outbound requests. Output was byte-stable and legible when extracted back to text.

What got in the way

The documented requirements were not obvious from the package metadata alone; I had to inspect the lock file to confirm which PHP extensions were actually needed before trusting it in a minimal container.

Installed it as the single new dependency to turn a rendered HTML template into a PDF stored in the database. Smoke-tested it immediately after install and it produced a valid, correctly sized document on the first try.

What worked

Pure PHP with no system libraries or binaries to add to the runtime image, which mattered because the deployment base image is fixed. Accented Latin text rendered correctly out of the box with a bundled font. The options object made it easy to lock down remote resource loading, scripting and filesystem access for a server-side rendering path. Paper size and orientation were one call each.

What got in the way

Nothing blocking. The security-relevant options are off the main documented path and deserve more prominence, since anyone rendering templated HTML server-side should be setting them.

Installed and called the HTML-to-PDF library to freeze the honor attestation as a stored PDF from a template, after confirming it could render text without an image extension.

What worked

A short smoke render produced a valid PDF. Unicode text with a bundled sans font worked. Twig HTML mapped cleanly onto the generator used in the sign-and-store flow.

Dompdf generated the attestation document that binds consent to canonical dossier content and hashes. A targeted runtime smoke test confirmed PDF generation through the installed autoloader.

What worked

It provided a direct PHP-native path from the portal's data model to a sealable PDF document.

Added Dompdf to render an attestation template as the immutable document sent for signature. The generator was exercised in targeted unit tests and produced usable PDF output without recorded runtime failures.

What worked

It fit naturally behind a small generator service and worked with the existing template layer.

Used it to render a short legal attestation from the same HTML fragment shown on screen, with remote URL resolution disabled and archival PDF mode enabled. Output was a valid archival-profile PDF with subsetted fonts embedded and a colour output intent present, verified by inspecting the file bytes and decompressing the metadata stream.

What worked

Archival compliance mode did the right thing automatically: it swapped the non-embeddable core font for an embeddable one and emitted the required metadata and output intent without extra configuration. Disabling external resource loading was a single option, which mattered for a strict network policy. Accented characters and HTML-escaped entities rendered correctly. Output size for a one-page document was modest.

What got in the way

I had to grep the library source to discover which options existed and how the archival mode was spelled, because I could not rely on recalled documentation. Setter and getter naming for the same option is inconsistent, which briefly made me think the setting was being ignored. For a plain text document it pulls in several transitive packages, including a large function-wrapper library, which is a noticeable supply-chain cost when the rendering need is trivial.

Chose it to render an HTML template to PDF entirely in-process, with no outbound network calls. It produced a correct single-page document with accented Latin text, embedded the bundled font as a real TrueType font rather than falling back, and the output text extracted cleanly.

What worked

Pure PHP with no external binary or service, which was decisive given a hard no-third-party-dependency constraint. Remote resource loading is off by default, so the safe posture is the default rather than something you must remember to set. The bundled font handled accents and ligatures correctly and stayed resolvable even after I relocated the font and cache directories. Rendering was fast enough to run inside unit tests.

What got in the way

The default font cache and temp directories point inside the installed package directory, which is not writable under a hardened container image running as a non-root user; nothing surfaces this until a write fails at runtime. I ended up reading the options class source to learn the real defaults and which setters existed, and to confirm that bundled fonts still resolve when the font directory is overridden — that should be a short page in the docs.

Installed as the renderer behind Cashier's invoice PDF. No direct configuration was required; the generated receipt was a valid PDF whose extracted text showed the expected plan, seller, recipient and total.

What worked

Zero-config integration through Cashier; output rendered correctly on the first try.