How to automate printing a PDF document

The first time this question came up at our office, my thought was this: "Any PDF viewer has a print icon; why don't I use that?" Maybe a similar thought crossed your mind.

After all, PDF is the nearly perfect middleware for documents. It contains all the text and graphic elements you need. Any time you look at a PDF with any viewer, you get everything you expect, and it never changes. You can print PDF on any printer, should you choose to, and the results are exactly what you see on the screen.

Yet, sometimes you need to print without a human actually pressing the "print" button. Sometimes your print workflow requires that kind of solution to work around the clock, day and night. During weekends and even sporting events.

There are two reasons I know this is true:

  1. I have heard staff explaining how this works to customers dozens of times. Possibly hundreds.
  2. We added a page on our web site detailing the technical steps to print PDFs to a Windows printer. This page has been in the top five pages every month for the last 4.5 years.

I don't have a list of reasons why this comes up but clearly it does.

How we do it

If you are not already familiar, let me introduce you to our RPM Remote Print Manager product ("RPM" for short). I explain RPM as a "toolkit for solving print problems". Many of the solutions people come up with using RPM are not programmed in as much as the program's design enables, or facilitates, the answer.

Depending on your situation, there are two distinct approaches we take to printing the PDF on the printer. The first uses a third party viewer to print the PDF using Windows drivers. The second uses networking to send the PDF directly to a printer, bypassing Windows drivers altogether.

I suspect the advantage to using Windows drivers to print a PDF is that virtually any Windows printer can do this. You don't need a high end printer in most cases, although if you need speed, you'll want a solid machine.

RPM has the ability to run a program of your choice. When the customer tells us which viewer they use, we help them research a command line they could run to print to the Windows printer of their choice. We've done this countless times with Adobe Acrobat and Foxit Reader, among others.

When RPM processes the PDF file this way, it waits until the program finishes. The program needs to exit on its own. This is why we researched Foxit because some versions of Acrobat at that time had problems exiting.

When you use RPM to do direct networking you bypass the Windows drivers (some would cheer) and achieve the greatest speed. In this instance you're going to want to use a more powerful printer.

We had the opportunity a few years ago to work along side a printer vendor with a government client in the Northeast US. The print stream started with a mainframe producing a certain data format. There was a program upstream from RPM which translated this format to HP PCL. The customer needed a font change. We used RPM to edit the PCL and change the font. Fortunately this looked right in the output.

RPM then translated the PCL to PDF, and used FTP to submit the print job to the printer. RPM has a built in FTP client although you could use your own by executing the command line as I described above.

RPM has two other networking protocols built in for sending jobs to printers, LPR and IP using port 9100 (or any other port). FTP happened to be the one this situation called for.


When you encounter an automated print challenge which is not completely in your wheelhouse, I hope you will consider talking with us. We have a unique set of tools in RPM and ample experience with automated processing. I've hinted at only some of that here.