What is a print spooler?
A spooler is a device that receives incoming data from another source and stores it until it can be processed. Usually, a slower device processes the data sooner or later.
The etymology seems to be from Old North French "spole" or "espole" which refers to the "wheel for winding thread upon." I watched my mom use one of those sewing machines with a spool of thread on top. It's also common to see cable spools. It's the same concept; someone manufactures a length of cable which you then use in projects as needed. You don't want to run back to the vendor for another fifty meters of cable!
So, "spool" refers to a device or method that stores something you need to use over time.
There are several ways this applies to printing:
- Usually, your network is much faster than your print device
- Usually, your printer prints just one job at a time, where your network can easily send more than one at once
- The print spooler, therefore, arranges to store jobs for the printer, or printers, until the device is ready for it
The fastest office printer I've seen was 120 PPM, though I understand the maximum numbers are much higher. On the other hand, I can receive anywhere from 40 to 200 or more jobs per second. Even a superb printer might not keep up!
Our print server product RPM Remote Print Manager® ("RPM") is also a print spooler. First, we'll talk about the print spooler you already know, the one that comes with Windows.
Then we'll talk about how RPM operates with it or works around it.
The Windows print spooler
Windows has a built-in print spooler. I'm sure we are all familiar with it. Every time you print a document from Microsoft Word, you involve the Windows print spooler.
What does the Windows print spooler do for you?
- it keeps track of whether your computer is ready to print
- it makes sure your printer gets just one job at a time
- when your printer has completed a print job, the Windows spooler then sends the next job
- you can also see the status on jobs and cancel jobs if they have not printed yet
How does RPM use the Windows print spooler?
RPM can do a variety of tasks with your print jobs. Several of these involve printing. Others, such as email, archive to disk, and running a program, do not include Windows printers.
We offer two routes to print that work through the Windows print spooler.
The first we call "Text Print," which involves assimilating the data, possibly converting it from another form, then specifying the font, character size, line spacing, margins, and more.
We can also optimize this result for a more pleasing page layout.
This process is very similar to Microsoft Word when you print your document. When Word or other apps print to a Windows printer, it uses commands to set the font, text position, and more. The print driver creates the right bytes, and the Windows print spooler arranges for those bytes to print when the printer is available.
RPM uses those same commands.
The second route we call "Raw Print." Unfortunately, that name also applies to "telnet printing" or "direct socket printing." It's a crazy world. Our take on raw printing is to assume the print data is ready to go. We have no opportunity to set the font or line placement. We also submit the data to Windows in a different way than before. The Windows print manager still monitors the printer and presents our job when the printer is ready.
What are RPM's other spooling capabilities?
First, RPM spools print jobs to disk. It is much faster to receive and write print jobs than it is to add to our database. So, we ensure that we have a complete job, then insert it into our processing system.
Second, RPM offers reprint, which is based on job retention. We'll come to that below.
Like we said before, your network is probably much faster than your printers. RPM accommodates this by writing your print jobs and accompanying metadata to a folder. We have processes in RPM that read those files and create print jobs in the database. That happens slower than the network speeds but usually faster than the jobs are processed.
This process is automatic. There is nothing you need to do to enable it, and there's not much you can do to prevent it.
Since RPM uses the LPR/LPD print model, it places all jobs in named queues. Settings on those individual queues dictate whether jobs process immediately (that is, as soon as there is an opportunity) or if they wait for the user to enable processing on that queue.
So, whether jobs are processed right away or not depends on queue settings plus perhaps other availability, such as output device online.
RPM also offers reprint, which is possibly unique among print spoolers. To reprint, you need to retain the job after RPM processes it. We have two retention settings: keep a maximum number of jobs, and keep jobs for a specific time after processing.
You would use the RPM user interface to select one or more jobs to reprint.
Reasons to reprint might include:
- you want another copy of the final result
- you've changed some settings and want to retry to see if it's perfect, yet
- someone took your printout by mistake! (it happens)
How does RPM work around the Windows print spooler?
We talked about the two ways we use the Windows print spooler. One option includes printing pages with font and spacing selected (like most regular documents), the other uses print-ready data (maybe your PostScript document or PCL or a proprietary format).
RPM can also use network protocols entirely outside of the Windows print spooler. Here we take responsibility that the printer is ready, but we don't have a way to check using these protocols.
We mainly check whether communicating with the printer returns an error or not. If the communication doesn't work, then we reschedule the job to try again later, as we do for any similar error.
Here are the network protocols we can use to print outside of the standard Windows print subsystem:
- LPD; you specify the host or IP address and the queue name
- Telnet; you select the host or IP address and the port which defaults to 9100
- FTP: you set the host or IP address, the login credentials for the FTP server, and the remote directory
RPM spools your print jobs with low overhead and high capacity.
You are not likely to be able to slow RPM down just from sending jobs. In fact, you can send as many jobs to RPM as you want, while it is processing, and not noticeably affect the processing.
I typically send tens of thousands of jobs as fast as possible, on many occasions, and RPM has not had trouble keeping up. You can watch jobs in the user interface as they are created and then processed long after the transfer is complete. I say this to demonstrate the scale of how well the print spooling works in RPM.
Please contact our sales and technical support if you are interested in more information about RPM.