RPM Print Workflow and Custom Bursting

Introduction

I was in a video meeting with several executives a few years ago, explaining what our RPM Remote Print Manager© ("RPM") software could do. When I got to the part where RPM "can run a program on your data, which means that it can do essentially anything," they were immediately intrigued.

One of them asked: can you give us an example? The case I had on hand was putting the data from the print job into a relational database. Anyone can see that this case has no relationship to ink on paper.

The Customer Requirements

Later, one of their customers came to us with a request:

1. we have letters we want to send out, and we want to include our company logo on page 1
2. but some of the letters are two pages or more, and we don't want to put the logo on the other pages
3. The input is text, and the output needs to be PDF

I should mention that these letters were contained in one large file and the content of each letter was variable.

The input mainly consisted of plain text pages, but it also included formatting data, codes representing a unique filename, and some setup "jargon" they didn't want in the final output.

How we addressed the customer requirements with RPM

First, I took stock of several things RPM was already good at:

1. using the network print protocols to receive files
2. converting plain text to PDF with complete control over fonts, line spacing, margins, page size, as needed
3. generating PDF documents with any number of pages
4. placing a logo on a specific page, e.g., page 1 in this instance

RPM can do more than these items, but this list is relevant to the customer's requirements.

Next, I considered the pieces that RPM could not address on its own:

• how to identify what was supposed to be the next "first" page to place a logo there
• how to remove the pages which do not contain the data the customer was after

I offered to write a program to burst their input text file into individual text files according to their criteria. A burster, or a burst program, takes a single file and "bursts" it into multiple files using some criteria. We would then send each of those files back to RPM to convert to PDF and add the logo. RPM is already good at those things, and we didn't need a stand-alone program to do them.

Later, the customer specified the conditions for their input text file. The burst program would need to accomplish the following:

• There is a delimiter in the file to separate the input into individual letters
• Use a regular expression to glean the output filename from the text.
• If a block of text does not have this expression, if we come to the end of the letter text and the filename is not specified, discard the text because it does not contain data our customer needs to send to their customer.

Adding one element to the workflow

By introducing the burst program into the workflow, we were able to take advantage of several more operations that RPM was good at:

1. Running a program against a print data file, which generated an individual text file for each letter, in a Windows folder they specified
2. Using the folder watcher, which we named Queue Folders; it automatically collects files created in that folder and submits them to an RPM queue as if we had used network print protocols

After reviewing the criteria and the samples I generated from their test input, the customer agreed to the burst program. They said they wanted to put the customer letters into their document management system, and separating them by customer now was a benefit. They had not mentioned this yet.

A note on the folder watcher

Historically, RPM has received print jobs via the network print protocols. We added the folder watcher mainly due to customer requests. We later realized that this addition resulted in a substantial change in the product.

Over the decades, RPM has grown from a simple print server with some options into a data processing engine that may not even result in printing. We've added many upgrades and features to our data processing, and printing is just one thing we do.

By adding the folder watcher, we no longer rely strictly on the print protocols to submit your print data to RPM.

The folder watcher works this way:

• You can assign a folder to a queue.
• RPM will watch this folder for new files created that it has permission to open.
• A folder can only be watched by one queue, so there is no confusion about how RPM processes the file.

When you create local files and want to get them into RPM, the folder watcher is the quickest and easiest way.

On the other hand, when you send files from your host system, we still recommend the network protocols since RPM is very good at networking. On your local system, you can use either method. I've used the "pylpr" program, which we include with RPM in the install folder, for better than a decade.

Conclusion

You can appreciate that this example is not complicated. I've created RPM as a print processing engine that makes it easy to innovate and accomplish tasks I didn't envision when I planned and wrote the software.

Please consider contacting our support staff to discuss your ideas for your print data workflow.

This article was NOT generated with the help of AI except that I asked one if it knew what "document bursting" meant. It did. I had already selected that term on my own.