The editor above opens on an A6 postcard carrying fifteen pre-press problems, none of them visible on screen. Eight of them the panel repairs in place.
Print rejections are an operating cost you inherit by default. The only place to remove them is the editor you are already embedding.
The rejection loop is yours by default
Print jobs come back for a short list of reasons: no bleed, wrong trim size, an unembedded font, RGB artwork, an image placed larger than its pixels allow. The list is short and it does not change.
Most operations only catch them at the end. Files arrive from the customer already exported, a preflight tool or a prepress operator finds the problem, and a rejection goes back out. Then the cycle runs: rejection email, a customer who has never heard of bleed, a re-export, a second review. Every order that fails costs your support team that cycle, for as long as the product exists.
The fix has to live where the design still is
| File preflight | Design preflight | |
|---|---|---|
| Runs on | the exported PDF | the live design in the editor |
| Reads | content streams | named elements and your own metadata |
| Repairs by | patching the file, or rejecting it | editing the design object |
| Acted on by | your prepress operator | the customer, before submitting |
| Tools | PitStop, pdfToolbox, Acrobat, veraPDF | this demo |
A PDF has been flattened into content streams, so the checker sees glyphs and
image XObjects. The design still has its structure, so the checks read intent.
{{first_name}} is a merge field nobody filled in. The 84 DPI photo has a print
master, because the asset id is on the element.
That difference is what makes repair possible. Eight rows carry a fix: add 3 mm bleed, substitute an available font, raise type to 6 pt, thicken a hairline, move text onto the layout margin, fill the merge field, darken low-contrast text, fetch the print master. Each is an edit to the design object, so it lands on the canvas, joins the undo stack, and re-runs the checks. After export none of that is available. A file can be patched or rejected, and the person who caused the problem has gone.
Two details worth noting. The safe-area fix moves type to the layout margin rather than the 4 mm legal minimum, because landing text at exactly 4 mm satisfies the rule and leaves the card visibly out of alignment with the rest of the layout. Resolution is the one problem no fix computes away, since the pixels were never captured. That row fetches the master your asset record points at, and where there is no master it stays a plain failure with nothing to click.
What it checks
| Check | Rule |
|---|---|
| Trim size | matches the ordered product (148 × 105 mm) |
| Working resolution | 300 DPI. The SDK default is 72 |
| Bleed | 3 mm, and only required when artwork reaches the edge |
| Image resolution | 300 DPI at the size the image is placed |
| Font availability | family must be in the declared font list |
| Type size | 6 pt minimum |
| Safe area | text no closer than 4 mm to the trim |
| Artwork past the trim | flagged while bleed is 0 |
| Merge fields | unfilled {{...}} placeholders |
| Contrast | 4.5:1, measured on solid backdrops only |
| Colour gamut | saturation above what four inks hold |
| Flat black | 100% K across more than 3% of the page |
| Hairlines | 0.25 pt minimum |
| Transparency | opacity, shadows, blurs, filters |
| Excluded elements | hidden, or set not to export |
Results carry five statuses: pass, warn, fail, note, and unknown. The last two stay separate on purpose. A note is something the check determined, such as this file using transparency. An unknown is something it could not determine. Merge them and the report starts inventing gaps, or hiding them.
The rules are yours
Web-to-print platforms that check designs ship their own rule set, their own thresholds, and their own wording. That is the trade you make when you adopt a platform. Here the checks are about 600 lines in your repository:
- Rules per SKU. The thresholds are one object. Load it from your catalogue and the same engine enforces the right spec for whatever is being ordered.
- Your assets. The print-master lookup reads custom metadata on the element, so it resolves against your own DAM.
- Your fonts. The SDK ships five Google fonts by default. Declare your own list and a missing font becomes a real finding.
- Your placement. The panel is React beside the editor, so it can be a rail, a drawer, a checkout step, or a gate on the order button.
- Your server. The checks read plain design JSON, so the same thresholds can run server-side against a saved design with your asset metadata in place of the browser image lookups.
What it does not do
Browser-side design checks do not replace a preflight engine, and the gaps are specific:
| Not covered | Where it belongs |
|---|---|
| Total ink coverage (TAC) | a preflight engine with an ICC colour engine |
| Colorimetric gamut through an output profile | same. The check here is a saturation heuristic |
| PDF/X-1a and X-4 conformance | Acrobat Preflight, callas pdfToolbox, veraPDF |
| Trapping and imposition | Esko, Prinergy, and equivalents |
| Separation control, overprint simulation | PitStop and pdfToolbox action lists |
| Barcode and dieline verification | your production workflow |
PitStop and pdfToolbox are mature products doing work this does not attempt. They run on a finished file, which is where certification belongs. Asking a customer to fix a headline at that stage is already too late.
