spacer.png, 0 kB
 
SwedishNorwegianEnglishGerman
spacer.png, 0 kB

Print Article 2 of 7


JDF under the Magnifying Glass

The JDF file is generally unnoticeable for the user as it works “under the hood”, so to say, as a means of transport for different types of information between the different participants in the workflow. Simply put, the file is a digital work order that has the task of replacing the traditional work order.

The information in the JDF file can be divided into two basic categories, Product Intent and Process Intent. Both of these can be part of the same JDF file. Product Intent is the part that is of interest to the customer, that is to say, what type of product is being made, number of pages, final format, type of ink and paper being used, etc. This information can be preserved unchanged as information about how the job will be accomplished is saved as Process Intent.

JDF Nodes
Every step of the production corresponds to a node in the JDF file. Together, the nodes form an upside-down tree that describes the desired printed matter and the production’s work process. The deeper one goes into the tree, the more detailed the description is of what will be done. The node at the top describes the entire product and the nodes that appear further down describe the more detailed processes, for example, how the different parts of the book will be printed or worked with. Observe that the same type of node is used regardless if one is describing a product or a process.

Click here to see a picture of the JDF tree.

The picture illustrates the JDF tree with each box representing a node. It becomes more detailed the further down one comes.
The result of a node is usually IN data for the next node and after a node has been executed, the result is saved in the JDF file. This makes it possible to trace every individual event and see whom or which machine has performed each process. To sum up, one can say that a node is an instruction to perform a certain task in a certain situation.

Each node is made up of several elements (components), which in turn have different attributes with their job being to describe the elements. Moreover, the elements can contain different sub elements.

Below are several examples of elements that can be found in the nodes:

  • NodeInfo
    The element NodeInfo contains information about scheduling, for example, deadlines and time estimates. The element can also contain administrative data that describes, for example, which press will be used. Additionally, NodeInfo contains information about the route of the status messages, that is to say, where JMF messages and JDF files will be sent after execution. The information in this node usually comes from the management system.
  • AuditPool
    This element saves information about the course of events. Among other things, it can save information about time consumption, resources consumption, and details of an event. For example, it can save the information that a task was performed with a 430, 120 g sheet instead of the planned 400, 130 g sheet as 30 of the sheet was destroyed and 130 g sheets were unavailable. The element also saves information about paper that has become caught in the machine. This element functions as a logbook and receives information as the work proceeds.
  • CustomerInfo
    The element CustomerInfo contains detailed information about the customer and the customer’s contact person as well as all given addresses.
  • ResourcePool
    Resources are materials or parameters needed by or created by a node. Examples of resources are paper, ink, digital materials like PDF, machine parameters, and so on. A node cannot begin its work before all incoming resources are available, which is rather obvious as it is quite difficult to begin printing without paper or ink, for example.
  • ResourceLinkPool
    To avoid needing to define the same resource more than once, one utilizes links to retrieve information about a particular resource. The links can retrieve data from within a single node or from overlying nodes. The reason for this, among others, is that two sub-nodes, for example, could use the same resource and one then avoids needing to define that resource two times.

There is much more to discover about JDF and its structure. If you are interested in learning more about the subject, please visit www.CIP4.org.

   
spacer.png, 0 kB
spacer.png, 0 kB
spacer.png, 0 kB