Jun 6, 2006
The Broadhurst Report
When is a PDL not a PDL?
By Guy Broadhurst
Do you know how often I hear the term PDL? Let me put it this way: it's like the old saying, "if I had a dime for every time I (fill in the blank)…" Well, it's something like that! I'm not sure how many page description languages are out there these days. Some go back a couple of decades, while others are much more recent. They are an astonishing collection of two-, three-, and four-letter acronyms. The common ones we think of daily, AFP, IJPDS, Metacode, IPDS, LCDS, PCL (in various flavors), PS (PostScript), and PDF are just the beginning.
PDLs are common discussion topics with customers because they are a key element of document production. Not only are there are a lot of them, most are proprietary to one degree or another. This failing stems from the delusion some companies had (and some still have) that having a unique PDL was a way of preventing customers from looking elsewhere for their print engines. Of course, this strategy failed as document producers began buying equipment from multiple vendors and took on the challenge of managing multiple PDLs. The resulting mixed production environments are now the norm.
Questions
Still, the number of PDLs, especially when legacy applications are involved, is a leading concern among transactional and direct mail printers. Customers routinely ask if we can "run" their PDLs, especially some of the newer, semi-proprietary ones being devised that still need conversion to one that print engines will accept. This ultimately comes down to a workflow issue: Can our RIPs and print engines consume the PDL du jour and produce jobs correctly and on schedule?
Next, customers worry about the many applications they run, especially since these likely involve multiple PDLs. The first question is how much additional training is required to manage a system that can consistently and accurately handle multiple applications without requiring operator training for each app? In addition, if a company that does all their own transactional printing adds graphic arts applications such as marketing materials or books and manuals, how do those PDLs impact the equipment they use and how he jobs are processed? Hmm, sounds like workflow again.
The first part of Océ's response to these concerns is that we are distinct among all major print engine vendors in that we have never developed our own PDL. This has enabled us to develop equipment and software that integrates smoothly into mixed environments and can accommodate virtually any PDL and handle the broadest range of applications. Even in the case of firms adding graphic arts applications, these are really just more jobs. Load the correct paper, set up the pre- and post-processing and start to print. The PDL is not the issue.
So When is a PDL not a PDL?
When it is part of a workflow. Which is just about all the time. Any number of shops will say they have an AFP workflow, a PDF workflow or something to that effect. Here again, PDL independence, when combined with Océ PRISMA workflow software, enables virtually all PDLs, file formats, and data streams to run on machines from Océ and other manufacturers. And when jobs can be run on whichever device is available the choice of PDL far less of an issue. This is the flexibility of an open software architecture. Not just an "open standard" (which means everyone must bow to the standard) but software that is designed from the ground up to "play well with others" and provide the building blocks to create customized solutions that are proven to work as expected.
The PDL game is changing, however. Corporate and transactional customers are continuing the shift to PostScript and PDF (where graphic arts already is) for a widening range of document types--even statements. This should ultimately simplify the number of PDLs used and reduce the challenges of managing them. But until that time comes, the best way to manage multiple PDLs is to adopt equipment and an overall workflow architecture that are truly PDL-agnostic.