This is the quality checklist we use when a new Paperka generator is prepared for release. It is not a generic promise that a PDF “should print.” We generate real files, inspect their technical properties, render their pages back to images, and keep fixed-seed examples that anyone can download and compare.
1. Generate the file through the public workflow
The first useful test begins at the same endpoint as a visitor's download. We select a paper size, layout, content settings, and—where a puzzle needs one—a fixed seed. That matters because a test of an internal drawing method can pass while the download route, filename, locale, or submitted controls are broken.
For this check we created three A4 examples on 20 August 2026: a maze with its solution, a Sudoku with an answer page, and a mixed-math worksheet with answers. These are normal generator outputs, not hand-redrawn marketing mockups.
2. Verify the document, not just the filename
A file ending in .pdf proves very little. We check that its header identifies a PDF, that a parser can open it, that the expected number of pages exists, and that each page reports the requested dimensions. A4 should be approximately 595 × 842 PDF points; US Letter approximately 612 × 792 points. A swapped or silently rescaled page is a failure even when it looks plausible in a browser preview.
We also check the response type and download name. These small details catch routing mistakes where an error page is saved with a PDF extension or a configuration is ignored during export.
3. Render every page back to an image
Technical validity does not detect a heading clipped by a margin, a maze squeezed into a corner, or an answer key running beyond the page. We therefore rasterize the finished PDF pages and inspect the resulting images. This is deliberately downstream of generation: the renderer sees the same page geometry a PDF viewer or print system sees.
The visual pass checks outer margins, title and footer clearance, writing space, line contrast, consistent alignment, and the relative size of the main activity. Multi-page exports require every page to be checked; the answer page is not allowed to inherit a layout that only works for the question page.
4. Check the content and its answer key together
For worksheets, a beautiful page with a wrong key is worse than an ugly one. Math problems are compared with their calculated answers. Sudoku generation must preserve a valid completed grid while the puzzle shows only its clues. A maze solution must follow open passages from the marked start to the marked finish rather than drawing a decorative line across walls.
Fixed seeds make these failures reproducible. If variation 48201 exposes a problem, the same input can be generated again after a change. Random output is useful to a player; deterministic output is essential to debugging and to a teacher who wants replacement copies of the same activity.
5. Compare the on-page preview with the export
The preview is a fast planning aid, not a separate product. We compare its title, selected difficulty, page orientation, count badges, answer-key state, and dominant proportions with the exported file. Pixel-perfect identity is neither possible nor useful because the preview is responsive while the PDF has physical dimensions. The important promise is that a choice shown in the interface changes the downloaded document in the expected way.
This check has caught the sort of defect users notice immediately: a healthy full-size PDF paired with an undersized preview, or a control that changes on screen but never reaches the export service.
6. Run one practical print check when physical scale matters
Rendering catches most layout defects, but paper introduces printer margins, toner contrast, and scaling settings. For templates where measured spacing matters, the practical check is one page at 100% / Actual size on matching paper. A ruler can then confirm the intended grid or line spacing before a batch is printed.
We do not claim that one printer represents every device. Borderless settings, driver-added margins, and “Fit” options vary. That is why Paperka builds content inside safe margins and why the A4 versus US Letter guide explains the remaining printer-side checks.
What this evidence does—and does not—prove
The example PDFs let you inspect actual output before using the tools. The checklist describes repeatable checks, and the fixed seeds make two puzzle examples reproducible. It does not guarantee compatibility with every printer driver or promise that a difficulty label will feel identical to every learner. Those are limits worth stating plainly.
If an example renders incorrectly in your viewer, or your generated file differs from the selected controls, use the contact page and include the tool, paper size, and variation number. Those details turn a vague report into a case we can reproduce.