This article provides a comprehensive overview of the Job Definition Format (JDF) and its integration with GelatoConnect, focusing on how to automate workflows effectively. It covers key concepts, steps for JDF generation, validation, file transfer, and the differences in automation between various printing technologies.
Understanding JDF and ISV Integration
To effectively automate your workflow, it's crucial to understand how JDF (Job Definition Format) files are used to send jobs from GelatoConnect to your internal systems and presses. This involves configuring your Internet Input Method and mapping to a ticket template.
Key Concepts
Input Method: Ensure your DFE (Digital Front End) has the internet input methods set up, pointing to your desired ticket template.
Ticket Templates: Enable the DFE to understand the job's specifications and provide a base for job settings.
JDF: Allows you to override specifications of the ticket template and allows you to point to your artwork that should be processed.
Substrate Names: Gelato’s substrate naming may not match your press substrate library. Through a JavaScript activity in Workflow Builder and the JDF, you can map the GelatoConnect substrate name to the substrate on the press.
Building JDF inside the workflowStep 1: JDF Generation
Prerequisite: The product which needs to be printed should already be configured using WF builder.
Open the workflow for the configured product and add an activity (JS Script) after the activity where the PDF plate is being sent to SFTP. This JS script activity will have any custom configuration that is needed by you, for example, the device ID name, the structure of JDF file name, and any other internal mappings with their systems.
Then add an activity “Create Configuration File” and select type as “xml” and template as “JDF Basic Template”. The file extension by default will be “.jdf”.
Update the JDF schema thus created to have values from the context.
Step 2: JDF Validation
Validate that the JDF file is well formatted.
There are cases where certain values, like product substrate, press name, file name, etc., are configured differently from what we have in GelatoConnect. This means we need a JS (JavaScript) activity or a mapper activity before the JDF step so that we can normalize the values before sending them in the JDF (xml).
JDF file should have the right reference to related assets (actual PDF or images if required) and should be accessible from your facility.
Step 3: File transfer
For the first iteration, we just send the JDF file to the SFTP server and let you read it from there and send it to their respective press. Add activity for SFTP and update the file name as required and also the link to the file which needs to be used by the PSPs.
We should be able to send the associated assets like PDF, images for the job to you via existing SFTP.
DFE should be able to read the JDF file and also access the related assets (PDF, images, etc.).
Workflow for Automated File Transfer (FTP to Hot Folders)
The process of moving files from FTP to specific press hot folders involves a series of modules and scripts that work together to process JDF and PDF files.
Imposition and FTP Transfer: After your imposition is complete, the job is sent to an FTP server.
JavaScript Activity in Workflow Builder: A JavaScript activity inside Workflow Builder is used to build variables, such as:
Descriptive Name: What the descriptive name of the job should be on the press.
Paper Name Mapping: Pulling values from various sources to map the paper name to the specific substrate name on the press. For example, "100 pound text code" might be mapped to "silk on a B2 tool" with a "20 by 29 sheet" and then to a "master MPF, artist silk text" with an inventory number. This payload is then returned into the context, which includes the customer template.
JDF Configuration: The next step is to use these variables to populate a JDF configuration. This involves:
XML/JDF File Extension: Ensuring the file extension is JDF.
Populating Fields: Filling various fields in the JDF with the descriptive name, IDs, file name, and other saved information from the JavaScript module. This includes the device ID (what the DFE is going to), the
descriptive name, and the substrate name.
Push to FTP: The fully configured JDF file is then pushed to the FTP. This includes the JDF file itself and the plate ID.
Grabbing Files from FTP (Internal System): You need an automation tool, internal system, or script that can grab the JDF and PDF files from the FTP and move them to the correct locations. Examples:
Workflow Automation Tools (e.g., Enfocus Switch, n8n, Make dot com).
Custom Scripts: Custom scripts within these tools can be used for further manipulation of database elements as needed.
Device-Based Routing: Based on the device name (e.g., "18K-DFE" or "7800 DFE") contained within the JDF file name, the file is routed to that specific DFE’s JDF folder.
Global Asset Library: The Plate PDFs typically go into a global asset library that the DFE has access to. Then the JDF file, placed in the specific press JDF folder, tells the press where it needs to load the PDF from the asset library.
Alternative (Custom Scripts): You don't necessarily have to use automation tools. Custom scripts can be written to monitor folders and perform the same routing and file manipulation tasks.
Automating the RIP Process
The RIP (Raster Image Processor) process is typically managed by the DFE of the press. The JDF file, which includes all the necessary job information (imposition, substrate, quantities), is loaded into the press's DFE. The DFE then uses this information to RIP the production files before sending them for printing.
JDF as Instruction: The JDF file acts as a comprehensive instruction set for the press, eliminating the need for manual configuration at the press for each job.
DFE Responsibility: The DFE's role is to interpret the JDF and prepare the file for printing, including color management, screening, and imposition.
Differences Between Sheet-fed HP Indigo and Wide Format Automation
While the core principles of using JDF for automation remain similar, there can be differences in the specific configurations and modules used due to the distinct requirements of sheet-fed HP Indigo presses versus wide format presses.
Ticket Templates and Internet Input Method Mapping: The mapping of Internet Input Methods to ticket templates might differ based on the press manufacturer and model. Each press type might have specific parameters or proprietary settings that need to be accounted for in the JDF generation and interpretation.
Substrate Handling: While both require substrate mapping, the range and types of substrates for wide format are generally broader, potentially leading to more complex mapping logic in the JavaScript activity in Workflow Builder.
Imposition Layouts: Imposition templates will vary significantly between sheet-fed (e.g., gang-up for multiple small jobs on a single sheet) and wide format (e.g., nesting for irregular shapes on a roll). The JDF would carry these specific layout instructions.
DFE Capabilities: Different DFEs (e.g., for HP Indigo vs. a wide format printer) might have varying levels of JDF support or proprietary extensions that need to be considered when generating and processing the JDF files.
RIP Features: Wide format RIPs often include features like tiling, step-and-repeat for very large graphics, and specific color management profiles for different media types, which might be handled differently within the JDF instructions or the DFE itself compared to a sheet-fed press.
Video Reference