Copy files to the server, open fonts, preflight, open source files and edit, make postscript, make pdf, preflight again, color optimize, impose, send to press, this is what is in our mind when we start to create automated workflows. We visualize the entire job folder going through the system hitting each checkpoint and moving along. This can be done but there is a large amount of processing and network time involved in moving entire folders of files, images, XML and fonts around on a network server. We have to think a little differently.
The job folder does not have to travel any further than necessary. The best way is to use XML to call the shots while the rest of the job sits quietly on the server where it belongs. A jobs flow does not have to be a linear process; with today’s automation tools, we can have our XML file copy itself to several different processes at once and work simultaneously for some processes and wait for some of the others to finish if needed. The XML file that we require with our job folders includes most everything needed to produce our product. Its name probably is our job’s docket number and inside we have customer information, job docket information, email information and other data your automation system can use to sort with and decide which flows to follow and report with.
Here is an Example:
A job comes in from the Web portal and is downloaded by the automation system to its server location. On the way, copies of the XML hop into the production flows to start the processing. One makes its way to a flow that adds the information to the production database. From there an email is generated notifiying sender and production coordinator of the jobs receipt. Our second copy of the XML makes its way to a flow based on the information about the type of files in the job. This XML file picks up a Quark file and runs it through the Markzware Flightcheck Professional plugin. The report and the updated Quark file is then copied to the server and a passing file can follow its production flow to postscript/pdf production. The home base job folder on the server can always be found as the original data is added to anything picked up by the XML. A third copy of the XML can be used to generate packing slips and print out docket info or any paperwork for the bindery. This method of processing smaller XML files automatically is much easier on the network and server load.
XML can do the heavy lifting if the entire package or job folder needs to be processed. The XML file can pick the entire folder up when it is needed. This avoids the folder traveling through the entire process for no other reason.
A Word on PlugIns:
The Markzware Flightcheck Professional plugin was mentioned in the above example. Enfocus FullSWITCH and PowerSWITCH install by default many built in plugins that do not require any extra installation to use. If you have the software license and are running server programs, such as Enfocus Pitstop Server, Axaio MadeToPrint (QuarkXpress or Indesign and Indesign Server), Quite Hot Imposing, Alwan CMYK Optimizer, Ultimate Impostrip on Demand, EFI XF, Stuffit Deluxe, ICS Remote Director, Jaws PDF Creator, Elpical Claro, callas pdfToolbox, to name only a few, the plugin can be used as long as the software is installed on the server with the automation software. Whatever setups you have created in these products will be picked up and used by the plugin in SWITCH. It is that easy.
Since these products were mainly used with hot folders previously, the plus side to adding them to the automated flows is that files can be sent on their way to another process automatically after completion. If the XML method above is used to pick up items, all the data is available for use in any other process.
You can find more information about plugins for SWITCH at www.crossroads-world.com. There are examples for download, demos and contacts for developers available. You can learn more about XML from www.w3schools.com.