PDF workflow seems to have become a buzz! Is anyone out there using a complete PDF only workflow.

What I mean is anyone only sending PDFs to their production equipment. So when a non PDF is received you convert it to PDF and do everything through your shop with a PDF.

If so, what tools do you use?

We do not have a PDF only workflow, but we do have a particular workflow for PDFs. In that we use a few 3rd party tools, primarily Pitstop Professional.

Is anyone using any tools that they find much better?

Hello all, first post so take it easy on me!

We run a complete PDF workflow at our shop.
No matter what format the files come in, they
are converted to PDF before they are output
to any device.

We use PitStop Pro and PitStop Server.
Server is very nice! It applies automation to
your workflow. It can run any number of action
lists to any number of PDFs using a hot-folder
configuration.

In my opinion PitStop Server and Pro are the
only tools you really need for a PDF workflow -
and a good RIP ofcourse.

Cheers,
Vee

Welcome Vee,

Thanks for posting. Sounds like your workflow is suiting you pretty well. What types of outputs are you going to?

I haven't used Pitstop's Server; however, I really like Pitstop Professional. It is a great tool.

How long have you been doing a pdf only workflow?

Are you using Pitstop for pre-flighting?

I am using pitstop too, both for preflight and for the workflow. It is easier to convert as much files to pdf. The problem here is when you convert a 100 pages of 4/4 color document to pdf. Its size became huge. Sometimes our Docucolar igen can not read it properly.

what rip do you have on your igen?

what type of distiller settings are you using? what version of distiller are you using? what version of pdf are you generating? are you embedding all fonts, downsampling anything, preserving DSC and other attributes?

I'm using the same as VEE for the most part and am using Quite Imposing to do all of our imposing. Layout on the DocUSP is tempermental some times and to avoid a potential problem we just stay away for it, and Quite Imposing works Great (overpriced I might add, but great!). Also, in regards to MayBeex we do NOT use Pitstop to convert to 4/c - Actrobat 7.0 Print production conversion does a much superior job that pitstops action....

We use the recommended Distilller settings from Xerox with the exception we use zip compression...




Dale

Which industry segment is being discussed? If we're talking only about digital printing, non-VDP, then a PDF workflow is certainly possible. If we're discussing VDP, then I'd like to know what PDF tools are being used to generate the PDF. If we're talking transactional documents, I'd be very, very curious!

VIPP Thin Printer can take a VIPP program and generate PDF.

What's great is that it's exactly the same VIPP program and datastream that creates the hardcopy output. So, once the program is created it simply exists in two places--printer and Distiller server--and the same simple, small data file goes in and the user gets a hard copy that's mailed along with a perfect PDF version of it for reference.

But that's not a PDF workflow... VIPP, as I understand it, is a set of proprietary macros on top of PostScript, and so will only be interpreted by a VIPP-enable interpreter. Regardless, this is pretty much the same as using ANY VDP tool, outputting PostScript, Distilling the PostScript to PDF... and calling that a "PDF Workflow".

What you're describing is a VIPP workflow with a PDF output option. That's fine, and has its uses, but it certainly isn't unique and doesn't describe what I'd call a PDF workflow.

Well, VIPP stands alone in what it does and how it does it--and it was originally designed to compose pages at the printer, directly inside the interpreter.

I thought it was cool for someone finally to recognize that Distiller is most of what a PS interpreter is, and therefore could have VIPP installed.

One *could* then use the PDF output to drive any print device that doesn't/can't have VIPP installed--but that makes sense only if you're already generating the PDF for other, non-print reasons.

And then there's Lexigraph PDF Express....ugh. Yeah, it looks like it competes with PlanetPress--but ugh. (And I say that from the point of not being a fan of PlanetPress.)

PlanetPress works similar to VIPP in that you simply send the data, the form already being resident on a host, or on the device. The difference is that at that point it's just PostScript, with no additional lookup/macro layer. (I'm very familiar with VIPP, as some of the VIPP coders were my students when I taught PostScript at Xerox.) I've done some VIPP conversions, as well, for clients switching to PlanetPress... but the topic is PDF workflow.

My point is that there really isn't a PDF Workflow for VDP, in that you could have a PDF resident on a device, which would accept incoming data and map fields to the document. For promotional and transactional documents, you still have to handle data, which includes data cleansing, sorting, CASS certification, barcode generation, suppression, and so on. Then that data has to be married, at some point, with the static elements. There are a variety of ways to do that, and at some point a PDF may or may not be generated, but there is no "PDF Workflow". There cannot be, since PDF isn't a programming language. I discussed in the article "PostScript is Dead, Long Live... PDF?".

Purely theory but doesn't the ANSI spec for PPML call for template "copy holes" for VI to be referenced from an external XML data source.

Upon processing the PDF, the data from the XML file is placed. However, the issue in implementation is not the fault of PDF but the lack of the Adobe PDF Print Engine and having to drop to CPSI Postscript from a PDF input file?

Once more, in English? I haven't kept up on the PPML spec, because I didn't see broad and/or consistent vendor support, and also because I saw no native PPML consumers. Meaning, yes, everything is still converted to PostScript and rasterized at the interpreter. So PPML seemed like so much extra work/overhead, compared to good ol' PostScript.

I agree with Patrick regarding the PDF Print Engine. The world will change enough to keep us all busy, but in the meantime, the implementation will suffer due to the PDF to PS conversion.

Technically speaking, the same thing that postscript is able to do by accessing extra data files and looping via macros or postscript extensions, ala VIPP, is possible in the ANSI spec for PPML (ie, VDX for the Nexpress folks out there).

There is a function to read in any external file, data or image and parse through the PDF engine. The PDF file can cache and compress each resource used in composition and through the linking of external files, accomplish the same thing that PS can do.

The problem lies in the fact that no RIP today is PDF Engine based, instead on relying on CPSI or Harelquin postscript engines. Kodak Nexpress actually has the ability to handle the PDF resource caching via VDX (PPML) but nothing out there takes advantage of this "feature". Because ultimately the Nexpress has to dump back out to CPSI to RIP the final print data...

But if anyone saw the Adobe presentations at Graph Expo about APPE (Adobe PDF Print Engine) you would have seen that APPE now brings the advantages of PS to PDF files and variable data streams. Of course, it will take vendors months, if not years from now to fully utilize the APPE architecture. Plus the adoption of APPE will most likely take well over a year to find its way on to current digital output DFE's.

Maybe this is just a problem with semantics, but PDF isn't doing any of the "doing" in what you describe. It's a static document file; there is no "intelligence" plugged into the PDF. I know the PPML spec can define a PDF as a page image, and mark it as an image to be cached.

If I understand this correctly, then, PPML can describe how different elements, such as external files, images, and PDF pages, work together to create the final document, but there is nothing in/about PDF itself that enables this.

In other words, I cannot open a PDF in Acrobat and have it automatically attach a datasource and create variable pages/documents. Nor can I send a PDF to a printer/press and expect it to do anything other than be converted to PostScript and rasterized. Right?

Pure PDF 1.6 standard, no. You are correct. But with the ANSI Spec for PPML (ie VDX) you get an encapsulated PDF or Multifile VDX that can do exactly that. It is viewable / previewable via a plugin in Acrobat, but can only print to a PPML / VDX engine. A common misconception is that this means only Kodak Nexpress, but reality is the VDX extensions are available to any Postscript 3 interpreter.

The biggest key here is PODI and ANSI have defined a specification for this and is becoming a widely accepted standard by application developers. Time will tell if we see it as a cross platform solution based on PDF.

The biggest difference is it is all done in a PDF wrapper and not in postscript. It is a PDF VI workflow, unfortunately, until the PDF Print Engine hits the market, it still needs to dump to CPSI postscript to process.