The ICS - Important Supplements to Job Ticket Specifications

In general, languages are complex systems of communication. For example, your dialog partner may not understand some of your words at all or may interpret them differently - even if you use only words from the official vocabulary according to the correct grammar. This is true not only for a language between human beings, but also for computer languages and even data formats such as JDF. RIPs might render a PDF file differently. Analogous applies to JDF

The ICS papers ensure the interoperability of (X)JDF and PrintTalk devices and controllers.

An ICS - What a device or controller needs to understand from a job ticket specification

No single device (i.e., printer, press, imagesetter, etc.) is likely to implement all that the job ticket format specification provides for. For example, if you are in the digital printing business, you might not care to facilitate data used for case-binding. In the same type of example, a RIP is not a requirement for facilitating preflighting. A Stitcher likely doesn't need (nor have the ability) to handle image rendering data. To specify exactly what individual classes of devices need to do with JDF or XJDF or PrintTalk, CIP4 members have developed ICS documents that provide the basic requirements for individual classes of devices. Thus, ICS documents decrease the risks of incompatibilities between modules. Note that CIP4 ICS documents are specifications for software engineers to read, they are not machine-readable interfaces. These documents provide valuable recommendations for developers and integrators, guiding them to what portion of JDF, XJDF or PrintTalk they should implement in order to achieve interoperability to other modules or solutions.

Two JDF systems may not understand each other, even if they both comply with the JDF specifications. The reason for this is that the developers of a system do not implement the entire JDF functionality, but consciously or unconsciously expect certain prerequisites. A JDF reading device may simply ignore certain parts of the JDF information provided. For example, it is conceivable that a folding machine reads the resource FoldingParams properly, but then only interprets the information about the FoldCatalog, not the individual folding operations. After all, both attributes are marked as optional in the JDF specification.

The Interoperability Conformance Specification (ICS) is intended to remedy this situation. These papers describe which parts of the specification should be observed for certain production sectors. There are different papers for different sectors and interfaces. For example, there is an ICS paper for MIS-to-Prepress, another one for MIS-to-Finishing, and so on.

The ICS documents also define names and usage of Gray Boxes. What is a Gray Box though? An MIS normally cannot describe details of the production, only a rough framework. It defined place holders, which are called Gray Boxes. The information contained in a Gray Box does not suffice to execute the processes that the Gray Box holds, which is why a Gray Box is called non-executable. The missing data must be added as the production progresses. The ICS papers define, which Gray Boxes might be written into a JDF document and which device needs to read it.

Many ICS papers do not describe a single conformance specification but rather up to three. They are called levels, where Level 3 includes Level 2, and analogously Level 2 includes Level 1. These three levels represent different compatibility requirements. In simple terms, the levels identify low, medium, and higher compatibility requirements.

There are several ICS documents for different interfaces. In addition, there are sometimes several versions of an ICS document. Here only the current version is shown for download. If you are interested in older versions, please follow this link.
There are ICS documents specified for JDF and others specified for XJDF.

To specify exactly what individual classes of devices need to do with (X)JDF and PrinTalk, CIP4 members are developing ICS document that will provide the minimum expectations for individual classes of devices.