Blogs

Due to the influx of customers using RPM Remote Print Manager® (RPM) to send print jobs to multiple trays in a given printer, we have produced a video which demonstrates just that.

The title of the video is "Triplicate Printing" to denote the way many of our customers refer to this process. Other names include multiple tray printing, printing on multiple printers, even using different colors of stock.

Using RPM as a toolkit, a set of building blocks, one of our customers was able to construct a digital workflow which let them print a given print job on each of 4 trays in their printer.

Introduction

RPM Remote Print Manager® ("RPM") is a Windows service, which is not news to you if you are reading this web site. RPM does not itself appear on anyone’s monitor; it runs in the background only. We also have a user interface which we call the “UI”, because we’re tech people and we abbreviate everything.

Typically people use the UI to watch RPM running on the same machine. When you install RPM at first, we launch the UI. All the basic setup and fine tuning happens in the UI. Of course, that is not news, either.

Introduction

We were working with a customer running RPM Remote Print Manager® ("RPM") in a large network which included several hospitals. The problem they ran into occurred while their high capacity LPR printers were offline at night. RPM would fail to send the print job, so it would retry the job every so many minutes. This filled their log with "job retry" messages.

The problem of course is that if there were any other problem happening, it would be hard to track down due to the volume of similar messages.

Introduction

RPM Remote Print Manager® ("RPM") is not my first LPD print server software. That honor goes to a program called "WSLPD" which I wrote for a US government agency in the early nineties.

The LPD print protocol is not that hard to understand. There is a reference document for it available on the Internet to anyone who wants to know. You can track it down with a search for "RFC 1179". The conversation essentially goes something like this: 

Introduction

The data extraction module is part of the Elite edition of RPM Remote Print Manager® or "RPM". This module gives you a way to extract text fields from your print job using rules you define.

For instance, you might want to use an invoice number which starts at column 60 on line 5 of your print job. Let's say you want to use that in the job's file name when you archive to disk (after converting to PDF).

Hint: it had nothing to do with the database

I started up the RPM Remote Print Manager® (RPM) user interface one morning, and instead of the usual list of queues and jobs, I saw this instead:

Introduction

A number of years ago we decided to host the database for RPM Remote Print Manager® (RPM) in an external process. If for whatever reason we had a database problem, we didn't want to affect print job processing.

Naturally, we wanted to use some method of communication which was lightweight and reliable. We considered using the network like we did with the user interface (UI), but decided against that as the UI conversation can get very busy when there are a lot of jobs coming and processing. It seemed like a good plan to keep those two channels separated.

One of the changes we added recently in RPM Remote Print Manager® (RPM) was to make your print jobs launch faster.

Whenever you receive a print job from the network, of course the aim is to process that job as soon as possible, and I believe we have been doing that all along. However, there are many other situations which result in jobs needing printing right away. We did it before, but now we do it more proactively, I believe to good result.