Portals
Transforms
Actions:
- History
- New approach
- Software MFP
- Actions list
Print to
Windows printing
Text markup
Queues
How to
Workflow
Archive
Purpose
The purpose of RPM Remote Print Manager® ("RPM") "actions" is to give you the most functionality, the most output options, for your print jobs.
Most print servers do one thing, and do it very well: they send every print job they receive to the same printer, and no changes to the data stream sent to the printer. This works much of the time for many people.
A smaller set of print servers support multiple queues. These queues typically have some settings for data tweaking.
RPM has always gone far beyond that. For years we supported three types of print actions:
- Windows printing, which we referred to as "text printing"
- Direct to the printer, which we referred to as "raw printing" based on comments in some Windows documentation (that's more or less what typical print servers do)
- Run a program on your data, which we called "filter processing", derived from our Unix heritage
We executed this approach by assigning a "type" to each queue. That queue performed one of these actions based on its type and other setups.
We also had some general processing steps independent of the 3 print actions, which we called "transforms" hidden behind the term "Print data options". This is how you specified a code page, SCS, insert a file, etc.
A new approach
However, the weakness of that approach became evident every time someone asked us, "How do I print this job, then archive it?" or, "How do I send this to two different printers?" Those are the simplest versions of the same type of question we heard over and over.
What we decided to do was break out the print actions. Rather than a queue having one action based on a "type" we came up with this approach:
- run the job through all the transforms the user specifies
- take that result and feed it to one or more actions
Now we can print, archive, email, as many places and times as we want. We have it set up so that the actions are independent from each other. It doesn't matter which goes first, or next. We use multiple threads so the actions are usually done in parallel.
The one caveat is that the actions need to use the same data.
While the multiple action approach is an improvement, it still doesn't answer the question of what to do when the data is not in the form you need for the action. For instance, let's say you convert to PDF, and your actions archive to disk and email a copy. These are well suited to PDF input.
Now, what happens if you want to do a Windows print action, and archive to PDF, and email? The Windows print needs an intermediate form, text markup. It won't work with PDF data. On the other hand, we convert to PDF from text markup.
We decided to address by adding a "copy to queue" action. Doing this, we expanded the workflow capabilities of RPM considerably.
Multiple actions for a multifunction software print server
Let's use some examples to illustrate.
First, let's send text reports to completely different Windows printers; different printer languages, different vendors, etc. Let's call them printer A and printer B.
Our configuration:
Transforms
convert the text to text markup
Actions
- Text print to printer A
- Text print to printer B
We have now demonstrated broadcast print with two completely distinct printers.
Next, let's try this: convert to PDF, archive, and email. To do that:
Transforms
- text markup (in this case, plain text is converted to text markup)
- text markup to PDF
Actions
- archive; this gets the PDF file and places it in a folder
- email; in this case, the PDF file is an attachment
Note that the two transforms are run back to back, then the PDF is handed off to each of the actions.
Now, let's do something a little more challenging. We receive Simplified Chinese and Traditional Chinese jobs. They are not identical. We want to print them to a Windows printer (our text print action), and convert to PDF, archive, and email.
Here is how we do it:
Queue A, send Simplified Chinese here
Transforms
text markup transform that reads Simplified Chinese and writes UTF-8
Actions
copy to Queue C
Queue B, send Traditional Chinese here
Transforms
text markup transform that reads Traditional Chines and writes UTF-8
Actions
copy to Queue C
Queue C, send text markup here
Transforms
None
Actions
- text print
- copy to Queue D
Queue D Transforms text markup to PDF
Actions
- email with PDF as an attachment
- archive the PDF to the specified folder, as above
With this setup, we have handled multiple languages and hit 3 distinct outputs, the archive, email, and print.
Actions list
Text print
- input = text markup
- Windows printing which supports any Windows printer including shared
Raw print
- input = printer language
- Print directly to any Windows printer, including shared
- input = anything
- Anything can be attached. Plain text and HTML can optionally be used as the message body.
Archive to Folder
- input = anything
- Write the results of transforms to disk, job metadata is available for file naming, supports shared drives
Filter
- input = anything
- Run any program available, job metadata is available for command-line options
Copy to queue
- input = anything
- Copies print job using the final output of any transforms to another queue
LPR printing
- input = anything
- Sends print jobs to an LPD server remotely, locally or loopback
IP printing
- input = anything
- Sends print jobs to any IP addressable printer, defaulting to port 9100
Archive to FTP
- input = anything
- Use File Transfer Protocol (FTP) and file naming options to upload print jobs to an FTP server