OL Learn

Correct procedure for PDF/VT generation from Planetpress Design (7)

#1

Hello all,

I’m attempting to self-troubleshoot potentially generating PDF/VT files.

We currently have a setup where we use Connect’s Workflow, but maintain all our templates in Planetpress Suite (Design). We can’t move some of our larger templates into the Connect Designer simply because some of them are too large/complex to rebuild now.

I’ve read that generating PDF/VT files is possible from this perspective. (https://help.objectiflune.com/en/PlanetPress-workflow-user-guide/2019.1/Workflow/TasksProperties/OLConnect-CreatePDFVT.html)

I’ve set up (what I believe to be correct) process in Workflow, which returns a PDF (generated from csv data and a PP suite template), but after investigating the PDF’s properties with Acrobat, it reports that the PDF’s version is 1.4 (I believe 1.6 is recognised as PDF/VT).

My process simply checks a folder for an expected csv file, then creates metadata (which was only added as initial logs without reported it was missing), then creates a PDF/VT, and finally outputs to a folder. Both the metadata and PDF/VT tasks point to a pretty basic testing PP suite template (ptk file), where no metadata has been configured. (I have simply never interacted with the metadata side of OL’s products, but attempting to learn.)

Can anyone point to a reference, or explain in fairly layman’s terms, what a correct process would consist of?

I’m more than happy to provide any other information if it would be beneficial explaining my issue.

Thanks,
Jamie.

#2

A PDF/VT can be a PDF 1.4, that’s not a problem. The PDF/VT standard is based on PDF/X-4 and you can validate that by opening a PDF/VT file in Acrobat Reader and examining its Custom properties. One of them will read as:

GTS_PDFXVersion               PDF/X-4

To create a PDF/VT, your PlanetPress Document requires metadata so that the structure of the job (i.e. where each individual document starts and ends inside the PDF) can be embedded as an XML structure inside the file, which really is what PDF/VT is all about. If each document has additional metadata fields (as defined inside the template), then these fields will be added to the metadata and will also be embedded inside the PDF/VT.

Now you can create that metadata separately but you don’t need to: when specifying the name of the template in the Create PDF/VT task, the task will automatically generate basic metadata (which will simply include document boundaries if you haven’t defined additional metadata fields in the template) and will embed it inside the PDF.

So there really isn’t much for you to do in the Create PDF/VT task: select the proper Template and then specify which metadata level inside the job (Group or Document) represents each mail piece that are meant for a single recipient. Usually, that would be the Document level, but it could also be the Group level if your metadata, for instance, is structured so that all documents for a single recipient belong to the same group.

To better visualize how the PDF/VT is structured, you can use the Connect Data Mapper and create a new configuration using the PDF/VT wizard. Follow the instructions and the wizard will generate a configuration that already knows how to move from document to document inside the job. That’s because the Data Mapper simply follows the metadata structure embedded in the PDF/VT file.

Hopefully, that clarifies things a bit.

#3

Phil,

Thank you for your reply, I’ve took a couple of days to test and compare some outputs, and your description has been very helpful. We are now able to produce and validate PDF/VT files.

I’ve shared these results from testing with colleagues, and we’re in agreement that it’s surprising that the PDT/VT files always result in a larger file size than a standard PDF. Our understanding is that common elements are only contained one in the postscript, rather than an individual copy per instance it appears throughout the PDF.

I haven’t yet managed to find time to test how long our production printers would take to rip the file, but my base assumption would be at least the same length of time, if not longer.

Does Workflow have the capability to send the postscript as a stream directly to a printer? (Bypassing the need for the printer to rip the file.)

Thanks,
Jamie.

#4

It is absolutely normal that PDF/VT files would be larger than a standard PDF. As I mentioned in my previous post, PDF/VT is based on PDF/X-4, which is a format meant specifically for device-independent printing. So for instance, all fonts must be embedded in a PDF/X-4, which isn’t the case for PDF. Also, the metadata I mentioned earlier must also be embedded inside the PDF/VT, so that definitely occupies additional space. These differences show how PDF/X-4, as well as PDV/VT are meant to be used when higher quality output is required.

But the basic advantages of object caching inside a PDF are still present in PDF/X-4. So the larger file size should have little or no impact on performance (in fact, some RIPs may actually process those files faster since all required resources are embedded).

And yes, Workflow can send a PS file directly to a printer, either through the LPR queue or by using a Windows Printer driver.