What is LPD / LPR Printing?

Introduction

If you have set up a computer to print to a remote system, you may have heard of LPR and LPD. When you set up using a remote hostname and queue name, you're working with LPR. LPR is the "line print requestor" or, in plain English, "please print this file at this location."

LPD is the "line print daemon" which is a way of saying it handles incoming print requests from LPR.

The queue name refers to a pre-configured set of directions for processing your print jobs. You can think of them as "packaged" because each print job sent to that queue will be handled the same way. Jobs sent to other queues would be processed to meet other goals.

Nearly every computer system supports LPR/LPD and networked printers. Of course, it's not the only print protocol used today, but it is undoubtedly well-represented.

Most LPD print systems do not give you choices like we do. They may come with one or two queues with specific, unchangeable settings. We give you unlimited queues with any settings you can create.

Note: we added a related page, LPR/LPD Advanced Topics.

Topics covered

Line print?

I have worked in the same building as a line printer exactly once in my career; it was on the other side of the door next to my desk. This device used wide carriage paper with green bar stripes. I think it was rated for around 20 pages per second! And, was it ever loud!

Naturally, it was text only. The engineers on this project mainly used it to generate listings of their Fortran programs for the simulator project (officially) although I saw some prints of Spock.

We had a print command on our Data General computers which utilized this setup.

My first experience with the Berkely LPR/LPD system was on a later project, using a quiet PostScript printer. It was my first opportunity to acquaint myself with print server setup, which later led to some of the use cases I had in mind for RPM Remote Print Manager® ("RPM").

There's no real difference to the computer between line printers and PostScript printers; they only need to know what port or address to send the jobs to, and the administrator has to know the right configuration options for each device and the files you send.

History

LPR/LPD comes from the Berkeley print system, part of the BSD or Berkeley Software Distribution. BSD, in turn, follows UNIX System V, one of the first commercial versions of Unix.

System V printing has similar commands and concepts to LPR. LPR/LPD was to be more uniform across different Unix systems.

Windows platforms, by default, support LPR/LPD printing. You may have to enable a setting to make LPR available to you.

The Internet Engineering Task Force (the "IETF") sponsors documents that define network protocols and practices of many types. Among these documents are the RFCs, or "Request for Comments." RFC 1179, published in August 1990, defines LPR/LPD.

Common terms

This chart shows terms frequently used with LPR/LPD, matched with what I believe to be the correct perspective. I've included hyperlinks to take you to the explanation in this article.

Sending jobs with LPR

LPR is the "Line Printer Remote" protocol. It works with LPD, which is the "Line Printer Daemon." LPR and LPD work together like "send" and "receive" or "command" and "execute."

The "remote" part of LPR refers to sending a file to a printer or print server "somewhere," including the same office, building, or a different continent. That is, "remote": as in "not physically attached to this computer". Since LPR works over the network, printing locally then works the same as printing anywhere on Earth—assuming your network connection is good.

LPR is similar to uploading a file or sending a mail message, except that it's a print job. LPR includes three primary functions for sending print jobs:

1. specify a named queue
2. send data about the print job
3. send the print job

Wikipedia adds the following advantages of LPR:

• with LPR, you can migrate your print processes to a single print protocol
• platform independence
• and it's accessible via the Internet

Receiving jobs with LPD

LPD is the listener, and LPR sends requests to LPD. They speak the same language. That is the intent of the graphic at the top of the page.

The essential functions of LPD include:

• handling multiple queues and multiple printers
• matching a queue name with the proper job processing
• processing related commands, such as job status in a queue

Wikipedia points out that LPR and LPD commercial applications offer more robust functionality and performance. We believe RPM, our LPD product, meets and exceeds this statement:

• we handle as many concurrent incoming connections as Windows will support
• unlimited named queues, each with a separate configuration
• a vast variety of data processing outputs and options
• extensive logging and error reporting
• automatic reprint on job error

Network implications of Port 515

1. LPR/LPD is client/server
   
   1. LPR is the print client. When you configure LPR, you tell it the hostname or IP address of the host running LPD
   2. LPD is the print server, running on a computer that is accessible to LPR
2. LPR/LPD uses port 515
   
   1. nearly any networking computer reserves port 515 for print requests, even if it does not have an LPD present
   2. sources refer to port 515 as the "LPR port" or the "LPD port" because LPR talks TO the port, and LPD listens ON the port
3. Any print request includes:
   
   1. destination hostname or IP address, that is, where the LPD is running
   2. a TCP/IP port (nearly always 515)
   3. the name of the print queue you're sending the jobs to
   4. metadata which describes the job, including the job name, optionally the number of copies, and more
   5. and, naturally, the print data

LPD queues

I have reviewed the vendor specifications for numerous printers and hardware print servers. Nearly all of them supported LPD, with one or more pre-configured queues. Typically, one queue handles plain text while another supports pre-formatted print jobs in the printer's native language.

Many hardware print servers have no internal queue names or will have one such as "LPT1". They merely route all incoming jobs directly to the printer. If your print job is not in the correct format, you may lose the job with no reporting.

I believe that most, if not all, of the software print servers I've reviewed, allow you to add queue names and may specify one or more processing settings.

RPM lets you create essentially unlimited queues. I have seen one customer configuration with between 800 and 900 queues. The program startup took a little longer, but the job processing speed was unaffected.

How RPM improves on error reporting

In the sources I reviewed for this article, one of the chief complaints about LPR/LPD is that you don't get much detail if there is an error.

On the other hand, RPM goes overboard regarding detail. We keep several internal logs that you can tune to the level of detail you want:

• a diagnostic log for each module in the project, which you can turn on or off by module
• a message log that covers the primary activities, such as receiving and printing, with varying degrees of detail
• an event log for one-time or exception events
• a critical events log that displays in the user interface for situations we deem worthy of immediate attention

Conclusion

1. LPR/LPD is simple to set up
2. LPR/LPD is very platform-independent; the LPR does not know what kind of host or printer the LPD is running on, and vice versa
3. With a mature commercial product, you'll have many options not available in the lower-end

References

1. "Line Printer Daemon protocol" https://en.wikipedia.org/wiki/Line_Printer_Daemon_protocol
2. "List of printing protocols" https://en.wikipedia.org/wiki/List_of_printing_protocols
3. "What is LPR?" https://web.mit.edu/network/appletalk/lpr.html
4. "Difference between LPR and RAW" http://www.differencebetween.net/technology/protocols-formats/differenc…