The printer subsystem includes a spooler, real printers, virtual printers, backends, and queues. A print job can be sent to a printer attached directly to a local system, or it can be sent over a network to a remote system and printed on a printer attached to the remote system.
The system management tasks associated with printers include:
The system sends codes to the printer when you print a file. Some codes print specific characters, such as a to z or 0 to 9. Other codes print characters or files, such as underscoring certain characteristics or by adjusting the page length. Edit the file if you want to send different character codes to the printer, such as to change the word that to this. You do not have to understand the underlying codes.
To alter the way a printer works, you must understand what happens when you print a file, which options you have for sending control information to the printer, and which printer characteristics you can control.
You can use Web-based System Manager (type wsm, then select Printers), the System Manager Interface Tool (SMIT), or the qprt command to send a file to a printer. You can also use Web-based System Manager or SMIT to cancel or prioritize a print job.
A file does not go directly to the printer. Web-based System Manager, SMIT, or the qprt command calls the enq command and places the print request in a queue. The print request stays in the queue until a printer becomes available, at which point the qdaemon command runs the (printer input/output backend) piobe command. The piobe command processes the file and sends it, along with control information, to the printer. The printer receives a data stream containing the contents of the file and the control information specified with the qprt command.
Add printer control information to the printer data stream in the following ways:
Note: Set the print queue data stream to passthru (that is, d=p). Refer to Printer Colon File Conventions for more information.
Include all printer control information that is unique to that file. For example, to underscore the title of a book or print a paragraph in bold type, insert codes that start and stop the printer control information at the correct places.
Some application programs, such as word processors, allow you to insert specific printer controls in the file. However, if the printer cannot be configured from the application program, you must use a system editor to insert printer control codes. Printer control codes are available with the printer, from the dealer where the printer was purchased, or from the printer manufacturer.
You can specify particular print characteristics for a single print job. For example, the qprt command flag for setting pitch is -p Number, where Number is the number of characters per inch. If the standard qprt command setting is 10 characters per inch, but you need 12 characters per inch for the printtest file, enter the command:
qprt -p 12 printtest
The flag on the command line overrides the standard qprt command setting for this job. The standard qprt command pitch setting remains 10.
Web-based System Manager (type wsm, then select Printers) allows you to change or show the print queue characteristics of a printer. You can also use SMIT or the lsvirprt command.
Note: You must have root authority or be a member of the printq group.
For example, to change the standard pitch to 12 characters per inch, run Web-based System Manager (type wsm, then select Devices.), the chvirprt command, or SMIT. Select the printer from the list displayed and enter the attribute name and value, separated by the equal sign ( = ).
The attribute names for the qprt command flags are the flag letters. You can change the standard pitch to 12 by specifying p=12.
The spooler is not specifically a print job spooler but a generic spooling function that can be used for queuing various types of jobs, including print jobs queued to a printer.
The spooler does not know what type of job it is queuing. When the system administrator defines a spooler queue, the purpose of the queue is defined by the spooler backend program. For example, if the spooler backend program is the piobe command (the printer I/O backend), the queue is a print queue. Likewise, if the spooler backend program is a compiler, the queue is for compiler jobs. When the spooler's qdaemon command selects a job from a spooler queue, it runs the job by invoking the backend program.
When networks are composed of base operating system machines and other types of clients and servers, not all remote print requests are supported across the network. In some instances, you may have to submit print jobs one file at a time or concatenate files before submitting them as a print job.
The main spooler command is the enq command. Although you can invoke this command directly to queue a print job, three front-end commands are defined for submitting a print job: the lp, lpr, and qprt commands. A print request issued by one of these commands is passed to the enq program that places the information about the file in the queue for the qdaemon to process. The queue is the /var/spool/lpd/qdir directory.
If the job is not a file (that is, pipe output of a command to enq), a real file is created in /var/spool/qdaemon that contains the data to be printed. The information in the /var/spool/lpd/qdir file points to the file in /var/spool/qdaemon.
A real printer is the printer hardware attached to a serial or parallel port at a unique hardware-device address. The printer device driver in the kernel communicates with the printer hardware and provides an interface between the printer hardware and a virtual printer. A real printer can be added with Web-based System Manager (type wsm, then select Printers) or using the mkdev command at the command line.
A virtual printer is a set of attributes that defines a high-level data stream (such as ASCII or PostScript) that the printer understands. This does not include information about how the printer hardware is attached to the host computer or about the protocol used for transferring bytes of data to and from the printer.
A virtual printer is associated with a print queue. You can define a print queue for each data stream the printer supports. Multiple print queues can use the same real printer.
When you submit a print job, a print queue must be directly or indirectly specified. To specify a specific printer for a print job, add a colon and the printer device name to the print queue name. If a printer is not specified for the print job, the spooler selects the first available printer associated with the print queue. If there are several printers associated with a print queue, any printer is used.
IBM Proprinters, for example, need only one print queue to be defined for each real printer. This is because Proprinters support only one data stream, IBM extended ASCII. The IBM 4216 Model 031 Personal Pageprinter needs multiple print queues defined. A print queue can be defined for each data stream the printer supports. A print queue can be defined for PostScript, Proprinter, HP LaserJet, and Diablo 630 emulations. All four print queues output to the same real printer, the 4216 Model 031.
A local printer is the printer attached to a node or host. A remote printer allows nodes that are not directly linked to a printer to have printer access.
To use remote printing facilities, the individual nodes must be connected to a network using the Transmission Control Protocol/Internet Protocol (TCP/IP) and must support the required TCP/IP applications. The lpd daemon controls the remote print server and any host on a network can be designated as a print server. Before a remote server can accept a print request, the /etc/hosts.lpd or /etc/hosts.equiv file must be configured to accept print requests from other nodes or hosts. Use Web-based System Manager (type wsm, then select Printers) or SMIT Manage Print Server option to configure a print server.
The printer backend is a collection of programs started by the spooler's qdaemon command to manage a print job that is queued for printing. The printer backend performs the following functions:
The mkvirprt command defines a virtual printer to the printer backend. The set of predefined attributes for the particular type of printer is copied to create a customized set of attributes. The customized attributes can be listed with the lsvirprt command and changed with the chvirprt command or, by using the Web-based System Manager (type wsm, then select Devices), or SMIT Change / Show Print Queue Characteristics option. Each time the mkvirprt or chvirprt command is used, a digest utility (piodigest command) is automatically run to construct a memory image of the attribute values and lookup tables to be read in and used during the printing process.
The qdaemon command calls the piobe command (the Print Job Manager) and passes the flag options and the names of one or more files to be printed. The only flag options not passed are the spooler flag options removed by the enq command. The qdaemon command has already opened the printer device and redirected standard output to the printer. A status file provides communication between the qdaemon and the backend.
If a header page is needed, the piobe command retrieves a header page pipeline used to generate the header page. The header page pipeline is passed to a shell. In the pipeline, the standard output from the header page filter becomes the standard input for the formatter filter. The formatter filter processes the header page and writes the result to standard output. Standard output for the formatter filter becomes standard input for the device driver interface program that writes the filtered header page to the printer device driver.
A formatter filter provides the capability of either formatting the input print file or passing it through unmodified, based on an input parameter. Even if the formatter passes the input file unmodified, it still sends printer commands to initialize the printer before the input file is printed and restores the printer after printing is complete.
A formatter driver is device independent. There is a formatter for each type (or group of types) of input data. For example, there is one formatter for all the supported Proprinters.
The formatter filter is made up of two components:
The formatter driver is invoked by a pipeline and is passed the name of a formatter to be driven. The formatter driver dynamically loads and links the formatter and calls the formatter's setup function which indicates whether data formatting or data pass-through is requested. After the formatter's setup function performs the necessary functions, it returns to the formatter driver. The formatter driver calls the initialize function. The initialize function outputs a string of printer commands to initialize the printer and returns to the formatter driver.
The formatter driver either calls the passthru function once or calls the lineout function for each line in the print file based on the return code from the setup function. If the lineout function is called, the formatter driver performs all vertical spacing, including line spacing, vertical tabs, form feeds, and top and bottom margins. Line spacing and vertical tabs are performed by the lineout function. Other vertical spacing functions are performed automatically.
When processing is complete, the formatter driver calls the restore function. The restore function outputs a string of printer commands to restore the printer to its default state, defined by the database attribute values.
For more information about how the print formatter interacts with the printer formatter subroutines, refer to the Example of Print Formatter .
|Printer/Plotter Device||A special file in the /dev directory for the device. This file can be used by redirection (for example, cat FileName > /dev/lp0). Settings for the device driver can be displayed and changed using Web-based System Manager (type wsm, then select Devices) or the lsdev and chdev commands. Before printer commands can access a printer device, a print queue must be created for the device or the printer must be configured in the printer backend in /etc/qconfig.|
|Virtual Printer||A combination of a specific queue and a specific queue device in the
/etc/qconfig file. There is an associated file in the
/var/spool/lpd/pio/@local/ddi directory that contains formatting
data. When you use SMIT to add a printer, the system automatically
creates the virtual printer's queue, queue device, and
Use Web-based System Manager (type wsm, then select Devices) to create a queue and queue device for a printer, using the standard piobe backend. If you want to implement load sharing, use to add a second queue device to an existing queue. You can also use the SMIT commands.
|Queue||A line or list of items in the /etc/qconfig file where the
name of the queue manually points to the associated queue device. The
following is a sample listing:
lp0: device = lp0
Normally, queues are created through Web-based System Manager.
|Queue Device||The queue device is the line or list of items in the
/etc/qconfig file that normally follows the local queue. It
specifies the /dev file (printer device) to print to and the
backend to use. Following is a sample listing:
lp0: file = /dev/lp0 header = never trailer = never access = both backend = /usr/lib/lpd/piobe
There can be more than one queue device associated with a single queue.
Adding a printer through Web-based System Manager (type wsm, then select Devices) creates a standard queue device entry to an existing queue.
Note: There will not be a file entry in the /etc/qconfig file when you are using a remote printer. The queue directs the file to the server.
|The qdaemon is a process that runs in the background.
When you turn the system on, the startsrc
command starts the qdaemon. startsrc is a command
to the srcmstr daemon that is started from
The qdaemon keeps track of the print requests in the /var/spool/lpd/qdir directory and ensures that the jobs are sent to the proper printer at the proper time. It also keeps track of the status of the printers and stores printer usage data for system accounting purposes (for example, lpstat and enq -A commands). This information is held in the /var/spool/lpd/stat directory.
If the qdaemon is stopped, it will be restarted by the srcmstr.
Note: Do not stop the srcmstr process; it controls other daemons running on your system.