RPM Remote Print Manager® ("RPM") is a unique product in the marketplace. Even though RPM is a print server and a virtual printer, our primary goal is to provide a print workflow that you can set up yourself. Of course, we can help! When print jobs arrive, RPM will run unattended to produce the results you need.
For instance, let's say you have PCL files you want to convert to PDF, but you still want to print the files. With RPM, it's easy to set up a workflow to accomplish this. First, you would create a queue that receives the print job and sends it to the printer you specify. This queue would also copy the job to a second queue where you would convert the PCL to PDF, then archive to disk (or email or several other likely actions).
The reason we split it up this way is this. When RPM processes your print job, first, it runs through all the data changes or transformations you specified. Then it sends that result to each of the actions you have added to that queue. In this example, we printed the original data. Then we copied that data to a different queue where we changed it to PDF, and then we archived that PDF.
Following is an overview of the significant parts of RPM. In this article we'll talk about:
- Inputs to RPM, that is, the ways you can get jobs into the software
- Print spooler, which is the gateway to many of our features
- Queues, where much of the action takes place
- the Job scheduler, which controls the order RPM processes jobs
- Transforms and actions
Inputs to RPM
RPM is a listener, or server, for the following:
- Telnet, or port 9100 raw socket
- AppSocket, or port 9100 JetDirect compatible
- folder watcher
- our custom RPC API which the user interface uses
RPM includes a print spooler, which stores incoming print jobs on disk before the RPM scheduler runs to process the jobs.
The two primary reasons we spool print jobs to disk are reliability and flexibility.
Let's talk about reliability first. If we sent your print job directly to the printer as it arrived over the network, and we did not spool to disk, then you would inevitably run into two problems: if the network fails, you have only a partial job printed. In fact, with some print languages (e.g., PostScript), you would have no printed job at all.
Similarly, if the printer fails for any reason while printing, your job is lost, and you will have to send it again.
You don't have to have a computer science degree to appreciate that spooling print jobs is the more reliable solution.
Secondly, by spooling print jobs, we can offer customers the flexibility they would not otherwise have.
- RPM will automatically retry a print job if it fails for any reason
- we offer a reprint feature depending on how you configure the queue
- you can manually hold jobs and release them to print later
- RPM supports the copies command, so you don't have to resend the same job repeatedly
RPM also allows you to put a priority value on devices and queues so you can fine-tune the job processing order. Additionally, RPM Elite offers several job scheduling options for broader policy control.
None of this would be available without spooling your print jobs.
RPM follows the model of the LPD print server, where you send print jobs to a named queue. Queues in RPM function much like a print queue on a Linux system, although we have extra functionality.
Each queue has a unique set up so you can create utterly independent processing in each queue. RPM also features queues working together, which is a topic we can explore in a longer article about print workflow.
Queues also have settings that control whether jobs in the queue are immediately available to be scheduled or not.
For a comprehensive overview of queue setup and functions, see the page How Queues Work in RPM.
Once RPM spools your print job, next on the list is scheduling. RPM Select offers one scheduling model, "FIFO" or "first in, first out." RPM creates jobs when they have entirely arrived (or soon after).
RPM Elite offers four scheduling models:
- The "FIFO" model works the same as RPM Select, where jobs process in the order they arrive
- The "fair" model tries to service all the eligible queues which have jobs
- With the "priority" model you can set a weight on queues, devices, and actions to receive preferred scheduling (or deferred)
- The "ordered" model attempts to process in order of the job ID
The user interface with RPM Elite lets you select the scheduling model where RPM Select does not.
Also noteworthy in the job scheduler:
- if there is a "copies" directive with the job, the scheduler runs that many copies of the job
- if the job is interactive, the scheduler will wait until a user that can process this job is logged in
Actions and transforms
The way we achieve print workflow for you is by using transforms and actions.
Actions are outputs such as print, archive, email, and several others. The RPM Actions Portal includes more discussion and a list of actions RPM supports.
Transforms make changes to your data, possibly converting it entirely. We have one exception, data extraction, which searches your data and extracts values. The RPM Transforms Portal includes more discussion and a list of the transforms RPM supports.
As we said above, when we receive the print job, we spool it to disk in its original binary form. That way, we always deliver accurate data to your print output.
However, there are numerous occasions to convert your data one way or the other. For instance, PCL to PDF is a significant conversion.
RPM features several dozen transforms, which can be useful for a variety of processing tasks. Most of the "how-to" articles use transforms.
When you configure a queue with multiple transforms, RPM processes those transforms in order. The first transform receives the print job data for this job. RPM, in turn, runs each transform using the results of the previous transform.
Finally, RPM hands the result of the transforms over to each action.
Print workflow gets more impressive when you copy the job to another queue. In the example above, where we printed an incoming job, then converted it to PDF, that's how we achieved that result. Once again, refer to the fact that all the actions in a queue receive the same input. In the first queue, the action is "print this file directly to the printer." For convenience, we assumed the printer would not accept PDF, although some do.
In the second queue, we want to write a PDF file to disk. The transform or transforms we add to this queue will create a PDF from the original print file. Then the action, "write a file to disk," writes our result to disk.
More RPM support
The RPM FAQ includes links to subsections on many specific topics in RPM.
Much of our published material on RPM is a discussion on how to perform a variety of common tasks. We have the How to page which includes topics ranging from "how to send print jobs to RPM" to "how to get RPM to print on multiple output trays".
The Print To page delves into common subjects such as print to a file, print to email, print to PDF, all based on customer inquiries.
PDF itself is a broad topic that has much coverage in RPM, so for that we offer the RPM PDF Portal.
Unicode as a unifying technology has certainly grown up and become dominant worldwide while RPM has been in existence. On the Unicode support for PDF page, we delve into this topic.
RPM is a Windows product so naturally, Windows printing is an important topic. The RPM Windows Printing Portal covers this large topic.
RPM also covers all corners of the LPR / LPD protocol as we cover in this FAQ.
RPM is currently in the 6.2 release. The changes and updates that went into 6.2 are extensive and are covered in the 6.2 guide.