An IBM Selectric model electric typewriter
A Teletype model ASR–33
Printing was so simple once! Although the story of printing goes back to the time of ancient Greece and Rome, we will skip a bit to the 1970s. Printers were little more than typewriters, some without lower-case letters such as ASR–33. They used to sell a "clip-on" board with 53 motorized "fingers"; you would position the fingers over the keys of an electric typewriter to convert it to a printer!
A cable connected the printer to a port on a computer. Generally a printer was attached to a parallel port (often called the printer port) which has eight parallel wires to send a character of data in one fell swoop. However printers could be attached to any port available with the right cable. (Today this includes parallel ports, serial ports, USB ports, etc.) An application on the computer could print by sending the text, one character at a time, out that port. That's all there was to printing back then: the printers could only print ASCII text, and computers supported only one application at a time. Easy-peasy!
At first printing was pretty slow. It still is! But initially this was acceptable since computers weren't used by the rich and powerful. (Early users were accountants, students, scientists, etc.) Some changes occurred in the late 1970s and early 1980s that caused some complications in the world of printing. One such change was the popularity of so-called personal computers. All of a sudden computers were being used by corporate VIPs and lawyers, and the slow speed of printing on these systems and the general poor quality of the output was cause for concern. Imagine having to print out a 40 page contract when your printer took several minutes to print a single page! Even worse was the problem that the computer would "lock-up" or "freeze" (meaning you couldn't use the computer) until the last page of the document completed printing.
A CDC Line Printer
Another problem occurred when time-sharing computer centers became popular. Prior to this computer centers ran in batch mode, which meant only one program (today known as applications) could be running at a time. These computer centers usually used line printers, which printed a whole line of output at once, at speeds up to 1,000 lines (about 15 pages) per minute. But after time-sharing operating systems were installed in computer centers several users might be running applications at the same time. If two or more users started printing simultaneously the data would get inter-mingled. The result was a mess to say the least, and due to the slow speed of printing this was a distinct possibility.
(As an historical aside, printing in computer centers could take hours for a print job to complete. As a person's office could be in another part of a building from the computer center (or even in another building), the poor user had to guess when printing was completed and periodically check the computer center. What a waste of time! To make life easier some print utilities had (and still have) options to request an email message when printing was completed. You would then make a single trip to the computer center to pick you your printing!)
Still another problem was the advent of dot matrix and other "fancy" printer technology. These printers were still slow but could print more than just plain text. An application could mix special non-ASCII printer control codes in with the data to activate extra features such as bold, italics, underline, switch to second paper source, and so on. Usually there was one code to turn on a feature and another (or the same code a second time) to turn that feature off. This may not sound as if it would be a problem, but consider that printers were and are big business.
Dozens of companies produced hundreds of different models of printers over the years. You might think that since it can't possibly matter what code was used for what feature, all these printers would use the same code for the same feature. Sadly this never seems to be the case and if you had such a printer, it was up to you to figure out how to type the non-ASCII control codes in your document. (Back then printers would come with poorly written booklets documenting the control codes.) If after a year or so you purchased a new printer, it was unlikely that your saved documents would be printable since all the codes would have different meanings for the new printer.
By the end of the 1980s computer networks were becoming common in the workplace. This meant that applications had access to multiple printers, perhaps all different types. Since no applications knew about networks you might wonder how could they print to a remote printer (a printer attached to a different computer), or even know what printers were available. At first they couldn't!
Something had to be done to solve these problems. The solutions that were developed are not perfect but are mostly still used in today's printing systems: Print servers un-freeze computers while printing and coordinate printing from several applications simultaneously. Print filters and drivers convert application specific print codes into printer specific codes and control the extra features of high-end printers. Network operating systems allow users to select a printer to use and to direct an application's printer data across a network to the right destination.
Many printing problems were resolved by adding a print server, also known as a print spooler, print daemon, or print system. No longer did an application communicate directly with a printer. Instead the application communicated with a print server and the print server would then communicate with the printer. The application could find out from the print server which printers were available and specific printer characteristics, such as the printer resolution (often measured in dpi or dots per inch) and what options the printer supported.
When the user selects the application's print function, chooses a printer destination, selects options, and clicks on "OK", the application then creates something known as a print job. A print job contains the data to be printed, the name of the print destination, and which options were selected. The print server accepts this print job and stores it (temporarily) on the hard drive in a directory known as the print spool or print queue directory. This is sometimes called spooling or queuing a print job. From the application's point of view the document has now been printed and control returns back to the user. No more "frozen" computer!
Of course this isn't the end of the story. The print server also has the task of monitoring the printers under its care. When a print job is waiting for some printer, then when that printer becomes available the print server will send it to the printer, finally printing it. By having each printer under the control of a single print server, the problem of may users printing to the same print destination at the same time is eliminated. Rather than mixing the output of all those print jobs, the print server keeps all but one in the spool directory. Each print job is printed in turn.
A print server must seem like the perfect servant to a user: They say to print something and the print server does so, taking care of all the details and never getting confused no matter how many print jobs are created at the same time. Still there are a few problems.
Adding print servers to computers meant rewriting all applications to use that print server rather than send data directly to a printer. Servers change from time to time, say from Novell Netware to WindowsXP or to one type of Unix or Linux print server to another. This means older applications may not be fully compatible with the new print system. They may not be usable at all!
A print server on one system must currently be manually configured to know about remote printers. Also care must be taken to have each network printer under the control of a single print server (or intermingled output from multiple print jobs is a possibility).
Designing a printing infrastructure is a juggling act. Most Unix/Linux systems must have a print server running on every host that runs an application that supports printing. These generally just forward the print jobs to a remote print server. That's a lot of print servers! If an organization has many networked printers an administrator must decide which print servers will handle which printers. Note that a print server has a maximum number of printers it can handle efficiently (not to mention a limited number of printer ports per server). That number varies with many factors (such has how much printing is done on those printers and the average print job size), but no more than a few dozen not-too-busy printers per server is typical. (A busy PostScript printer may need its own print server.)
This is not normally a problem but in a large organization with dozens of networked printers it may be an issue. Every time a new printer is added, all printer servers need to be updated to know about it. What a pain!
With modern systems you don't need a print server per workstation anymore. (Modern workstations can talk across a network to a print server.) It may seem simple in this case to only have one print server for all printers. Sadly this is a single point of failure and of network congestion. You should always use at least two print servers in any medium to large organization. With at least two (and proper documentation), printers can be migrated from a broken server to another in short order. However this still leaves some networking issues to resolve.
In the Unix/Linux world standardization efforts are underway with a new printing system known as CUPS (common Unix print system). Only time will tell if this new system will be the Jeeves of print servers or not.
Using print servers solves some of the problems of printing, but not all of them. To understand one of the remaining problems you must also understand a little bit of printer technology.
Once printers could display more than just plain text a way was needed to turn on and off special features such as bold, underline, color, and so on. These features were enabled by sending special printer control codes mixed with the text.
Dot-Matrix printer output sample [ From en.wikipedia.org/wiki/Dot-matrix_printer]
Modern printers are even more complex. They produce images by carefully positioning tiny dots of ink. Originally such printers produced awful looking output (worse than a modern FAX). This was the result of using a small number of relatively large dots. The density of the dots is usually measured in dots per inch (or dpi) and is known as the printer's resolution. Originally dot matrix printers had a resolution of about 20-75 dpi. By way of contrast, books and magazines are printed using high-end dot matrix printers known as typesetters. These machines have resolutions of 30,000 dpi (or more)!
A modern printer may use ink-jet technology to spray the dots of ink onto paper. Such printers often have resolutions of about 150-450 dpi. Another technology is the laser printer, with resolutions from 300 dpi to over 1,000 dpi. All these wonderful technologies mean that printers must use more complex means to describe what goes onto the paper. Printer control codes just won't help when printing lines, graphics, images, or text in any font.
The solution for such printers is to do away with printer control codes completely, and use a page description language (or PDL). At first there were as many PDLs as there were printers. This was just as bad as when printer control codes were used: no two models of printers used the same control codes (or today, the same two PDLs). Today most of the early PDLs have gone the way of the dinosaur. (Except of course if you are the one stuck using such a printer!)
While there are two dominate PDLs today you still may have quite a number of older ones to deal with. The two main PDLs are PostScript, invented by Adobe (who is also famous for fonts and graphic applications such as Illustrator), and PCL (Page Control Language), invented by Hewlett Packard (who is also famous for their high quality printers). Working with printers with non-standard PDLs can be quite a pain, which is why smart people buy PostScript (or PCL) printers. (And even in this case, there may be different versions of the same PDL in use.)
Consider how a PDL such as PostScript works. PostScript (or PCL) is actually a general purpose computer programming language. A PostScript printer accepts print data as a PostScript program! The printer has a CPU and RAM, and in essence "runs" the PostScript program which produces the printed page. It is quite possible to generate PostScript using Notepad or vi or some other editor. Most Unix/Linux systems have the application ghostscript available, which allows you to view the results of PostScript on screen.
To see what PostScript looks like, search your computer for
files with the "
Those should be PostScript files.
Or you can view a short sample text file
(163 bytes) and the
It is worth mentioning two other PDLs in use: GDI and PPA. GDI is the graphics system used for Microsoft Windows, both screen and print (at different resolutions of course). A GDI printer is sometimes called a winprinter. Hewlett-Packard's PPA is similar. Such printers contain no CPU, RAM, or rendering engine, and thus are a lot cheaper then real printers. Your computer runs a print filter to convert the document to a big graphic (a bit-mapped image) that is then sent to the dumb printer, which prints the graphic. This can slow down your computer to a noticable degree, and results in large print jobs.
On the one hand we have a zillion applications. Each one that supports printing has its own document format. For example: MS Word format (several of those), text, RTF, GIF, PNG, JPEG, Spread Sheet formats (Excel, Lotus, Gnumeric, ...), and so on. On the other hand we have a zillion brands of printers. Each with a different set of printer control codes or PDL. This causes quite a problem: How is the document to be printed (which is in some application-specific format) translated to the PDL of the selected printer?
The answer is that a special program (or piece of one) is used. This code that performs this translation is called a print filter. However the term print driver is sometimes used instead, especially in the DOS or Windows systems. Also printer description is occasionally used, but these other terms can have different meanings as explained below.
One possibility is to have every application in the world have the code needed to translate its document format to every PDL used. Before you laugh, this is exactly how early DOS and Mac PC applications worked! For example, in the mid-1980s WordStar word processor was distributed on about 35 floppy disks: the first two or three held the program, the rest held various print filters. Even today some applications still print this way.
This is not a good solution!
For one thing if you purchased the application last year and
purchased a printer this year the odds are very low the
application will have the right print filter.
For another thing you may have many applications, so
switching to a different printer means upgrading every
Another problem is "command line printing" using a
print utility such as
lpr to print a
(Or GUI drop-n-drag
printing, using say a print icon on the desktop.)
These utilities would need a lot of print filters, or
some way to invoke the right application to use to filter
Another solution might be to have every printer manufactured with print filters for every possible document format. Needless to say this is unlikely to ever happen.
The only good solution is to have "standard" PDLs used in the middle. Applications would only need a single print filter to convert their data formats to some standard PDL format. Printers in turn can use the print data directly if the printer happens to support the standard PDL. If not the print server needs another print filter to convert the data in the print job from a standard PDL to the printer specific PDL.
PostScript is often used as the standard PDL.
For one thing may printers can use PostScript directly
so no additional filtering is needed once the print job
has been created and spooled.
For another PostScript is very flexible, so if some
effect is possible in another PDL it is most likely
possible in PostScript too.
On Unix/Linux, PostScript is a most desirable standard PDL
for another reason as well.
Printers that use custom PDLs can often accept a raw
graphic, due to the "dot matrix" nature of most printers.
A special type of print filter called a RIP
(Raster Image Processor) can convert or render
PostScript into a graphic format which can then be easily
printed on almost any printer.
ghostscript is used for a RIP on many
systems, especially Linux.
ghostscript includes RIP print filters for
many hundreds of printers.)
So an application uses a print filter to create PostScript,
and a RIP is used as the "back-end" print filter to
convert the Postscript print job into the printer-specific format.
Not every application can create PostScript print jobs.
So a given system may have to deal with two or more
nearly standard PDLs.
Many print filters are avaliable for this, just look for commands
with names like "xxx2ps".
Some examples on my Gnu/Linux system include
gif2ps, pdf2ps, scs2ps, tiff2ps, db2ps, fax2ps, h2ps, ps2ps,
Additional effects for translating text (or PostScript) into PostScript
are supported by other print filters such as
Finally you may not find the exact print filter needed.
Often you can use a chain of print filters; for example many
applications don't include print filters for PostScript
but instead have filters to produce PDF,
text, GIF, etc.
In turn there are other print filters to convert these to PostScript.
But even if some applications or printers require special setups and filters, having most applications use a standard PDL will certainly simplify printing and is a worth-while goal.
A print driver is sometimes used to refer to a print filter. However this term should be used to refer to the device driver a computer uses to communicate with a printer. The print driver might include some sort of print filter, but it must also be able to send commands to printers (to set options) and to return replies to queries (such as "out of paper?"). A print server (or perhaps an application) should be able to get the printer status, which options are in effect, which paper cartridge is loaded, the exact dimensions of the printable area (few printers can print all the way to the edge of the paper), etc. A print driver is used by the printer server for this communciations.
Once an application has selected a printer to use, it needs the description of the printer: the dimensions of the printable area, the printer resolution, and which options the printer supports. In the past this information came from the print driver or a "booklet" that the printer manufacturer supplied. A more modern technique is to have every printer use printer description files called PPD files (for PostScript Printer Description). The PPD files describe the capabilities of all printers, not just PostScript printers. There is one PPD file for each make and model of printer. PPD files for non-PostScript printers also define the additional filter(s) used to support those non-PostScript printer drivers. The idea is that applications can query the print server for printer details, and the print server in turn can use the PPD files to respond to the queries and to direct printing (such as any needed "back-end" print filter).
Once computer networks became popular it seemed natural to share access to printers. Any printer that is not attached to a port on your computer is considered a remote printer. (Of course your local printers might be someone else's remote printers.) Some printers are network printers, which means they don't appear to be anyone's local printer. That is such printers are attached directly to your network and not to any computer. So how to you print to a remote printer?
The initial solution to the problem of networks with multiple
remote printers was to install special network printing
software in each computer's operating system.
This fooled applications into thinking they were sending data
to be printed to some port on the computer
The OS would then collect the printer data sent to one of these
"virtual" ports across the network to a specific printer server,
which would accept the data and forward it out one of its
ports (where the printer really was).
But the application thought it was printing directly
to a local printer.
This solution isn't very elegant. But for older applications that are not designed to work with a print server, pretending that there is a local printer attached to some port is the only solution possible. One problem with this and similar solutions is that every computer must be configured individually for all remote printers. Adding, changing, or removing printers could be a nightmare. Using a print server doesn't help much, since each computer must run a local print server and it must know about all networked printers and have local configuration for each.
Another problem with remote printers is access. How can an administrator control who has access to which printers? How can accounting data (who has printed what) be collected? How can a user know which printers are available, what features each supports, and whether or not the printer is operational? How can a user check the status of a print job (or delete one) sent to a remote printer?
Accounting data can be very important. In some cases people (or their departments) are charged so much per page. In other cases an administrator must keep track of how many pages were printed per printer, so they can restock the printer before it runs out of paper, and to track and order printer supplies. (After so many pages, printers often require servicing such as new ink or toner, or new drums or just a cleaning.) Users need to be able to "browse" the network to find printers that meet their current requirements. Security can be a big concern to prevent users from using a color laser printer or banner printer for inappropriate purposes.
One way to support remote printing is to have network-aware print servers. Such print servers "listen" for arriving print jobs across a network. (TCP/IP port number 515 is often used for this but port number 631 will likely be used in the future.) Provided the network-aware print server is running and configured to accept remote print jobs then a local print server (or application) can submit the job across the network to that print server. (Provided no firewall blocks this access!)
The protocol used for remote printing depends entirely
on the remote print server.
The original AT&T Unix print server "
was not network-aware and thus didn't support remote
The BSD Unix print server
lpd did (and does),
and "lpd" became a standard protocol for remote printing.
Perhaps due to the name of the command line print utility
included, the name of this print system is "LPR" not
This early system didn't have the control and security
features demanded in the modern world, and a variation
known as "LPRng" ("LPR - the next generation") became a default
on many Unix and Linux systems.
(Even Windows servers come with support for accepting LPR print
jobs from clients.)
Although quite usable, LPRng still lacks many features desirable in a remote printing system. Each system must still be manually configured for each available printer. There is no way to browse or search the network for printers, or locate printer with specific features. To address these issues a new printing system is being used known as "CUPS" (Common Unix Print System). More information about CUPS can be found on their web site: www.cups.org. Versions of CUPS are available now, including commercial versions from Easy Software Products, who provide a lot of CUPS support and software to the open source community.
Microsoft servers use "SMB" protocol for sharing all remote resources including printers. Using "SMB" users can browse their network looking for shared printers. However only newer applications make use of this feature; most Windows applications still require all printers, local or remote, to be pre-configured on each system. (It is worth noting that both Windows servers and Unix/Linux servers can accept remote print jobs using both "lpd" and "SMB" protocols. Also Novell's Netware servers have "NDS" to allow clients to locate printers, and a protocol to submit print jobs remotely. No doubt other server types provide similar print services to clients.)
Some printers are not attached to any computer. Instead these printers are attached directly to a network. Such network printers can be dangerous if several applications send print jobs to them at the same time. The common way to deal with such printers is to have a single print server somewhere "control" that printer, and to enforce a rule that all print jobs for that printer must go the the designated print server rather than directly to the printer.
The most common way to use a network printer is to bundle one with its own print server. Hewlett Packard ("HP") is the market leader with their JetDirect print server. Many printers include a special socket for a JetDirect card. The card plugs into the printer and the network connects to the card. External versions of JetDirect print servers are available that connect to a printer via a very short cable. JetDirect and other brands of print servers can be quite tiny, little larger than a pack of cigarettes.
The bottom line is that remote printing shows a lot of promise for the future, but except for a few applications on some operating systems, remote printing is difficult to setup and requires considerable time and effort to manage.
When a user selects a "printer" to use, they really are selecting a queue. Sometimes the phrase printer destination is used, as is printer, but in any case it is a queue. Queue is an English word originally meaning "a waiting line of people or vehicles", so you might say "there is a big queue at the ATM machine". (Then again you might not.) Today queue also means a sequence of stored data (meaning print jobs in this case) awaiting processing.
After an application creates a print job which gets stored in a spool directory, the print server must somehow know which jobs are destined for which printers. To ensure fairness print jobs are usually printed in the order they are placed in the spool directory. To do these tasks each print job doesn't merely go into a central spool directory but also onto a specific queue. As more and more print jobs are created, the print server takes the next print job from the head of the queue when the printer is ready. In this way each print job gets sent to the printer in turn.
Typically there is a single queue for each printer, so there usually is no confusion in referring to a queue by the name of the printer. However it is possible to have multiple printers served by a single queue, or multiple queues for a single printer. Or a combination!
One example is a college's open lab with slow printers, it may make sense to use single name (the "printer") for a cluster of printers in one location, and output appears on first available printer in that group. (HCC did this in the DM-Tech open computer lab for many years.)
Originally the AT&T print system ("lpsched") called a queue with
many printers a printer class.
In reality each printer has it's own queue and the print server
takes jobs from the central class queue and moves them to the queue of
the first available printer in the class.
CUPS uses this term now too.
(The common Unix/Linux command line print utility
lpr has a option
-C class" that is used to control
an individual print job's priority.
Don't confuse this with a print class!
A print class is used exactly the same way as any other queue.)
Multiple queues for a single printer can be used to separate types of jobs that require operator intervention. For example a printer with removable printer trays of paper may have a tray for letterhead, legal, envelopes, invoice forms, or other special papers. Users direct print jobs to the "envelope" printer or the "letterhead" printer. (Of course they are really the "envelope queue" or the "letterhead" queue but it is fairly common to just refer to queues as printers.) The operator can disable printing from all queues except the one matching the loaded paper tray.
Some print systems support the idea of print job priorities. One way to control this is to define a high priority queue and a low priority queue. So someone printing a book or 5,000 copies of some flyer could use the low priority queue while others could use the high priority queue. You could setup a system this way and not tell anyone about the high priority queue, only use it yourself. That way all your print jobs come out ahead of others! (Besides being unprofessional, this is a good way to get fired.)
Queues can be implemented in several ways on different systems. The directory on the disk where print jobs are stored is called the spool directory. On some systems each queue is stored in an individual spool directory. (Netware and most Unix/Linux systems use this scheme.) As print jobs are created and stored in files, a sequence number is used as the filename (perhaps with additional information). Many systems use two files for each print job. One file holds just the print data and the other contains all the control information (which queue, the user, the priority, the selected printer options, etc.) The two files are related by their file name. On other systems a single spool directory is used and the name of the print job file contains information indicating which queue the print job is on and other information.
A printing system is a print server plus a collection of filters,
drivers, and fonts (or access to an independent font server),
plus some administration and user utilities.
(The user utilities include command line printing tools
that can use a limited set of filters to allow the user
to directly print text (or possibly GIF, HTML,
RTF, ...) documents.
There are several collections of filters and drivers (sometimes called printer definitions or descriptions) such as ASPfilter, MagicFilter, or foomatic. Some modern print servers allow the administrator to use different collections but most servers only allow a specific collection.
APSfilter is a filter collection for the LPR or LPRng
It can autodetect input file formats and translate PostScript, ASCII,
TeX DVI, PCL, GIF,
TIFF, HTML, PDF, and a number of bitmapped graphic
formats to PostScript.
It then uses
ghostscript to support non-PostScript printers.
APSfilter utilities setup the LPR
/etc/printcap file (the printer
capabilities database, which defines available printers for LPR/LPRng systems)
and create the print queue directories, including configuration data and correct
Magicfilter is similar and also is designed for LPR and LPRng systems only.
Foomatic is a print filter system designed to support all spooling
systems (including CUPS).
The main filter
foomatic-rip works like APSfilter to detect the input
format and to convert it to PostScript.
It then uses a collection of PPDs and printer drivers to make the final
translation for the actual printer driver (note
may be used as the printer driver).
Find and download PPDs for any printer at www.linuxprinting.org/printer_list.cgi.
Applications can query a print server to get printer attributes (dpi resolution, optional features supported, size of unprintable margins, etc.) for the selected printer, use this information for wysiwyg layout, construct a print job (data plus printer features selected (number of copies, econo-mode, 2-up, ...), destination, username, etc.) and pass it to the print server. The printer data is created from the applications document formation using a print filter to a standard PDL, usually PostScript or text.
The server notes the print job (and possibly constructs a print job control file from the meta-info), decides whether or not to accept a print job from this user for that destination, and puts it in a spool directory. Later the server notes the printer is ready for this print job, uses the print driver to set up the printer for the desired options and features, then passes the data to the print driver. The driver may filter the data to the prints PDL if it is not the same PDL as the data.
Not all applications filter their documents to create print jobs. Not all applications can query a print server for printer information. (Often such systems rely on the user knowning the proper print destination names.) Not all applications use a system standard print system for their fonts or printer descriptions (an example is OpenOffice). Not all applications can use a networked print service directly. Systems with such applications still need to have a local configuration for each available printer. In such cases, it is not uncommon for the local print system to accept and spool a print job, then send it across a network to another print server, where the print job enters another queue.
Not all print systems use a standard PDL for spooled print jobs.
Sometimes an application will have several filters and pick the right one for
the selected printer.
ghostscript has many hundreds of such filters
to convert postscript to different PDLs.
If the printer driver for some printer can't convert PostScript
to it's PDL the print server can use
as a filter when passing a spooled job to some
particular printer driver.
Not all print systems filter the jobs the same way.
Some might filter print jobs as they enter a print queue (so the
job is ready to be sent to the printer) but some might only use
the "backend" print filter when the printer is ready for that print
Applications may or may not be able to work with multiple printing
systems, but usually not.
Many applications are designed to construct a
command line from the user choices in a GUI print dialog.
Such applications never know about special printer capabilities
or options, they can only use standard
line arguments to control a print job.
However, since "
lpr" is the name of the command line print
utility used by many print systems, such applications can use
any print system installed.
Users and administrators can use utilities to locate printers, check the status of printers, queues, and their print jobs. Also they can delete print jobs from a queue, or sometimes delay its printing or change the priority of a print job. Exactly what utilities are available depends upon which print system is running.
Install and update software/drivers/filters/fonts. Maintain printers, keep paper, toner and ink supplies, clean, inspect, replace parts or whole printer when needed. Track usage (accounting). Make network printers available (firewalls).
Setup queues/classes, server configuration, printers, access controls. Name printers well. Monitor printers for problems (especially remote printers). Enable/disable queues/classes (printer destinations) and printers. Manage print queues (delete/delay/move print jobs).
LP Print System — derived from the original AT&T system, LP doesn't support remote printers. All modern systems have grafted on some other system to support this. (Used on Solaris, HPUX.)
LPR Print System — LPR derived from the BSD print system,
and is still widely supported on Unix, Linux, and even Windows NT.
Access control is provided by two means.
First, all requests must come from one of the machines listed in the file
Second, if the "
rs" capability is specified in the
/etc/printcap entry for the printer being accessed,
lpr requests will only be honored for those users with accounts on
the machine with the printer.
LPRng Print System — LPRng is a re-worked LPR from the ground up, with new configuration and access control files): /etc/lpd.conf - LPRng configuration file, /etc/lpd.perms - LPRng printer permissions, /var/spool/printer* - spool directories and printer-specific printcap info (or .../lpd/* can be used).
(Discuss Samba/SMB share names: use forward- (or doubled back-) slashes.)
CUPS Print system — Common Unix Printing System is fairly new (See www.cups.org). CUPS uses the Internet Printing Protocol ("IPP") as the basis for managing print jobs and queues. The Line Printer Daemon ("LPD"), Server Message Block ("SMB"), and AppSocket (a.k.a. JetDirect) protocols are also supported with reduced functionality. CUPS adds network printer browsing and PostScript Printer Description ("PPD") based printing options to support real-world printing under UNIX.
|Description||AT&T (lp)||BSD LPRng (lpr)||Solaris||CUPS|
|Printer daemon||lpsched, lpshut||lpd||lpsched, lpshut||cupsd|
|Disable printer||disable||lpc||lpset/lpc, disable||disable (cupsdisable)|
|accept||lpc||lpset/lpc, accept||accept (cupsaccept)|
enableas an internal command, so you must use a pathname to run this command. For this reason newer versions of cups have renamed this to
(and similarly for related commands). Back
All the information in this page came from other sources, so the blame for any errors rests with them not me! Sources used: (list URLs, books)