Software Print Server

How can a software print server benefit your printing process?

RPM Remote Print Manager® is our software print server product. Let's explore the ways our customers are using it in ways you can't use a traditional hardware print server.

Broadcast printing / print to multiple printers

Someone called us recently who needed to send a print job simultaneously to the warehouse and shipping offices. These locations had two distinct printers (from different manufacturers). We had them up and running in five minutes.

Actually the Select version of RPM can handle up to ten unique printers, and the Elite version can handle 99 (with options for unlimited).

Email attachment and archive to disk

A common request is to convert a print job to PDF, attach it to an email, and archive it to disk. RPM can do this easily.

RPM can convert a number of input formats to PDF (as well as PCL, HTML and plain text, among others).

Once that is accomplished, RPM feeds the data to the "actions" you define. For this situation, the actions would be "attach to email" and "archive to disk". For the multiple print situation above, the actions would be "text print to the warehouse" and "text print to the shipping office". Same difference. There is no fixed limit to the number of actions you can apply to a print job.

This is an example of how a print server can do in software tasks you can't likely do in hardware.

Auto-rotate and scale printed output

RPM converts text formatted data to its own internal "text markup" format. This text markup can then be sent to a text print action (like our first scenario, above) or converted to PDF (like the second scenario) or a number of other possible outcomes.

The text markup lets you set the character width and height, for instance, 7.5 lines per inch or 13.2 characters per inch. We can also use page settings, for example, 66 lines per page, 140 columns.

The same function also has "auto-calc". If you use this, then RPM will look at each print job, up to 64K bytes and determine the line and page lengths. It will then scale the output to fit. At the same time, you can specify the longest lines you would want to see in portrait mode; if the output lines are longer, then RPM automatically rotates the output to landscape.

This applies to the text print and PDF output, and PCL output as well.

What this means to you is that you can send print jobs to one queue and let RPM use its flexible scaling to make the jobs come out right, whether you use Windows printing, direct to a PCL printer or convert to PDF. 

Binary search and replace

RPM can do search and replace to change strings in your file. For instance, we regularly work with users and printer vendors who need to "patch" a PCL file to change the input or output bin.

We have worked with PCL enough over the years to help you with this. Of course, we can change anything else in the file you need (or you can) but PCL tweaking is a common request.

Ultimate customization--run a program

RPM also provides the "ultimate customization" where you can send your print job to a program.

We were recently contacted by a customer in the financial industry. The company receives reports and orders from one of the major financial reporting services (if we mentioned the name, you would recognize it). 

The customer's problem was that they printed over four thousand pages per day on their LaserJet; at the rate they were wasting both paper and toner, our software would pay for itself quickly. We worked with them to configure a queue to send the print jobs to what we call a "filter action". It's a name that comes from the Unix printing world where the concepts for RPM were originally conceived.

We contracted with the customer to script this program, which we did in under eight hours. All jobs came into "queue A" which had the filter action. RPM ran the program. The program looked in specific places in the file. Most files were discarded immediately. Around 20% were sent back into RPM to "queue B" where they were converted to PDF and emailed. The remaining files were sent to "queue C". This queue was set to "hold jobs". An operator could right click on a job, view the contents, then either drag the job to "queue B" or delete it, or keep it until later if they preferred.

Between consultation with us, some development time, testing, and a little refinement, the customer had their print situation in control in around a week.

What would you like to do next?