« XMPie Video | Chocolate Direct Mail »
On the Adobe stand at drupa you'll find plenty of information on Adobe PDF Print Engine 2. This new version of Adobe's PDF interpreter has significant implications for the future variable-data printing. But before I explain why, it's important to first understand what the heck Adobe's PDF Print Engine actually is and does.
Introduced at IPEX 2006, the Adobe PDF Print Engine is a PDF interpreter, but unlike most PostScript intepreters used in RIPs or digital printer controllers, PDF Print Engine has the capability to process PDF files natively—most PostScript Interpreters (e.g. Adobe CPSI) have to convert PDF files to PostScript before they can interpret the file. The problem with this approach is that conversion can introduce interpretation errors and not all PDF features are supported by PostScript interpreters.
Due to new features in creative software such as Illustrator and InDesign, artwork is becoming increasingly complex and graphically rich. Use of transparency effects, layers and 3D design means that it can now be quite challenging to reproduce artwork accurately.
PDF Print Engine shares several core technologies from Adobe Creative Suite products including Adobe Color Engine, CoolType (a font engine) and Adobe Graphics Manager. With support for these Adobe core technologies, combined with native transparency support, PDF Print Engine ensures efficient and reproducible output.
In this new version, Adobe has introduced support for digital printing and specifically, optimised the engine for jobs with VDP characteristics. Many major digital print and RIP vendors have already indicated that they are working on support for PDF Print Engine, including Kodak/Creo POD, Océ, EFI and Xerox. In fact, Kodak already includes Adobe PDF Print Engine in their NexPress print controllers and Xerox is showing a mock-up of FreeFlow Print Server with Adobe PDF Print Engine on their stand.
So how does Adobe PDF Print Engine have implications for VDP? Well, for a start it only consumes PDF. Yes that's right. Farewell PPML, VPS, VIPP, et al. Like Henry Ford said, "you can have any colour as long as it's black", well with PDF Print Engine, "you can have any VI language as long as it's PDF". So, is this the end of all the other VI languages? Well, maybe, but not for a while yet.
To date, only two digital print vendors currently offer Adobe PDF Print Engine; Kodak with their Nexpress controller and Fuji Xerox with their 490/980 press. Xerox won't be supporting PDF Print Engine until sometime in 2009 and I don't think we'll expect to see support from the other vendors before then. However, Xerox won't be dropping support for VIPP just yet. The FreeFlow Print Server version on Xerox's drupa stand used Adobe CPSI (Configurable PostScript Interpreter) and PDF Print Engine, although this integration was only a mock-up and isn't functional at this time.
But is PDF a viable file format for VDP? Yes, I believe it is, for a couple of reasons. Firstly it's easy to proof, you just need Adobe Reader. Secondly, through support of x-objects and the ability to separate assets (in PDF/X-5), it's comparable to VDP support in other VI languages. In fact, ISO Technical Committee 130 are currently working on a new standard for VDP in PDF; PDF/VT. This is will be an ISO standard for Variable and Transactional printing (hence the 'VT') next year.
But what about in-RIP composition? Well, that's a good question. As Adobe PDF Print Engine is entirely PDF based, it can't compose templates on a RIP like some PostScript-based VI languages can. PDF Print Engine requires a pre-RIP composition workflow; you need to create a print-ready PDF file first. But is this really a problem? I don't believe it is. If you asked me four years ago, then I'd have given you a different answer. However, most desktop VDP software today can create print-ready files very efficiently, typically at a rate of 500+ records per minute and significantly faster using server-based solutions.
While other VI languages will be around for quite some time yet, and some will never disappear, I believe that PDF adoption will replace use of other VI languages over the next five years and emerge as the de-facto page description language for variable-data printing. Mark my words.
Posted on Monday, 2 June 2008 at 4:43 PM | TrackBack: http://www.veedeepee.com/cgi-bin/mt-tb.cgi/145
Eliot, thanks for the article. I too was at drupa but was very tired by the afternoon of the day I sat and watched the Adobe Seminar that you write about. Thanks for your thoughts on the future of Adobe PDF Print Engine.
Is there any data available yet on RIP speeds compared to current PDLs?
Posted by Brian Gibson on Tuesday, 10 June 2008 at 8:50 AM
Hi Brian, I don't have extensive benchmarking results, but we've done some testing of our own. We created several VDP test files which varied in complexity. When comparing the interpreter speeds of PDF Print Engine + PDF, versus CPSI + Optimised PostScript, the PDF Print Engine was considerably faster across all test files, from 4x faster to 11x faster. We're very impressed and happy with the results we've seen so far. However, the PDF file obviously has to be optimised accordingly (i.e. re-using variable objects, etc).
Posted by Eliot Harper on Tuesday, 10 June 2008 at 10:42 AM
PDF would make sense for some VI, especially if processed natively although VIPP has some very unique features that PDF would find hard to emulate.
For PDF VI we're half way there already in some respects. Already if you print to Acrobat distiller (version 5 or later) doing a simple mail merge from MS Word, although the ps file generated is huge, Acrobat essentially caches the background pic and you get a tiny PDF file. All that work means nothing, since the rip ends up reprocessing every page. There are a couple vps drivers for MS word that help, but of course only works with Creo vps variable workflows.
Posted by Kevin on Wednesday, 25 June 2008 at 11:09 AM
With the increase in persoanlised imagery and the extensive need for professional colour management, I hope this new PDF engine will remove the CPSI issues currently in the existing digital RIPs (from all manufacturers).
It's fine for Adobe to create it, but the adoption from the vendors is still a requirement - so adoption will be related to pricing of implementation (something that has dogged most of the players in this space).
Posted by David Thomson on Friday, 1 August 2008 at 12:19 PM
Eliot,
Thank you for sharing this. It seems Adobe has settled on the name PDF/VT and now touts PE2 on their PE page: www.adobe.com/products/pdfprintengine/
I realize the desktop tool vendors (like XMPie) are somewhat agile, and will allow exporting to PDF/VT soon; however, VDP RIP vendors don't seem to update much. What's your thought on the adoption/implementation timeline within existing VDP RIP's, or whether it will be some time until we see it in entirely new versions.
Also, is there anywhere one can have a look at the PDF/VT spec or some sample files?
Thanks again for such a great site!
Posted by Russ on Wednesday, 24 September 2008 at 8:42 AM
Russ, thanks for the feedback. I think we'll see VDP software vendors continue to pledge support for PDF/VT over the next 12 months. The problem is that it's not yet a standard. The consumer (i.e. interpreter) part of the standard is still being authored and isn't slated for completion until sometime in 2009. Once PDF/VT becomes a standard, I believe it will quickly establish itself as a mainstream VDP language. On the topic of PDF Print Engine, I understand that many print hardware and RIP vendors are already working on PDF Print Engine support. It's clear that Adobe have got retirement plans for PostScript and we can't expect to see any significant further developments in CPSI. PDF is the future—there's no avoiding it.
Posted by Eliot on Thursday, 25 September 2008 at 8:15 AM