I’ve been helping folks to get PDF output for years using Ghostscript.  One of the things I like about it is that it answers the multiple sets of printing instructions in a document question very naturally; you can concatenate multiple postscript files together into one PDF document, and each “document section” obeys the rules with which you printed it, no problem.

PDFListener and PDFClass exploit this capability for VFP report forms, by supplying a collection of reports (in PDFListener’s case, inherited from FFC’s _ReportListener) to help you manage the process of running multiple reports in a sequence to postscript files, sending appropriate instructions to Ghostscript, and tidying up.

This isn’t a VFP-specific reporting scenario, of course.  In fact I’ve been answering lots of RS forum posts with advice like this recently:

You can find a demo app with code for printing reports without UI, using the ReportViewer control, on this page: http://www.gotreportviewer.com/. I expect it can be adapted to go to a ps printer driver and given target file information (or the ps driver setup can be set to go to a file target explicitly — but that doesn’t seem thread safe to me).

Then you can use standard postscript to PDF capabilites to convert the string of files you just wrote out.  I use Ghostscript to do this, you don’t need Adobe and you don’t need any UI for this step either. You can learn about Ghostscript here http://www.ghostscript.com/awki  There is a overview of command-line switches here
http://ghostscript.com/doc/8.54/Use.htm#Options — for your purposes, pay particular attention to the ability to create a commandfile listing all the
switches as well as all the files you wish to process in this run (more flexible than listing the files directly on the command line if your list may be long).  You may prefer to use the API directly (DLLs rather than command-line).  It’s quite extensive.

The process is simple, and really does work quite well.

But there’s an important difference between what VFP reports can do and what Reporting Services can do: in VFP’s case, we can’t get PDF output natively. On the other hand,  RS provides PDF as a native export format.  That means RS folks don’t have to go all the way down to the PS file level to use PDF files as document sections if they don’t want to.

While I think there is stuff in the Ghostscript API that will let you concatenate PDF files properly into a single document (stripping off the extra header information from each, or whatever it takes), I’m pleased to say that I’ve found another utility recently that does this job with no fuss at all.

Take a look at PDFTK.

PDFTK is a GPL, cross-platform toolkit for PDFs with no reliance on Acrobat.  And if you’re working with PDFs as your input files, you have no reliance on printer setups either; that part is already done by the time you “get here”.   I’ll quote from their relevant examples:

rem Merge Two or More PDFs into a New Document
pdftk 1.pdf 2.pdf 3.pdf cat output 123.pdf
rem or (Using Handles):
pdftk A=1.pdf B=2.pdf cat A B output 12.pdf
rem or (Using Wildcards):
pdftk *.pdf cat output combined.pdf

 

What could be easier?

What’s that you say? You don’t like the idea of shelling out to unmanaged code to perform this task?

And I thought java purists were annoying…

Retro is the new future

Quit whining, learn about true interop, and make the best tool for the job your new mantra.

Invoke PDFTK with Windows Power Shell if it makes you feel more au courant, more comme il faut, more with-it, or more… powerful.

I figure, since it’s taken Windows until now (Windows Server 2008?) to come up with something integrated into the OS that handles a pipeline like *nix always did, PowerShell is probably pretty good…