One of the problems we help customers with is identifying why their print jobs don’t have the number of pages they expect, using our print server RPM Remote Print Manager® (RPM).
We’ll cover several possibilities and show you how to determine what the problem might be.
#1: use job retention to show past jobs
Usually when you set up RPM, you expect the jobs to process right away and then you don’t need to see them again.
However, RPM has a built-in “job retention” facility in case you want to revisit a job before it is gone forever. We covered job retention in a recent post about reprinting. so if you’d like to review the setup and options, feel free to do that now.
Once you have job retention setup and find a job with issues, here are your options:
- Try a reprint now. It’s worth trying once in case it works. Generally, one retry is enough, either way.
- Look at the data with a viewer and see if there is a glitch.
- Look at your queue set up to see if you are limiting the amount of data RPM processes from the job
- Take note of the amount of data sent; RPM does not truncate. If you look at the print job with a viewer, and it contains 3 pages rather than the 4 you expected, it was the sending side.
For the first option, sadly, if this works, there is nothing further we can do to help you. If it didn’t work before but it works now, there are too many variables to point to a reason.
We attempt to address the remaining situations below.
#2: problems in the data
We recently posted an article describing how we helped a partner company deal with bad coding in their PCL print jobs
There may be other reasons in the data why the job doesn’t print correctly. If RPM is sending your print job directly to the printer, then it’s between the source of your print job (upstream) and your printer to be in agreement.
There are viewer programs available for some data formats; for instance, if you are sending PostScript or PDF, you can do a quick web search to find viewers. It’s also possible to find viewers for PCL. It happens that we have decent expertise in PCL, so we were able to find the tray problem without consulting the Internet first.
If RPM is processing text using your print drivers, then the most likely issue is going to be the print driver. Make sure your Windows print drivers are up to date. Then remove the text print action in RPM, create a new action and re-select your printer. RPM attempts to retain previous printer settings so that you can get just the print features you want. If the Windows printer is updated and the RPM configuration is not, you can expect a problem.
#3: limiting your data
RPM has a variety of ways to limit the data in a print job; for instance to avoid a pre-generated banner page or perhaps trim data from the end of the job.
Look in the queue setup for any transforms with names such as “limit” or “trim.” Review these to see if this is the right setup for this print queue.
Another possibility might be the text print action. Look for settings for start and end page. Default settings are 1 for the start page and 0 for the end page. If the settings are any other values, RPM limits the number of pages printed, as specified. Otherwise, RPM prints the entire job.
#4: does RPM truncate my data
RPM does not truncate your print data when it receives the job.
The LPR print protocol includes a specification for the size, in bytes, of the print job data. There is no option for RPM to limit that data, nor is there any logic to discard part of the data.
If you want to see for yourself what the sending side is sending to RPM, we have diagnostic logging to track actual communications. Go to the user interface, then Log / Diagnostic Logging. Turn on “lpd2” and “telnet2”. Enabling these settings records the conversations with your upstream print clients and RPM.
Part of this protocol is the number of data bytes sent in the print job. If you find that that number is different from the size of the print job, please contact our support. Otherwise, please contact whoever generates the print jobs and sends them to you.
If the upstream process tells RPM it’s sending so many bytes, and that is less than what you expect, then the problem is upstream, not in RPM.