Job Definition Format

Before describing the implementation of proofing in JDF, it's better to know a little about the terminology that will be used.

1. Proofing: the process of producing a printed output on a device (proofer) that emulates the best it can the supposed printed output on press (the final production device that can be a conventional press, a digital press…) where the final printed product will be produced. Prepress proofing (or off-press proofing) provide a visual copy without creating a press proof (the process is cheaper).
2. Soft proofing: the same as proofing, but the proofer is actually a screen.
3. Approval: the process of approving or rejecting the proofing (or the soft proofing). Comments and annotations may be added to describe the reasons of the decision and to give instructions on what changes to do.

The original input files have to be processed to be printed on the final press (interpreting, rendering, screening, color management....) and the same to be printed on the proofer (different characteristics). The decision on which of the processing steps will be executed once (common both for printing on the proofer and on the press) and which not will depend on many parameters (characteristics of the proofer device, user requirements, workflow requirements…). The proofing has to take in account the consistency between the press and the proofer.

In JDF 1.1, proofing and soft proofing were defined as an atomic process on which the input were all the parameters required for a successful process. This has some drawbacks:

1. Lack of flexibility: the semantics is specific for one workflow therefore limited to the definition of the processes and the resources that it can take as input.
2. Lack of control: it is difficult to define the input resources with all the information required for control.
3. Duplication: similar information has to be used to define both proofing and printing. If different resources are used, this will result in duplication.

From JDF 1.2 proofing and soft proofing were deprecated in behalf of a combined process to specify the proofing workflow. The job ticket explicitly defines the processing and provides the flexibility to implement them in different workflows. In order to do that, the atomic processes were made capable of keeping all the information necessary to specify different configurations/options.

It is impossible to describe proofing by a unique combination of processes which in turn will depend on the capabilities of the RIPs (Raster image processor), the devices used for proofing and the proofing production workflow. It is still possible to define a generic combined process for the proofing. This will allow it to describe its step in a workflow. The generic combined proofing process combines the following JDF processes:

• ColorSpaceConversion (1): converts the contents of the input RunList from the input color spaces to the color model of the press.
• Interpreting: interprets the input RunList file(s) and converts them to an internal display list in order to go through the Rendering.
• Rendering: renders the raster data.
• Screening: screens the raster data.
• ColorSpaceConversion (2): converts the data from the press color model to the proofer device color model.
• Imposition: if imposition proofing is done, combines the pages and marks on the imposed sheets.
• ImageSetting: specifies the actual printing of the proof. Depending on the characteristics of the proofing device DigitalPrinting can be used as well.

The ordering is not completely strict (same result may be achieved with different order combination of steps), but there are some precedence rules: the first color space conversion must be done before the second one, rendering must be done after interpreting, screening in turn must be done after rendering and the second color conversion, ImageSetting/DigitalPrinting must be done after screening.

Compared to proofing, since no printed proof is produced, no ImageSetting/DigitalProofing processes are required. Moreover, the rendered data is sent directly to the Approval process that must implement a user interface to show those data on the display and allow him/her to approve/reject the proof and eventually annotate it using digital signature. All the ordering consideration are still valid.

In a production workflow with proofing, there must be both the conversion of the input asset color spaces to the press color space and the one of press color space to the proofer color space. So in JDF two different ColorSpaceConversion processes are required and depending on the exact workflow and on the capabilities of the devices, they can be included in the same combined process.

Input data to the proofing combined process usually required both interpreting (with the exception of JDF ByteMap) and rendering. In these cases they will be included in the combined process describing the proofing step.

Two possibilities:

• Proofer can emulate the screening of the press: Screening should be performed once at the ripping combined process and the halftoned data should be sent directly to the proofing combined process.
• Proofer is a "contone proofer": one Screening process for the press and one for the proofer.

For printing the proof ImageSetting/DigitalPrinting process has to be specified at the end of the proofing combined process in order to define how the proof is actually printed.

Must be executed before the final production printing can be started.

HP incorporates JDF into its proofing products. Even if it's only one step in the total process JDF cuts time from the printing process making printers more efficient because proofing traditional generation and delivery of proofs can take days.

HP sends PDF files to a remote proofing. JDF file enables the inclusion of job information (color profiles, job ticket details...) that is sent to the client. In the future marking up the proof and digital signatures for approval will be implemented.