Artwork rejections and manual prepress rework
Manual prepress work piles up when a web-to-print channel accepts artwork without a preflight decision at upload. Every faulty file then surfaces after the order as a rejection, an email and a repair by hand. Netbase JSC builds that intake layer on W2P Solution: rules from the printer's file specification, safe fixes, and a reason the customer sees.
Start a project briefReviewed by CEO, Netbase JSC · Published 29 Sep 2026 · Updated 6 Nov 2026
Why is prepress still fixing web-to-print files by hand?
Prepress fixes files by hand when the web channel treats artwork as an attachment rather than as production input. The customer uploads a file, pays, and leaves. Hours later an operator opens it and finds RGB images, no bleed, a missing font or a 72 dpi logo. From that moment the order is stuck: the operator either repairs the file, which carries a quality risk, or writes to the customer and waits. Both paths cost prepress time, and the second adds days to delivery.
| Area | What you see today | What an intake decision does |
|---|---|---|
| Upload | Any file is accepted and the order is paid | The file is checked against the product's rules before checkout |
| Faults | Found in prepress, often after scheduling | Found at upload, with a reason the customer can act on |
| Repair | An operator fixes or emails, order by order | Safe fixes are automatic; unsafe ones are refused with guidance |
| Record | Emails and file names like final-v3 | One approved file version linked to the job |
A high rejection rate and a prepress team that spends its day on repairs come from the same mechanism, so this page treats them together. Other failing boundaries are listed under web-to-print platform limitations.
Key takeaways
- Checks that run after a paid order force a choice between repairing the file, which risks quality, and emailing the customer, which adds days.
- A per-product file specification, written as data rather than a help page, lets the storefront, the upload check and prepress read the same rules.
- Tiered rules keep checkout open: faults with a known correction are fixed and shown for approval, and only faults that would print wrongly are refused.
- A design editor that exports RGB without a colour intent is a systematic source of these faults, covered in the editor-exports-RGB page.
How does the rework loop form?
-
The product has no file contract
The storefront knows the size and stock but not the file rules that follow from them: trim size, bleed, safe area, colour space, minimum resolution, fonts.
-
Checks run too late
Preflight, if it exists, runs in the prepress workflow after the order is placed, so rejecting the file means stopping a paid order.
-
Warnings are not decisions
A preflight report lists twenty warnings. Nobody has decided which ones block the job, which can be fixed automatically and which can be ignored for this product, so an operator decides each time.
-
The customer is outside the loop
A rejection travels by email, the corrected file arrives as an attachment, and someone matches it to the right order by hand.
-
The editor itself may create the fault
Your design editor exports RGB, not CMYK explains that case.
What the checks are, from TrimBox to image resolution, is covered in what makes a PDF print-ready. This page is about where the decision sits and who acts on it.
What changes the outcome?
-
A file specification per product
Input: the printer's current file requirements and the product catalogue. Action: write each product's trim, bleed, colour and resolution rules as data. Output: one specification that the storefront, the upload check and prepress all read. A photobook adds rules of its own, including spine width and a separate cover file.
-
Preflight at upload
Input: the uploaded file and the product's specification. Action: run deterministic checks before the order is placed and classify each result as pass, fix or refuse. Output: an accepted file, a corrected file shown for approval, or a refusal with a reason the customer understands.
-
Safe automatic fixes
Input: faults with a known correction, such as a TrimBox that can be set from the product size. Action: apply the fix and show the customer a proof. Output: fewer refusals without silent changes to artwork.
-
A rework queue with a single file record
Input: files that need a human. Action: route them to a named operator with the report attached and collect the corrected file against the same order. Output: one approved file version per job, visible to production.
Netbase JSC engineers print output: PDF generation to a client-specified standard, CMYK and spot colour handling, ICC profile selection, bleed and trim geometry, imposition and automated preflight. Where a technical standard is named, it describes the output specification an engagement produces to, not a credential Netbase JSC holds. The service that scopes this work is print-ready PDF generation.
(opens the full-size diagram in a new tab)
How does W2P Solution by Netbase JSC handle artwork rejections?
W2P Solution by Netbase JSC is a web-to-print platform for mid-market and enterprise print businesses, built on Laravel and its own print API, with AI and API automation for print workflows. Three layers are kept apart here.
-
In the product
For every paid order the store obtains a print-ready PDF for each order line, keeps its own copy with a checksum and trim and bleed boxes, and places the order in a production queue. The first release supports flat print products such as cards, flyers and posters.
-
In the print API
Netbase JSC's print API includes AI artwork jobs that a person approves or rejects, and W2P Solution stores run on it. The pass, fix or refuse decision stays with rules and people.
-
Engineered by Netbase JSC
Per-product file rules and the upload check are not part of the standard store. Netbase JSC can build them as an extension kept separate from the product core and tested per store before each upgrade. That is a declared capability, not a shipped feature.
Which systems are involved?
The storefront and its upload route or online designer, a preflight engine that reads PDF and image files, the prepress workflow with its hot folders or JDF job tickets, and the print MIS that holds the job. The accepted file reference should travel with the order into the job, as described in print orders retyped into the production system.
How does this differ by segment?
Commercial and trade printers concentrate rework in a few high-volume products and speak in preflight profiles, TrimBox, total area coverage and imposition. Wide-format and signage printers see resolution and scale faults most, because a file at the wrong scale looks correct on screen. Media and publishing teams fail through templates and revisions, so the fix is a locked template and a check on each revision. Enterprise buyers need the refusal reason to reach the person who can fix it, often a brand coordinator rather than the orderer.
How do the options compare for artwork intake?
| Question | Packaged web-to-print SaaS or plugin | W2P Solution by Netbase JSC | Agency custom build |
|---|---|---|---|
| Where is the file decided | Depends on the product; check whether uploads are tested before payment | A print-ready PDF for each order line; upload rules are a Netbase JSC extension | In code the agency writes to your specification |
| Who writes per-product rules | You, in the vendor's screens | Netbase JSC, as a tested extension on your store | The agency; you inherit the code |
| Who decides on a flagged file | Depends on the vendor | A person approves or rejects AI artwork jobs | As specified in the build |
| Leaving | Export depends on the vendor | Full store data export, including print files | You hold the code |
What evidence stands behind this page?
Netbase JSC has delivered 50+ web-to-print platforms; as of 12 October 2026 its project records list 500+ custom web-to-print projects, for clients in 80+ countries as of 13 October 2026. The preflight rule set specimen publishes the checks and thresholds, each resolving to pass, warn or fail, as a specification rather than a client story. Live web-to-print stores are operated by their owners and use designer or print-option components Netbase JSC delivered. Delivery records cited on this site belong to Netbase JSC; where no delivered example of a capability is published, the page says so. No rejection-rate result is published, so the intake rules are tested on your own recent rejected files, as the delivery method sets out.
Check whether this boundary applies to your setup
Send a project brief with your file specification, ten recently rejected or repaired files, and the repair your team made to each one.
Frequently asked questions
It can, if every warning blocks checkout. The rules are therefore tiered: safely correctable faults are fixed and shown for approval, and only faults that would print wrongly are refused, with a plain reason and a way to upload again.
No. A missing TrimBox or an RGB image can often be corrected. Low-resolution photos, missing content near the trim and wrong page sizes usually need the customer, so the check explains what to change.
Count repaired and refused files per product before and after launch, over the same product set and period. The count comes from the rework queue, so it needs no manual log.
Yes. Web2Print Solutions delivers remote-first from Hanoi, Vietnam, and Netbase JSC has delivered web-to-print projects for clients in 80+ countries.
Send a project brief at /project-brief, email project@netbasejsc.com or message us on WhatsApp at +84 937 869 689. A senior engineer reads every brief and replies in writing.
References (3)
- Ghent Workgroup, PDF/X workflow: the GWG 2015 specification is based on the ISO PDF/X-4 standard, accessed 2026-09-30.
- Ghent Workgroup, GWG specifications for PDF preflight settings, accessed 2026-09-29.
- CIP4 Organization, What is (X)JDF: job ticket and messaging formats used between systems, accessed 2026-09-29.
