« Valentine Video | Videos From Down Under »
At drupa last year, Adobe announced Adobe PDF Print Engine (APPE) 2, a new version of Adobe's PDF interpreter and ultimate successor to CPSI (Configurable PostScript Intepreter)—the interpreter used in many RIPs and print controllers.
In this new version, Adobe introduced support for digital printing and specifically, optimised the engine for jobs with VDP characteristics and will support the emerging PDF VDP ISO standard; PDF/VT which is scheduled for release later this year.
This turning point in Adobe's intepreter direction represents a significant milestone for VI languages, as APPE only consumes PDF. As a result, this engine cannot be used with many popular VI languages, such as PPML, VPS, VIPP and more.
I've been having a dialogue with Todd Kueny from Lexigraph over the past few days. Lexigraph offer a suite of tools for VI language transformations and workflows and has substantial experience in this area. They also have strong knowledge in PDF and they have developed their own C++ PDF library, built "from scratch", specifically designed for performance.
Todd made some interesting and rather concerning observations on APPE, which he has given me permission to share:
"First off, there are horrific performance issues—mostly to do with large page-count PDFs. I feel Adobe does not understand large page count PDF workflows, their tools are fundamentally not designed to support them, and as a company they have no interest in it.Second, the PDF architecture is basically frozen at 1.5 in commercial workflows—again for a number of reasons mostly having to do with useless features that complicate later versions. So much of what they think is important is not and wastes time with users.
Third, supposedly APPE will support PDF/VT at some point in the future. PDF/VT will be a catastrophic failure—mostly because its a standard being created by people who have 1) never done large page count workflows, 2) like JDF way too much, 3) done understand why PPML and PDF are failures in this area already, and 4) have nothing better to do—though in this economy I doubt the development of the standard will continue much longer. I was involved in the development of VDX—look where that's gotten NexPress—so I know what I am talking about.
Fourth, personally I do not believe they really understand parallelism in RIPs adequately—this is from my personal experience with customers who have had to resolve RIP issues with the Adobe RIP support group. Basically Adobe still thinks RIP operate desktop printers and haven't figured out how to "do the right" thing with the PDF. This is why I have two related US patents and why we are still around despite their best efforts to be everything to everyone in the RIP arena."
I'm personally not really qualified to comment in this area—haven't had too much involvement with PDF/VT to-date, other than acting as an observer to its development. On the comment of Adobe's knowlege of parallel RIP processing, again, I am unqualified to comment, but I recall that Adobe have dabbled in this area years ago with the introduction of Adobe Extreme; a CPSI-based parallel RIP workflow which was scrapped in the mid-late 90's.
While Todd's comments and critism are somewhat harsh, I'm keen to hear from others working in this area (Adobe?) for an alternate opinion and comments on Todd's remarks—to see if they are well-founded. Or not.
Posted on Friday, 20 February 2009 at 4:39 PM | TrackBack: http://www.veedeepee.com/cgi-bin/mt-tb.cgi/205
I've been involved in the VDP industry for more than 10 years now. First building high-end color DFE's and now as a DSP specialising in VDP. Like Todd claims, it indeed always surprised me how little Adobe understands about VDP. People like Todd adequately and successfully fill in such voids.
Posted by Erik on Friday, 20 February 2009 at 7:25 PM
I have personally sat in the offices of highly placed Adobe people over many years and tried to convince them VDP was important - all with absolutely no results.
I believe Adobe has never cared about VDP.
Posted by todd on Saturday, 21 February 2009 at 4:20 AM
Having worked for Adobe, I know that VDP is strategically important to them—they even offer a VDP Resource Centre www.adobe.com/vdp, however their official position has always been that VDP is a "partner strategy".
Posted by Eliot Harper on Saturday, 21 February 2009 at 4:35 AM
I would like to see an interpreter (APPE/CPSI) that can provide parallelism on an element basis, or at least allow a RIP to configure it that way. I would also like to see easier methods to generate VDP from Adobe designer tools (even in the API levels), but this might mean I'll need a new job.
I'm curious about what Todd says about PDF/VT is expected to be a failure. putting aside what he describes as reasons for bad performance of the team, what in the outcome is wrong? I'll try to recount what I understand here:
1. PDF is bad for VDP. I'm guessing because it requires parsing the whole way through to process? I think PDF is good due to compression and support of live transparency and blind exchange. But it's lacking in it's ability to reference (PDF/X-5 is definitely not enough, placing requirements that are making it uninteresting), and does not allow streaming - which I'm guessing is why Todd is considering it as unsuitable for "large page count jobs". Live transparency is probably one of the features that Todd may intend to imply in "
useless features that complicate later versions ". Is that true?
2. Their insistence on dealing with JDF is not interesting and so wastes time in dealing with other things. Performance is the issue with VDP, and not incompleteness of the workflow.
3. PPML is bad. Why? It did serve one purpose - made a single format more widely used among printers. Is Todd looking for a format that can be dealt with on the interpreter level and not require extensions from the RIP?
Posted by gal kahana on Tuesday, 24 February 2009 at 4:56 PM
gal -
I have spent perhaps the last 18 months working on applications in what would be considered the PDF/VT arena. These are large, transactional projects requiring the printing of 100K's of PDF pages in a single job. We have successfully installed systems in several countries and these system run every day on high volumes of statements. The nature of this type of application is fundamentally different from a graphic arts application. Typically
- graphic artists contribute a only few component ads.
- the rest of the PDF is generated by IT people using off-the-shelf IT PDF technologies.
- the color is wrong.
- the jobs are generated in pieces (one PDF per recipient plus meta data).
- postal processing is required to re-order the PDF pages and to update delivery information on each PDF.
- there is no transparency.
- the generating application represents a significant investment to develop.
- the job requires imposition and marking for finishing.
- the device (a big inkjet) has a massively parallel RIP which has an effective RIP rate of at least 1K pages/minute.
- the workflow is predictable in terms of PDF content, i.e, the cost of building the overall application is large and its fundamental behavior in terms of the PDF generated does not change over time.
PDF/VT makes what I think are a number of bad assumptions:
1. The producer and consumer will both posses compatible tools to handle PDF/VT correctly.
2. The producer understands the proper strategy for creating the PDF/VT.
3. Massively parallel RIPs and workflow pre-processing steps are more expensive than a PDF/VT workflow.
4. Companies owning PDF/VT consuming devices will posses the knowledge to handle PDF/VT files received from customers.
We expect massively parallel RIPs to become the standard with the only cost barrier being the Adobe RIP license (as long as RIP time is less than print time).
We expect to deliver massively parallel alternate RIP technology (first for HP JLT which we have reverse engineered - http://voodooindigo.blogspot.com).
We already have massively parallel PDF manipulation tools (color, structure, marking, counters, address handling, imposition) in production around the world.
So largely the PDF/VT effort is simply to little too late in a modern workflows:
- Parallel RIPs are fast enough.
- Our tools can validate, preflight, update color, prepare, combine and impose 100K PDFs into a single 200K+ page job delivered to the RIP in about 8 minutes on an off-the-shelf multi-core processor box.
- We can also virtually any form of assembly direction - PPML, JDML, VPS, etc. which allows the pages to be reordered for postal processing.
PDF/VT is ideal in that it distracts (and will continue to do so for another year or two) Kodak and Adobe from looking at the real problems involved with this type of application - this gives me a a significant head start in achieving a significant market penetration with out tools.
Posted by todd on Wednesday, 25 February 2009 at 1:09 AM
When you are in direct competition with Adobe you would expect Todd to use any opportunity to put down Adobe.
The fact that he has to state that he worked on a press project so that means he "knows what he is talking about" Is laughable.
I was at a print shop just last week that hates the way their NexPres processes PDF compared to how their Xerox press works. Who is to say that NexPress knows what they are doing at all?
The primary goal of APPE is to provide a PDF direct RIP that removes PostScript from the workflow. It is not to suck up to Todd's childish whining. He is also still bitter because he is chasing a target with his PDF Library that he can never catch because it is controlled by Adobe as well.
APPE is available to software vendors and will be implemented in workflow software from ISV's now that the press manufacturers have ALL bought it. Soon APPE will be on both the MFP and in the workflow.
There is a reason Adobe didn't focus on VDP until recently. Why would they? They will develop what is needed just not as fast as many of us would like.
Oh, and the statement that most companies are stuck at PDF 1.5 is an out and out lie. and I work with many of the largest customers in and out of print that use PDF - so I know what I am talking about.
Posted by Michael Lee on Wednesday, 25 February 2009 at 4:19 AM
I figure going from lcds to postscript is like going from vhs to dvd, going from postcript to pdf is like going from dvd to mpeg2, lol.
Posted by technically speaking... on Saturday, 28 February 2009 at 6:33 PM
Your comments are fascinatingly bitter!
I am most certainly not in direct competition with Adobe - I am involved with leading edge VDP applications world wide - Japanese cell phone billing, US healthcare, home centers, among others - Adobe is never present or even mentioned as a competitor in these markets for many reasons.
My customer produce full color output at any where from hundreds to thousands of feet per minute - not your grandfathers NexPress or iGen application.
These sorts of comments are why I have customers: my customers cannot live with vendors that "develop what is needed just not as fast as many of us would like" - their business moves to quickly to be hampered by such limitations.
That I am "bitter because he is chasing a target with his PDF Library" is total nonsense. Our PDF technology is vastly superior to Adobe's PDF Library in the markets where it is used - which is why Adobe is not a competitor - performance literally several orders of magnitude faster. Perhaps you'd be interested in benchmarking a problem application with one of my solutions?
I've been benchmarking commercial Adobe RIP implementations for years - go ahead and think what you like - this type of thinking is why I have a growing market.
As to APPE - your comments make it sound like a monopoly - is APPE better because it is really a better technology than one sold by, say, Global Graphics or is it because Adobe controls the PDF standard and there really is no other choice. Perhaps
As for PDF 1.5 - my point is that is where PDF is for my applications - not yours - the ROI in my world on the minor improvements the newer PDF standards offer are simply not worth the investment and/or performance penalty.
Posted by todd on Tuesday, 3 March 2009 at 6:03 AM
"My customer produce full color output at any where from hundreds to thousands of feet per minute - not your grandfathers NexPress or iGen application."
While I enjoyed the info, and even the pissing contest for the most part; its unnecessary snarky comments like this that tarnishes your point a bit. Those two print engines generally target a totally separate market than what you compare to. Yes, they are both used to output VDP content, but tend to target marketing collateral rather than transactional. They generally hit a good price point at what would be considered short runs in comparison to huge run transactional jobs which roll fed print engines are better for in price/piece. I know at least Xerox offers other solutions for that type of printing, but never used it. Nexpress, I have no idea
Posted by Rob on Wednesday, 17 June 2009 at 4:28 AM