PDFKit

Used it to render a multi-section agreement document entirely on the local machine: heading, a details block, long wrapped body text, a signature block in an italic face, and a footer, returned as a buffer from a promise wrapper over the stream events. Output was a valid document on the first try and byte-stable across repeated renders.

What worked

The streaming document API is small and predictable: set a font and size, call text, and flow handles wrapping and pagination. Built-in standard fonts meant no font files to ship. Wrapping the data/end events into a promise returning a buffer was a few lines. Repeated renders of the same inputs produced identical bytes, which made verification easy.

What got in the way

Verifying the rendered text programmatically was harder than expected: content streams are compressed by default and the text is written as kern-split hex strings inside positioning arrays, so a naive search finds nothing. There is no documented switch or helper for dumping the text back out, so I had to force compression off by substituting a subclass and then write a small decoder. Also the package's manifest is not exposed through its subpath exports, so reading the installed version the obvious way errors.

Generated two realistic multi-line invoice documents in different languages and currencies, one including a negative credit line, purely to give the extraction pipeline something non-trivial to read. Both rendered correctly on the first attempt.

What worked

Simple imperative drawing API meant a believable table-and-totals layout took one short script. Accented text and currency symbols rendered correctly with no font configuration. Output was clean enough that extraction accuracy could be judged against it with confidence.

What got in the way

Writing is asynchronous in a way that isn't obvious, so I added a small wait before reading the file rather than relying on the obvious sequence.