A preview is not a production file
A customer can approve an attractive on-screen proof while the exported file lacks bleed, carries the wrong colour values or omits fonts the RIP needs. The order then reaches prepress as a repair task. The engineering problem is to define the production artefact separately from the browser preview and to make that distinction visible in the order record.
The first input is the client's actual output requirement. We ask for files prepress accepts, files it rejects and the reasons. We also ask what the current workflow expects from a job ticket, hot folder or submission endpoint. A PDF file extension is not a sufficient specification. The box geometry, colour intent, image resolution, font treatment and naming conventions all have to be agreed.
Specify geometry and colour
Page size, trim, bleed and any slug area must correspond to the physical product. A customer may design at one scale while production needs another. The pipeline must preserve the distinction between the visible trim and the material printed beyond it, and it must reject a layout that cannot provide the required bleed. An editor cannot solve that by merely drawing a red guide line.
The output contract also names the colour model and profiles the workflow expects. Some jobs contain process colour, others have named spot colours; an automatic conversion can change the intended result. Overprint and transparency behaviour must be defined for the receiving RIP. The system should record the profile and output settings used for each generated artefact so a rejected job can be reproduced and diagnosed.
Where a named PDF or colour standard appears in the specification, it describes the file the engagement is designed to produce, not a credential held by this agency. Where a technical standard is named, it describes the output specification an engagement produces to, not a credential Web2Print Solutions holds.
Preflight as a decision
Preflight should produce a deterministic result that an operator and the ordering system can both understand. A rule may reject missing fonts, insufficient image resolution at the final size, a colour mode outside the agreed policy or absent geometry boxes. Another may warn without blocking. The distinction is a business decision and should be named in the rule set.
The result needs a specific reason, the affected page or object where possible, and a route to correction. A generic "file invalid" message sends the customer back into guesswork. A silent pass is worse if prepress later discovers the defect. We design the failure state before automating the successful route.
Proofs and production files have different purposes. A proof may be watermarked or optimised for display and should be labelled accordingly. The final production artefact must be archived by the order or job identifier. If a customer approves a proof and the pipeline regenerates the output later, the system needs a way to show exactly what version was approved and what was sent to production.
Handoff and acceptance
The scope can include PDF generation, imposition where it belongs upstream of the RIP, preflight rules, machine-readable findings, proof generation and handoff to the existing production workflow. It also includes routing for failures: a rejected file must be visible and actionable, not an order that disappears between systems.
Acceptance belongs with the client's prepress team. It should test specimens generated from representative orders, including difficult artwork and products with unusual geometry. The team compares the output to its written requirement and confirms that the receiving workflow accepts it. A document review or a browser screenshot cannot substitute for that check.
Each specimen should be tied to its source artwork, product rule version and job identifier. That trace lets prepress explain a rejection and confirm that a corrected file, rather than an earlier proof, entered production.
We do not procure or calibrate presses, profile devices as a standalone service, install an unrelated RIP, or promise identical colour appearance on every device and substrate. Those tasks have their own specialists and physical variables. The agreement should state exactly which output controls this pipeline owns.
Keep the rule set maintainable
An output pipeline will meet new products, materials and receiving equipment. The written specification should separate a general file requirement from a product-specific rule. For example, the need for a trim box is general; the bleed amount may vary by product and process. Keeping those decisions explicit lets prepress review a rule change without reverse-engineering a converter.
The system should also retain enough information to reproduce a production artefact. The selected product configuration, artwork version, profile, output settings and pipeline version belong with the job record. If a later file differs, operators can compare inputs rather than guessing whether the customer, editor or generator changed it.
An automated pass should not be interpreted as a promise of visual perfection. Some defects require human judgement, especially where source artwork quality or intended colour is ambiguous. The workflow can route those cases to prepress with a specific question. Automation is valuable when it makes repeatable decisions repeatable and leaves exceptional decisions visible.
Evidence and next step
Web2Print Solutions is a new property. Where we have not yet published a delivered example of a capability, the page says so rather than implying a record.
The services directory covers related engineering scopes, and how we work explains written acceptance. Start a project brief with one accepted file, one rejected file and the prepress reason for rejection, provided you can share them lawfully.