Skip to content

Reproducible output

A document generated today can be generated again next month, exactly: the same template version, the same values and the same creation date give the same bytes. Every output also says what made it, so a question about a file can be answered from the file.

What could make two renders differ is pinned:

  • The template version never changes once published.
  • The values are what you send.
  • The date, which a PDF records in several places, is the createdAt you send with a render, job or batch. Without one, a synchronous render takes the time of the request, and a job or batch the time it was submitted, so a job retried later, or the records of one batch, share a date.
  • The engine is named on every output.

PDFs, PNG and JPEG images, ZIP files of images and the merged PDF of a batch are then byte-identical.

Every PDF names the engine that made it, its version and build, in its producer and in its metadata, with the template and version it came from. The reports of outputs, jobs and batches add:

  • engine: the engine that rendered it, and publishedWith, the one the version was published with.
  • packageSha256: the template package’s fingerprint.
  • fonts and profiles: the fonts whose glyphs appear and the colour profiles used, each by fingerprint.
  • valuesSha256: the values as sent, fingerprinted.
  • fileCreatedAt: the date written into the file.

So whether two files came from the same input is a comparison of fingerprints, not of documents.

Templates don’t pin an engine: when Paprika is upgraded, every template renders with the new one. To make that safe, each version records a reference rendering when it is published, and whoever runs Paprika compares every stored version against the new engine before rolling it out (upgrading). A change, even an improvement, is found before your documents change, not after.