Since JDF is the Job Definition Format, it makes sense to look in more detail at what a job actually is.
JDF & administrative data
The basic set of data that any JDF enabled system deals with are the core administrative data about a job. These include:
- the job ID number
- the job name
- delivery date
- customer data
- the name of the customer for which the job is produced
- their address
- contact details,…
Content
A JDF file can describe how many pages are part of the job and what their finished trim size is.
Using JDF, a system can also tell another system where to find these pages. There are two mechanisms for this:
- The JDF can include a path description, telling a system to look for the pages at \\servername\shared folder\filename. Such a list of pages is called a populated runlist in JDF parlance.
- A JDF file and matching PDF pages can be bundled in one single MIME-file.
JDF job parts
A single page leaflet is a straightforward product. Other products are more complex and may consist of different parts that are each produced using a different process. For a book the cover and content can be two different parts. For a magazine inserts or a special section printed using another type of paper can be a different parts.
The JDF specifications include a job parts mechanism. Applications may use job parts because
- parts of a job use different production techniques, media or process settings (such as screening)
- the job requires versioning: it is printed in different languages or there are multiple editions (e.g. per region)
- they want to adapt the job structure to the process that they are controlling. A simple example of this are press operators who do not really look at a job as a whole but who see each individual press sheet as a job. In a JDF sent to a press management system, each press sheet can be defined as a job part whereas a JDF about the same job which is sent to a prepress system only contains a single job part.
The above reasons are valid arguments for using job parts but different JDF-enabled applications may use JDF parts in a different fashion or may not even support them at all. Since job parts add complexity to JDF, some vendors do not support the mechanism. Depending on the type of job, operators or users may also like or dislike the use of job parts. For example: suppose a designer created a single 80 MB PDF file for a 300 page catalog. If an MIS system defines that job using 3 job parts, a web portal may show 3 separate job entries in which the designer needs to upload the pages. He can either split the PDF to match the job parts or he will be forced to upload the full document 3 times, instructing the portal to each time only make use of certain pages.