Tests for a PDF ·

The test suite runs four inexpensive checks on every PDF produced by the build. First it verifies the file starts with the bytes %PDF-. Second it uses pdfinfo to confirm that the Author and Title fields are non-empty. Third it ensures the document has at least one page. Fourth it runs pdftotext and requires at least 200 characters of output, which is intended to catch cases where the PDF is merely an image of text.

To investigate the common advice to disable ligatures for ATS friendliness, the author created two PDFs that differed only in the ligatures setting. Both PDFs contained the same Unicode text, and pdftotext extracted identical strings from each. The reason is that Typst writes a ToUnicode CMap that maps each glyph back to its underlying Unicode characters, so the extraction works regardless of whether ligatures are present.

Although the extraction was identical, the author kept the ligature-off setting as a defensive measure against hypothetical parsers that might ignore the ToUnicode table or against PDF producers that do not include one. The cost of this defense is that the normal em dash ligature (---) is disabled, forcing the use of an explicit symbol function (sym.dash.em) whenever a date range is written.

While reviewing the test code, the author discovered that the dictionary used to validate author and title was keyed on an outdated filename (dist/resume/main.pdf). After renaming the output to a more recruiter-friendly name, the condition relative in EXPECTED was always false, so the author check never executed. Changing the expected author to a different name still resulted in a passing test, revealing that the suite would not detect a mismatch.

The episode highlights three practical lessons for engineers: validate the actual output that downstream systems will consume, be aware that defensive choices can introduce non-obvious workflow overhead, and regularly verify that test expectations match the artifacts they are meant to check.