Skip to content

Build1 publisher2 min readPublished

Stamping typeset PDFs cuts a 180,000-copy watermark run from 90 CPU-hours to 2

Stamping watermarks onto typeset PDFs costs about 2 CPU-hours for 180,000 monthly copies versus 90 for per-recipient HTML rendering, a dev.to post estimates. That assumes the masters are already typeset, and seven years of copies still fill about 21 TB.

The Engineer · Build desk

Illustration accompanying Stamping typeset PDFs cuts a 180,000-copy watermark run from 90 CPU-hours to 2

What happened

  • A dev.to post models 30,000 source documents of about eighteen pages, each sent monthly to six external recipients with a distinct watermark per recipient to trace leaks.
  • Re-rendering HTML in a headless browser at an assumed 1.8 CPU-seconds per document costs about 90 CPU-hours for the month's 180,000 outputs.
  • Drawing the watermark as an overlay on an existing PDF at an assumed 40 ms per copy brings the same batch to roughly 2 CPU-hours, a ratio the author puts at 45 to one.
  • At 1.4 MB per copy the post counts 252 GB of new files a month, a bit over 3 TB a year, and about 21 TB over a seven-year records policy.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • contradiction Anyone citing a 100x saving is citing the post's framing; its own worked inputs support 45x, under half of that.
  • constraint The large saving belongs to pipelines whose masters are already typeset; a team that must lay out fresh sources every month keeps most of its layout bill.
  • decision A records team choosing between keeping every copy and regenerating on demand has to prove byte-identical output first, or keep paying for the copies.
  • cost Storage follows share count, so each extra recipient per document adds another 1.4 MB copy that sits in retention for seven years.

Print layout is the expensive half of PDF generation, the post argues, and a stamp skips it [10]. Pagination is a global problem [11]. A font substitution on page 3 can push a heading onto page 4. Every later break then shifts, the page count changes, and so does a "Page 7 of 214" footer that is itself laid-out content [11]. Engines resolve this with multiple passes and a fixed-point check. When the passes do not converge, they pick something and move on [12]. Stamping draws on pages that already exist, so none of that work runs again [10].

A browser pipeline that regenerates from markup pays the pagination cost on every output file, so its bill grows with recipients instead of documents [15]. The post's 90 CPU-hours also come before the memory ceiling that forces teams to cap headless-browser concurrency well below core count [3][9].

The 45-to-1 figure rests on two placeholder constants and one assumption: that the masters are already typeset [4]. "The ratio is what you should carry away, not my placeholder constants," the author wrote [7]. Readers are also told to measure p50 render time on their own page templates before going near a capacity plan [8]. I would add a test for the assumption. If all 30,000 masters needed a fresh layout each month at 1.8 s, that is 54,000 CPU-seconds, or 15 CPU-hours [2]. The stamping path would then total about 17 CPU-hours against 90, roughly 5 to 1. With six recipients per document, the ratio stays under 6 however cheap the stamp gets [3].

Retention turns on determinism. ISO 32000-2 files carry a creation timestamp, a file identifier and generated font subset tags, so two runs over identical input give different bytes unless those are pinned [13]. For a team whose compliance position is that it can regenerate the exact artifact, the post says "byte-level determinism is not a nice-to-have, it is the entire claim." [14] A stamped copy takes its page breaks from the master, so a font substitution cannot move them at stamping time [5]. The metadata still has to be pinned [13]. The available text of the post ends before it says which artifacts a stamping pipeline lets a team stop keeping.

Without byte-identical regeneration, the copies themselves are what a team has to keep [14]. The post calls retention the only cost term that grows without anyone deciding to grow it [18]. "Nobody reviews that line item," the author wrote [17].

What to watch

  • Measured p50 render and stamp times from a production template set, showing whether the 1.8 s and 40 ms placeholders sit anywhere near real workloads.
  • A PDF pipeline that pins creation timestamps, file identifiers and subset tags and shows byte-identical output across runs, which would make regenerate-on-demand a defensible retention policy.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories