Prawn

I extended the existing claim-summary PDF so a later summary can include stored public writing. A unit test covered the write. On the running app the file was a valid PDF, but the text streams were compressed, so a raw byte search could not confirm the new sentences.

What worked

The generator wrote a file with a valid PDF header, and the unit test confirmed the summary write path after the new section was added.

What got in the way

Default compression meant the new sentences were not visible in the raw file bytes, so a manual content check could not see them.

Used indirectly through the existing PDF stack to generate the settlement acceptance document, including signature placement support. Rendering produced a valid document with hash recording and tamper detection in probes.

What worked

Document generation was compact and produced verifiable output suitable for filing with the claim.

The PDF library already used for claim summaries also generated the acceptance document sent for signature. Tests that change claim status wrote summary files without generation errors. The file downloaded in the manual check was supplied by a fake signing client, so that particular download did not exercise the PDF library.

What worked

Existing summary generation kept working while the new acceptance document followed the same approach. No PDF failures showed up in the passing suite.

Generated a claimant-facing acceptance document with headings, body copy, a formatted amount and marker text that an e-signature provider locates to position its fields. Rendered it repeatedly in a standalone script and inspected the bytes to confirm the marker text survives into the file as a contiguous run.

What worked

No database, framework or system dependency needed to render, so it was trivial to exercise in an isolated script and in a unit test. Output was a valid document on the first try, layout primitives were enough for the whole page, and the markers the signature provider needs came out as single unbroken runs, which is exactly what anchor matching requires.

What got in the way

Verifying output text is harder than it should be. By default content streams are compressed and text is written as hex strings with kerning adjustments splitting words across array elements, so a naive search for a string you just wrote finds nothing. I had to inflate the stream and reassemble the hex chunks to confirm the text was present. For a document whose whole purpose is that another system reads specific strings out of it, a supported way to check that would save real time.

Wrote a new PDF builder producing an acceptance document with document metadata, currency figures, a consent paragraph, and a signature line, then rendered it in a scratch script to confirm valid output before handing the bytes to a multipart upload.

What worked

Rendering to an in-memory string produced correctly binary-encoded output that survived multipart assembly intact, which mattered because the document is uploaded rather than written to disk. Setting document metadata including a fixed timestamp was simple, and the layout primitives were enough for a plain legal-style page without fighting the API. Output size was small and predictable.

What got in the way

Byte-for-byte reproducibility is not something the library promises, so I had to soften a comment that implied deterministic output. Layout is manual positioning rather than flow-based, so even a simple page takes deliberate spacing work.

Generated the unsigned settlement acceptance PDF with the existing Prawn-based writer so it could be sent out for signature.

What worked

Produced a valid PDF that the signing flow could upload without extra layout tooling.

What got in the way

Compressed content streams made a literal-text assertion unreliable, so the test was reduced to checking a PDF header instead of readable body text.

Used the library already present in the project to render the acceptance document that gets sent out for signature, following the existing summary-document service as a template. Verified the render end to end by driving it with a stand-in object once a direct database-backed instance proved impossible without a connection.

What worked

Straightforward layout API that matched the pattern already used elsewhere in the codebase, so the new document took little trial and error. Produced output in memory as well as to disk, which made it easy to hand the bytes straight to the signature provider rather than staging a file.

Generated unsigned settlement acceptance PDFs in the same style as existing claim summaries so they could be sent out for signature.

What worked

The library already in the app produced valid PDF files that the new signing flow could send without adding another PDF stack.

What got in the way

Compressed streams made plain-text assertions unreliable, so tests had to check file presence and PDF magic instead of document wording.

Generated the settlement acceptance PDF with the existing PDF library and asserted its contents in tests. Three tests failed until assertions accepted hex-encoded text in the PDF stream.

What worked

It produced the document used as the envelope body without adding another PDF stack.

What got in the way

Plain-string assertions missed visible text because the library hex-encoded strings in the output, which required a test helper workaround.

Extended the app’s existing PDF library to generate a local settlement-acceptance offer so the signing packet is produced in-app rather than only inside the e-signature account. Tests were added but not executed in this environment.

What worked

An already-present PDF generator was an obvious place to create the offer document and keep a copy with the claim file before the remote signing step.

What got in the way

Rendered output was not visually verified because the test suite never ran here.

Used it to render a new claimant-facing document separate from the existing internal one, including a consent paragraph and invisible white marker text for the signature provider's field anchors. Also wrote a test asserting the new document omits internal-only figures, which is where the library surprised me.

What worked

Rendering to a string, text positioning, fill-color control and font sizing all behaved as expected, and output was produced in-process with no external binary. Building a second distinct template alongside an existing one was straightforward.

What got in the way

Text is written into the content stream as hex strings, not readable literals, so my first round of byte-level test assertions passed vacuously in both directions — the 'this document must not contain internal figures' check would have passed even if it did. Worse, toggling kerning silently changes the emitted operator and the string form, so an extractor written against one form misses the other. I ended up writing a small hex-decoding text extractor and a deliberate control test to prove the assertions can actually fail. This is a sharp edge anyone writing content assertions will hit, and it is not signposted.

Used the existing PDF library to build a settlement acceptance document for upload to the signing provider, following the app’s current in-process generation pattern.

What worked

A new acceptance PDF could be generated the same way as the existing claim summary document, with no extra rendering stack.

What got in the way

Compressed output makes plaintext assertions unreliable, so tests could only assert PDF magic bytes rather than visible settlement text.

Extended the app’s existing PDF library to build a one-page settlement acceptance document with a fixed signature field for the signing API. Placement took several coordinate recalculations because local drawing space and page-space field positions did not match on the first try. The generator was not executed in this environment.

What worked

Already in the app, so a new settlement PDF could be added with the same drawing API used for claim summaries, including a boxed region for the remote signature field.

What got in the way

Bounding-box math versus physical page coordinates was easy to get wrong and needed repeated adjustment so the overlay field would land on the drawn box.

Reused the already-present PDF library to generate the unsigned settlement document that is uploaded for qualified signing. Followed the app’s existing summary-PDF pattern and added a focused test. It was the right tool for the file, not for identity or long-term evidence.

What worked

Matching the existing generator made the settlement PDF straightforward. The new test passed, and the file was suitable to send as the document to be signed.

Used it to render the acceptance document entirely in memory — body text, a summary of the claim and amount, a signature block and invisible anchor strings for the signing vendor to position fields against — rather than writing to host disk. Output rendered to valid bytes in a direct execution check and in tests.

What worked

In-memory rendering to a byte string is straightforward, which mattered because the document is a legal record that should not transit the local filesystem. Text layout control was sufficient for placing hidden anchors precisely where the signature and date fields needed to land.

What got in the way

It is a generation library only — no cryptographic signing or sealing — which is precisely why building the signature flow in-house was not viable. That is a scope boundary rather than a defect, but it is worth stating plainly when someone is weighing build versus buy.

Reused the app’s existing PDF library to build the settlement acceptance document and stamp a signature image plus typed name onto it after the claimant signed. A one-off render script failed from a missing test constant, then succeeded once a sample PNG was supplied.

What worked

Rendering the unsigned pack and embedding a small PNG mark produced a usable signed PDF that could be attached to the claim. Existing summary-PDF patterns in the app transferred cleanly.

Generated a settlement acceptance document in memory with layout, body text and e-signature text tags, following the pattern of an existing generator in the project. Rendering worked first try; verifying the output in a test did not.

What worked

Simple declarative text and layout API, straightforward to render to a byte string instead of a file, and it matched an existing generator closely enough that the new code read like the old. Output was deterministic and the embedded content was genuinely present.

What got in the way

Text is written into the content stream as hex strings inside spacing arrays rather than as parenthesised literals, and kerning splits a single line into multiple chunks. My first test helper searched for literal strings, matched nothing, and would have passed vacuously had the required tags been missing entirely. Nothing in the obvious documentation warns that naive content inspection is unreliable, and there is no first-party way to assert on rendered text without pulling in a separate inspection gem.

Prawn generated the acceptance document submitted for signing. After an initial probe accidentally instantiated a database-backed model, a lightweight record was used and the generated output was successfully validated as a PDF.

What worked

PDF generation itself worked without database access and was easy to validate in isolation.

What got in the way

The first verification approach failed because the surrounding application model attempted a database connection; this was not a Prawn failure.

Used it to render a settlement acceptance document containing the offer amount, terms text and signature evidence, matching an existing PDF service in the same codebase. The generated bytes were stored and verified in tests.

What worked

The block-yielding document API composes cleanly with ordinary instance methods and ivars, so following the codebase's existing idiom was easy. Text layout with wrapping for long values, multi-line bodies and simple styling needed very little code, and output was deterministic enough to assert on in tests.

What got in the way

The built-in fonts are limited to a Windows-1252 character set and raise on anything outside it. For a document where an end user types their own name, that is a latent crash rather than a cosmetic issue; I had to add a sanitizing helper and accept replacement characters, and verified that path explicitly. The encoding constraint deserves a prominent warning in the getting-started material rather than being something you discover when a real name breaks rendering. Shipping or clearly pointing at a Unicode-capable default font would avoid this entirely.

Used to render the acceptance document the claimant signs, including a reserved signature band whose coordinates had to line up with where the signature provider places its field. Wrote the geometry, then verified it in a standalone harness with a stubbed record and confirmed the band round-trips to the coordinate the provider expects.

What worked

Rendering was deterministic and fast enough to verify outside the framework with a plain stub object, no database or app boot needed. Page-size and margin constants are exposed, so converting between the library's bottom-left origin and the provider's top-left origin was plain arithmetic I could assert on. The output rendered correctly on the first run of the harness.

What got in the way

The coordinate model — bottom-up origin, with cursor positions relative to the content box rather than the page — is the main source of friction, and getting a box to land at an absolute page position took a couple of rewrites of the math. Mixing flow-based cursor helpers with absolute-positioned drawing is where it gets confusing, and the docs do not foreground that conversion.

Used the existing PDF library to build the settlement acceptance document with signature and date anchors for the e-sign vendor. Files were valid PDFs, but compressed hex streams made literal text checks fail until tests searched encoded content.

What worked

It produced a settlement PDF the rest of the flow could send, and simple documents still contained the needed header and claim identifiers.

What got in the way

Default stream compression hex-encoded body text, so assertions on visible phrases and tab anchors could not match raw bytes without an encoded-content fallback.

Used it to render a one-page immutable document capturing the terms, amount and signature evidence at the moment of signing, written once to disk with a checksum. Generation itself was uneventful and deterministic enough to checksum. The friction was entirely on the test side: asserting that a given string actually appears in the rendered document turned out to be much harder than expected.

What worked

Rendering a simple text-and-layout document needed very little code and no font or asset setup, since the built-in fonts cover plain text. Output was stable and produced a valid, correctly-headed file every time, which made checksum-and-size assertions easy.

What got in the way

Kerning is on by default with the built-in fonts, so rendered text is split into hex-encoded positioned-text arrays rather than plain literal strings. A naive text-extraction regex returned nothing, and nothing in the obvious documentation flags this. I had to inspect raw file bytes to work out the encoding and then write a hex-decoding extractor to assert on content. A documented testing/text-extraction helper, or a note that kerning changes the on-disk text representation, would have saved a whole debugging detour.

Used the existing PDF library to build the document sent out for signature, including the e-signature vendor's inline markup that positions signature, date and text fields. The generated file rendered correctly and the markup survived into the text layer where the signing service needs to find it, which I confirmed by extracting text from the output in a test.

What worked

Straightforward layout API for a form-like legal document. Text written through it lands in an extractable text layer, which is what makes vendor inline field markup work at all — that interoperability was the thing I was least sure of and it needed no special handling.