Discussion

By Joe Kling on Nov 27, 2013

I tried to hit pdf.org but get routed to the Parkinson's Disease Foundation website. Can you check and repost the URL, or clarify if I did something incorrectly? Thx!

 

By Bill Russell on Nov 27, 2013

Correction to web address ... PDFA.org (otherwise you end up at the Parkinsons Disease Foundation website.

 

By Joe Kling on Nov 27, 2013

Just found the glitch. The site to hit is pdfa.org. Test suite files are located there.

 

By Rob Stokmans on Nov 27, 2013

The url http://pdf.org or http://www.pdf.org does not seem to be the correct one. I ended up at the Parkinson Disease Foundation. Didn't I listen carefully enough to what Frank mentioned in this video?

 

By Adam Dewitz on Nov 27, 2013

Thanks for catching the incorrect URL. I've updated the summary with the correct URL.

 

By Dov Isaacs on Nov 27, 2013

Specifically, you can access the “PDF/VT Test File Suite” from which points you to version 1.0.1 of the suite and documentation at .

A few other quick notes:

(1) Although the highest performance printing of PDF/VT is via RIPs that claim support for PDF/VT optimization (including XObject caching), the fact is that PDF/VT files print on any device that can print PDF 1.6 files (using either Adobe or third party technologies). And you can print PDF/VT to non-PDF devices (such as legacy PostScript devices or even inexpensive desktop inkjet devices) simply by opening a PDF/VT file in Adobe Reader or Adobe Acrobat and invoking the print operation.

(2) We hope to have updates to the PDF/VT Test File Suite supporting up to 20,000 records and further PDF optimizations in XMPie and Adobe InDesign in the future.

(3) PDF/VT is actually an ISO standard, ISO 16612-2, developed by ISO Technical Committee 130, Working Group 2, Task Force 3 over several years with the standard itself having been officially published by ISO in 2010 after several years of intense development in which many industry technical experts representing numerous RIP vendors, printer manufacturers, and software vendors participated. I served as co-chair. Tim Donahue served a chair of that task force.

Please feel free to provide feedback on the test suite as well as the PDF/VT standard directly to me at .

- Dov

 

By Dov Isaacs on Nov 27, 2013

URLs dropped from previous posting:

http://www.pdfa.org/download/

http://www.pdfa.org/download/cal-poly-graphic-communications-pdfvt-test-file-suite-version-1-0-1/

E-mail address dropped from previous posting:

[email protected]

 

By Vic Barkin on Dec 02, 2013

A dozen years ago, I wrote a two-part article on VDP for InPlant Graphics in which I stated: "...PPML/VDX is built upon PODi’s PPML and Adobe’s PDF format which uses PDF files as containers to package the information needed to produce VDP jobs and allows designers to submit formatted variable data documents electronically. Designers will be free to create VDP jobs without a specific production system in mind, and content producers can maintain a typical relationship with print-service providers. Just as you can accept a PDF document today regardless of what created it, tomorrow you will be able to accept or create VDX document regardless of which platform or PPML/VDX application created it. The big difference is that VDP will no longer be a proprietary process."

PDF/VT sounds identical in nature, and this time I hope it will have an open enough architecture to succeed, which from my understanding is what killed PPML/VDX.

My question: Are we there yet?

 

By Dov Isaacs on Dec 02, 2013

Of course, PPML/VDX didn't support the live transparency model of the applications and only Eastman Kodak really supported PPML/VDX consumption. To make matters worse, implementations of PPML/VDX effectively needed to convert the PPML/VDX into PostScript which was what was actually RIPed.

PDF/VT differs from PDF/VT significantly. PDF/VT is pure PDF, no PPML, and no PostScript or any other artificial by-products! :-)

PDF/VT is a totally open architecture and ISO standard. It is totally based on PDF/X-4 and PDF/X-5, both also ISO standards.

When I first revealed preliminary plans for PDF/VT to Frank Romano, his comment to me at the time was that “if we knew you'd be doing this, we would NOT have done the PPML/VDX standard.”

The biggest challenge will not be whether modern RIPs can render PDF/VT files efficiently, but whether printer manufacturers implement the connections between the PDF/VT metadata for multiple page types within a single PDF file as well as “record selection” for selective printing based on metadata in the PDF/VT file.

For better or worse, there is still some reluctance amongst digital printer vendors to move from their proprietary, lock-in VDP solutions to pure PDF standards. They don't get that if they help make VDP easier with an common PDF-based print workflow, there will be more successful use of VDP in total and more of an opportunity for them as opposed to closed, proprietary solutions.

- Dov

 

By Vic Barkin on Dec 02, 2013

Thanks for the great response Dov! I wish you the best of luck in convincing the vendors that its in their and the industry's best interests not to be proprietary about it this time! I know they're listening. ;-)

I'm constantly amazed at how many service providers are still only producing text-only personalization (even if they have proprietary variable image capabilities) due to the lack of open architecture, adoption by content providers, and the proliferation of proprietary solutions.

 

By Dov Isaacs on Dec 02, 2013

Vic,

Take a gander at those PDF/VT test files. I think you'll be fairly impressed with the ability to efficiently and effectively represent highly customized and graphically-complex content in PDF/VT!

- Dov

 

By Vic Barkin on Dec 02, 2013

I did, and I am. I'll be spreading the word!

 

By Erik Nikkanen on Dec 02, 2013

I have a question or two.

If one has variable graphics, would that not require a very consistent and predictable printing and prepress process that could reproduce the correct colour?

I am not sure this is yet in place or is it?

 

By Dov Isaacs on Dec 03, 2013

Erik,

PDF/VT like conventional PDF and PDF/X files is what we call a “final form file format.” There is absolutely nothing “variable” in the file itself. It is fully composed in the layout program. (In the case of the test files discussed in the video, the layout was done in Adobe InDesign in conjunction with XMPie's uCreate Print plug-ins to merge variable data with InDesign-based templates to yield the highly optimized PDF/VT files.)

The output from a PDF/VT is fully predictable and may be preflighted in the same manner as any other PDF/X file.

Obviously, a poorly-designed template with ill-conceived rules in XMPie could lead to less than pleasing or effective results, but this is true for any methodology for merging data with a template and printing, including how your utility bills are printed! ;-)

I urge you to take a look at the test files and see if that doesn't convince you ... then I'll gladly entertain as many additional questions that you may have.

- Dov

 

By Erik Nikkanen on Dec 03, 2013

Dov, Thanks for your response. I had a look at some of the reference material.

I think I get the idea of matching a large data base of people with personal preferences and information to a limited and controlled set of graphic images.

Do I basically have the right idea now?

 

By Dov Isaacs on Dec 03, 2013

Yes, that is correct.

- Dov

 

By Mark McDermott on Feb 04, 2016

Two years after this article, and we are facing a reverse situation.
Our NexPress printers, which used PPML/VDX markup PDFs, have been replaced by Xerox iGen printers, which prefer regular PDFs. This has left up with thousands of on-demand PDFs that iGens will just ignore. The PDF/VDX's have one single file for each entry in the variable database, so each file has separate pages with the formatted customer name and date on a blank page, followed by the graphic they get printed to for covers, or Tab pages.

We are hoping there is a quick way to "flatten" the files so the variable pages are combined, preserving the paper size and type pulls for cover stock, tabs, etc. We are currently editing pages by hand as needed, which slows down the PoD precess by several hours. Since we don't know in advance which jobs might be pulled for reprint, we can't spare the time to "fix" all of them.

Of course, as NEW jobs come in, or changes to the data for old jobs, they are run through PlanetPress to create new, iGen friendly PDFs. But until all the jobs are updated, has anyone found a solution to quickly "reverse-engineer" VDX files?