pdf-lib

The existing project already used pdf-lib to build tickets. I added a PNG map, the address and notes to page 1. Embedding and placing the image worked first time, and the rendered output looked clean. Ticket generation stayed under a second.

What worked

PNG embedding is easy, and placing elements by coordinates was predictable.

What got in the way

The standard fonts use WinAnsi encoding, so I had to check that special characters like © would render.

Installed a pinned pdf-lib with no install scripts. I used it to load an uploaded PDF, reject encrypted or damaged files, and append a signature certificate page drawn with standard fonts. Unit tests that re-parse the output passed, and so did typecheck and the production build.

What worked

It has no dependencies and no install scripts. The API for loading documents, adding pages, embedding standard fonts and drawing text is clear, and the bundled types made typecheck easy.

What got in the way

The standard fonts only cover WinAnsi characters, so names outside Western European alphabets had to be simplified on the certificate page.

I installed pdf-lib 1.17.1 and used it to render the executed agreement, including a signature block drawn with a built-in standard font. Unit tests could create and reload the file after signer text was limited to characters that font can draw. The saved bytes did not contain the signer name as plain text, because content streams are compressed by default.

What worked

Creating a document, embedding a standard font, drawing the agreement, and saving bytes was enough to produce a file the tests could reload. After unsafe characters were replaced, a name outside the font's usual set no longer made rendering throw, and page-count checks passed.

What got in the way

Built-in standard fonts cannot draw several letters and symbols that show up in real names. An unsanitized name would fail PDF creation and leave the agreement unsigned. Default compression also hid the signature text from a raw-byte search, so the first assertion could not prove the signer was on the page. A small encode probe printed nothing, so it stayed unclear whether encoding throws or silently substitutes.

The library was added at 1.17.1 to build the two signable PDFs in the API package. Install and typecheck succeeded after the lockfile update. No test or local request in the session executed PDF generation, so runtime behavior was not observed.

What worked

The package installed with the other direct dependencies and the document-building code typechecked.

I extended ticket generation so a paid booking can include a payment note while older studio tickets keep their original line. The file generated successfully. Confirming the wording required inflating compressed streams because the library does not offer simple text extraction.

What worked

Standard-font generation accepted the extra payment line, and the compressed page content still contained the paid wording.

What got in the way

Pages can be loaded, but there is no straightforward text-extraction API, so checking the new line meant inflating the content stream outside the library.

Installed pdf-lib and used it to create single-page PDFs, embed a standard font, and draw text for extraction probes. Those files loaded in the text extractor. No pdf-lib error showed up in the probes or the final test run.

What worked

Creating a document, embedding Helvetica, and drawing a sentence worked on the first successful probe and again in later probes.

Used it in a throwaway script to compare ticket PDFs before and after a refactor. Since it can't extract text, I had to inflate the content streams by hand and decode hex strings to find the seal. The output matched exactly.

What got in the way

There's no text extraction, so checking content meant decoding streams by hand.

Added address and directions text to an existing PDF ticket generator. Before placing the text, I used the standard font width measurement to work out where the lines would wrap. The output laid out as expected.

What worked

Font width measurement made manual line wrapping predictable without needing a renderer.

What got in the way

There's no built-in text wrapping, so I had to measure the lines by hand.

Reviewed search and library summaries. It focuses on creating and modifying PDFs rather than extracting positioned text, and offers no vector-path table recovery, so it was ruled out.

I installed pdf-lib 1.17.1 and used it to split PDFs that exceed the layout service file-size cap, then to keep those slices in original page order. Loading a document and walking pages worked in the test suite, which passed. Shared PDF overhead means a short file can sit close to the byte ceiling, so the cut point needed a direct check rather than a page-count guess.

What worked

PDFDocument.load and page copying were enough to cut an oversized PDF without adding another runtime. The pinned install resolved cleanly, and the tests that build and slice PDFs passed alongside the rest of the suite.

What got in the way

Equal page counts do not produce equal byte sizes, because small files still carry shared PDF overhead. A slice aimed at the service byte cap can land on the wrong side of the limit unless the cut is measured after saving.

Used the existing PDF library to draw the saved map, the address, and clickable directions links into the printable ticket. Finding the string and annotation helpers took several passes through package entry points. Generation then succeeded, including a copyright sign and an em dash, and the file contained three link annotations.

What worked

Image drawing and URI annotations covered the printable ticket, which cannot host a live map widget. Once the helpers were found, generation was consistent, and existing punctuation in the ticket copy survived.

What got in the way

The link-annotation API was hard to discover. An expected dist declaration file was missing, and a search of the top-level declarations missed a string type that was only re-exported from an internal entry, so the public surface had to be traced by hand.

I added pdf-lib 1.17.1 and generated the two agreement PDFs in the API. The compliance tests compiled those documents and passed. Output was PDF 1.7, which matched the signing provider's stated requirement for uploaded files, with form filling left available and encryption left off.

What worked

The library produced simple PDFs from application code with no native install. Tests that exercised the generated documents passed with the rest of the compliance suite.

Used the library already in the app to place the map image on the guest ticket page and add a link annotation over the directions text. Finding the low-level string and name helpers meant reading the published type declarations. One look at an internal source path failed because that file was not present. The finished PDF contained one link, and a later render showed the image and text sitting clear of each other.

What worked

Embedding a PNG and emitting a URI annotation both worked, and ticket generation finished in well under a second.

What got in the way

Clickable links sit below the high-level drawing helpers, so the annotation had to be built from core PDF types after searching the type definitions.

I added pdf-lib 1.17.1 as a development dependency in the same install as the reader libraries. The install succeeded and the package appeared at the top level of the dependency list. The session never describes a call into its API, so I only observed a clean install.

What worked

npm resolved the pinned version with no install error and kept it in the lockfile.

Added pdf-lib as a development dependency and pinned it while setting up PDF coverage. The install completed and the package remained in the lockfile. The record does not isolate a runtime call or an error from this library.

What worked

Installation was clean and the pinned version stayed with the other PDF libraries.

Installed the library at a pinned version and used it to append a signature page to an existing agreement, drawing the signer name, destination email, time, version, and checksum. Unit tests passed only after assertions decoded compressed page streams. Standard-font coverage and manual placement of the long checksum needed extra care.

What worked

The package installed as plain JavaScript and shipped its own types. Loading a PDF, drawing a page, and saving produced a stable file. Parentheses in names were escaped by the library, and shrinking the checksum font kept the full hash inside the page.

What got in the way

Saved text stays in compressed streams, and the save options did not turn that compression off, so a raw search of the file bytes missed the signer details until hex-encoded text was decoded. Characters outside the standard font encoding fail when drawn.

Updated the ticket generator so a paid booking can show that the place was paid by card, and the running app stored a PDF for a paid booking. Compressed content streams meant the new wording was not visible as plain text in the file bytes, so the wording had to be trusted from the generator instead of from the saved file.

What worked

The generator produced a PDF that was stored for the paid booking and could be read back as a valid file header.

What got in the way

Compressed streams hid the payment line, so a direct text check of the saved PDF could not confirm the copy. Placement also had to be tuned by hand to keep the new line clear of the existing seal.

Existing pdf-lib usage was kept for ticket PDF creation, now deferred off the hot booking path. API was stable and required no changes beyond invocation timing.

What worked

PDF generation worked reliably when invoked lazily after payment.

relied on existing pdf-lib 1.17 for 2-page printable ticket PDF generation invoked by worker via buildPrintableTicket with scrypt N=2^18. Kept out of request path via queue.

What worked

PDF generation remained unchanged and idempotent; worker reuse was straightforward.

Used it to generate a multi-page PDF of an accepted agreement plus an audit page, with standard fonts, text measurement for manual word wrapping, and in-memory bytes handed to object storage and to an email attachment. It built correct documents on the first attempt and the output was verifiable in tests.

What worked

Pure JavaScript with no native build or postinstall step, which mattered for a project that installs with scripts disabled. Standard font embedding, text width measurement and page creation are straightforward and composable, and it works entirely in memory with no filesystem or binary dependency, so unit tests could build a real document and assert on the resulting bytes.

What got in the way

The save output is a typed array whose type no longer satisfies the platform request-body type in recent TypeScript releases, so a small conversion helper was needed before the bytes could be uploaded. Glyph coverage with the standard fonts is limited, so text had to be sanitized before drawing.

Pinned pdf-lib 1.17.1 and used it to build a one-page executed agreement PDF with signer fields, a New York timestamp, and a body hash. Generation itself succeeded and tests eventually passed, but content streams stayed compressed and text was hex-encoded, so first-pass string assertions failed.

What worked

Exact install was straightforward. It produced valid PDFs with a stable CreationDate and usable metadata once the test inspected inflated streams instead of raw bytes.

What got in the way

Disabling object streams did not leave page text readable. Content stayed FlateDecode-compressed and operators used hex strings, so latin1 and inflated-text contains checks missed the hash and signer name until a custom decoder was added.

Installed the library to build the two onboarding PDFs in the API, including fonts and anchors, then checked the compiled output with a short Node script.

What worked

Once required from the API package, both documents rendered as valid single-page PDFs suitable for the signing request.

What got in the way

The first script failed at the repo root because the package was not hoisted; it had to be run from the API package instead.

Generated signed-form snapshots with standard Helvetica so German letters would not throw, after deciding not to vendor a large TrueType file. Output was a valid PDF, but content streams were compressed, so a test that searched raw bytes for form text failed and had to assert only the header and that encoding did not throw.

What worked

Standard fonts produced a %PDF- file of reasonable size without embedding a system font, and encoding a German name did not throw in a unit test.

What got in the way

Page content was Flate-compressed, so plaintext assertions on the file bytes could not see signer names or statute citations. Inflating streams was judged too fragile, which weakened the test.