We have a video on our website that explains how to set up a Windows printer port definition to use LPR. In the video, we mention that you *must* select the 'enable LPR byte counting' option in the Microsoft TCP/IP port dialog.
However, we no longer require you to set that option. As of version 6.2, RPM Remote Print Manager® (RPM) handles the unusual way Microsoft informs the printer world that it has a print job.
Why the print client might not know what size the job is
In the Microsoft printing world, it is entirely reasonable to send a print job over the network as fast as possible. And this happens every time your Windows application prints to a TCP/IP port. Your print job is the product of the print code itself analyzing the formatting, fonts and such in your print job. Then at some point, the print driver for your printer will convert what you want to print into a set of commands.
There is no way to know at the start how many commands it will take to express your print job correctly. If you are using the LPD protocol, it wants to know upfront what size your print job is. However, there is a way around that. There's the hard way, which is to write the entire print job to disk, and then send it. You can see where this approach is time-consuming. And then there is the easy way, which is what this article covers.
By the way, if you are printing a file from a disk, then the print client already knows what size the print job is.
The expected way to say "I don't know what size this job is"
The LPD protocol is set out in a document called RFC 1179, available from the Internet Engineering Task Force. Internet standards and practices use technical documentation called "requests for comments" or RFC for short, to discuss technical issues and get agreement upfront. The documents have unique numbers, and LPD has 1179.
This document describes the LPD conversation at great length. One of the components of the dialog is the size of the data file. If that size is not known, then the size used in the request should be zero. There is an expected behavior to go with this, which the RFC also describes.
Of course, RPM handles this.
The Microsoft way to say "I don't know what size this job is"
It's not completely clear why Microsoft chose this approach. Rather than say the data file is zero length and allow standards conforming printers and print servers to handle it, Microsoft instead decided to use a size greater than 4 gigabytes to express the concept "I don't know what size it is." The examples I've seen are over 16 GB with no consistency.
It's also not clear how many printers have trouble with this, but it seems the industry adapted.
How RPM handles the Microsoft way
When RPM's LPD protocol module sees a data file size over 4 GB, it makes a note that it's probably not accurate. Then RPM receives the data file until the connection closes, and makes the appropriate adjustments for the actual data size. Having a "too short" data file is no longer an error, warning, or any cause for concern.
Unfortunately, there is a caveat to this approach. First, the Microsoft LPR client typically adds a null byte to the end of the data file. Since the LPR client deals with files and not LPD printer ports, it also sends the correct data file size. Using that we know we have received more bytes than necessary, so it's legal to trim back the extra byte. If a printer depended on that extra byte, this would be a problem.
The Microsoft LPR client is a command-line program. It's not the same as their TCP/IP port monitor.
If the Microsoft port monitor sent an extra byte, there would not be a way we would know that since the file size is wrong.
Conclusion
In the past, we've asked customers to please turn ON the setting to "Enable LPR byte counting" in the Microsoft TCP/IP port monitor. Now, with RPM 6.2, you no longer need to worry about this.