Digital Press to Binder..."Hello, Are You There? Hello?"
As digital print engines got bigger and faster, efficient workflows became essential to effectively managing the volume of images that could be generated. And the digital print vendors responded by developing highly sophisticated color management, image imposition, and variable data composition software. In fact, software is a large part of a digital print engine purchase, and a profitable one for the vendors.
But when it comes to the finishing end of digital print, there is still a lack of "connectivity." The offset world saw the introduction of JDF (Job Definition Format) more than 15 years ago. JDF was developed by an industry and academic consortium. The plan was to introduce software that could define every aspect of printing and finishing, from prepress to bindery. The job specs could then be passed between departments and machines electronically.
JDF was a mixed success. It wasn't easy to get all of those various devices to understand the new language, and implementing it across an entire printing firm was an expensive proposition. But it did work, and brought considerable efficiency and accuracy benefits to those who did. Loading a format file into an enabled machine meant the makeready could be done on automatic pilot in a few minutes.
Enter digital print. Each vendors' print engine ran on a different software workflow. There was no JDF equivalent of a universal digital print-to-finish "language." An attempt was made via UP3i, a proposed printer-to-finishing specification which would have allowed the digital print engine to communicate with the cutter - stacker - perforator, and the saddlestitcher, or binder which was further downstream. So what happened to UP3i? Well, it sort of died on the vine due to a lack of adoption across the digital print and postpress vendor community.
Finishing integration with cut-sheet printers has been around for a long time. And it's not all that complicated. Booklet makers and small binders can "bolt on" to the end of a cut-sheet printer, and the paper path goes straight from the printer to the finishing device. Typically, the printer menu includes the settings for the finisher. Firms such as C.P. Bourg, Duplo, and Standard Horizon have supplied finishing modules for cut-sheet printers for many years.
With high-speed continuous printers, it gets a lot more complex. First you have to cut the web to the desired sheet length. Then the sheet (or folded sheet) gets passed to the binder or stitcher at very high input speeds.
Right now, this communication between printer and postpress is handled via printed codes. A variety of instruction codes are printed on the web (barcode, OMR marks, QR codes) and then read by the cutter - sheeter - stacker and the stitcher or binder running behind these. The printer can perform certain functions for postpress, such as providing blank paper to "clear out" the downstream devices after a fault, or job end. But if there is a problem further on down the line, the finishing system doesn't really talk directly to the printer as to which book, in which job, has an issue. Nor does it create a reprint file automatically.
It would be nice if that sort of back-and-forth communication were on the horizon, but it won't happen until a common language for doing this is adopted by the printer community.