Type to search. Arrow keys to move, Enter to open, Esc to close.

All research
Document generationState as of: 2026-10

Reproducible PDF output

How committed sample PDFs change only when their content changes, so a rebuild does not leave eight modified binary files behind.

Research question: How can a committed PDF change only when its content really changed?

Project requirement

Sample PDFs are committed so the README preview and downloads work without a build. If every build writes a new timestamp into the PDFs, every run shows eight modified binary files and the real change is hidden.

Method and validation

  • Compilation with a fixed SOURCE_DATE_EPOCH and FORCE_SOURCE_DATE=1.
  • latexmk -g, which forces a run even when latexmk sees no change.
  • Two consecutive full builds compared by file hash.
  • pdfinfo after every build for the page count, plus a word count for the cover letter.

Findings

  • Two builds produced hash-identical PDFs, so the committed output changes only with the content.
  • Without FORCE_SOURCE_DATE=1, pdfTeX uses SOURCE_DATE_EPOCH only in the metadata, not in dates printed in the text such as \today.
  • latexmk does not notice changed environment variables such as the timestamp or TEXINPUTS, so the -g flag is needed.
  • Measurable limits, a one-page CV and a word range per language for the letter, run as part of the build instead of a manual check afterwards.

Decision

A fixed timestamp in the build, latexmk -g, and page and word checks after the build that warn instead of failing, because a long CV is still usable output.

Limits and open questions

  • Verified on one machine with one TeX installation; another TeX Live version may produce different bytes (unverified).
  • No automated PDF build in CI yet.

Sources