3. Printer Capabilities, Configurations, and Printcaps

One of the major difficulties with printer software is dealing with the wide range of different printer hardware configurations and printer connections. This section outlines the printer communication methods, the types of print job languages, and the effects of these on printing software and the ifhp filter.

3.1 Printer Configurations

A printer consists of a hardware print engine which marks the output page and delivers it, a set of control hardware that takes a print job in a well defined format and operates the hardware to produce output according to information in the print job, and a communication channel from the computer to the control hardware. The control hardware is sometimes called a print engine. In most modern computers the control hardware may consist of multiple microprocessors, each with their own firmware, and each performing a specific printing task. For example, one may control the paper feed path, one may do rasterization, and one handle communications with the outside world.

In order to set up printing correctly, it is necessary to know the following information about your printer.

1. The capabilities of the hardware. This is dependent on the model of printer, and may be such things as the page feed, output and input tray selection, numbers of columns and/or rows of output available on the output device. This information is readily available from most manufacturers.
2. The print job language recognized by the control hardware. This is the special set of codes, commands, and formats recognized by the control hardware.
3. The protocol used to send jobs to the printer and obtain status about the printing activity.

Usually the capabilities of a modern printer are very well known and documented, and the ifhp filter and most print spooling software has little difficulty working with them.

The following checklist will help you in setting up your printer. The various options that you will need to know about are indicated where appropriate.

1. Printer Model (model=???)
   What is the exact printer model? Check the serial number or other identification to get this information. You should check the ifhp.conf configuration file to see if your printer is already supported.
2. Print Languages Supported By Your Printer
   1. PJL? (pjl or pjl@)
      The Printer Job Language (PJL) is a high level language supported by many Hewlett-Packard printers that allows some print system configuration to be performed. Due to historical developments, not all printers support all PJL language facilities, and some support them in different ways than other printers. The ifhp filter can use the PJL support for a printer if it is available.
   2. PostScript (and what version)? (ps or ps@)
      PostScript is the most common print job language in use. If your printer supports PostScript, then you will have a relatively trouble free time with it. One problem is that it requires a fairly substantial amount of memory and computational support, and is usually not found on the low end (less than $500) printers.
   3. PCL? (pcl or pcl@)
      PCL is another Print Language supported by many vendors, including Hewlett-Packard, Lexmark, and others. It is essentially text with escape sequences to tell the print engine to place markings on a page at specific places in a specific font. It is the second most common format used with modern printers.
   4. Text? (text or text@)
      Text is really just PCL without any control sequences. However, it is easy to have ifhp convert ordinary text into PCL by prefixing the appropriate PCL control codes. You may also need to use the crlf option to force CR to CR-LF translation. If you have a simple text printer then you may want to use the much easier to configure lpf filter from the LPRng distribution ( http://www.astart.com/LPRng.html).
   5. Vendor Specific
      There is a growing trend to have very proprietary Print Languages for very low end (less than $300) printers. These printers usually require all of their jobs to be preformated by software running on the host and to have the job delivered to them in a specific manner. If you have one of these printers, you will need to get a rasterizing program that produces the correct format. Check to see if GhostScript, supports your printer. If it does then you can use GhostScript to translate PostScript to your printer's required format.
3. Memory Size.
   If you are going to be sending large print jobs or ones with a large amount of graphics to the printer, you will need a substantial amount of memory to deal with rasterization. Most high resolution Laser Copier based printers require a minimum of 16 megabytes for adequate performance, and if you are printing complex PostScript or PDF documents you may want at least 32 megabytes. Color printers require substantially more and 64 megabytes is not uncommon.
4. Communications. The connection between your printer and the host computer.
   1. Network Connection
      This is the most reliable and high speed way to connect a printer to a system. This is especially true if a printer must be accessible to multiple users and is located at a distance from the user.
   2. Parallel Port (status@)
      Note that this is a unidirectional communications channel and there is little to no support for bidirectional communications. While there are drivers available for bidirectional communication with various printers, these are usually limited in capability and have a severe impact on system performance.
   3. Serial Ports
      This is the very worst way to communicate at high speed with a printer. Serial ports usually have a high error rate, suffer from data overruns, and have a severe impact on system performance. You will need to configure your printer speed, format (bits per character, parity, stop bit), and flow control method, and then do the same for the host. This can be an endless source of frustration for the novice user.
   4. Print Server Box
      Many older printers do not directly support a network connection and have an external print server box attached to either their serial or parallel ports. If you have the printer connected to a parallel port, then you will still most likely only have unidirectional communication and no status information will be available from the printer.

3.2 Network Communication Protocols

The most high speed and reliable connection to your printer is using a network connection. The following protocols are usually used to communicate with a network printer: RFC1179 (TCP/IP printing), Socket Protocol (TCP/IP), AppSocket Protocol (TCP/IP), Novell Print Protocol (IPX), SMB Print Protocol (TCP/IP), and AppleTalk Print Protocol (TCP/IP).

It is highly recommended that you use TCP/IP networking to communications to talk to your printer, and that you do not enable any other protocol on your printer. If you have two different systems trying to connect to the same printer using different protocols, a wide range of vendor's hardware will lock up and may require a power up reset to recover. Documented evidence for this behavior includes a wide range of printers, including those from Hewlett-Packard, LexMark, IBM and other vendors.

Only the TCP/IP based network job transfer protocols are discussed in this document. For details on using other protocols, please consult the consult the LPRng documentation.

3.3 RFC1179 (BSD or TCP/IP) Job Transfer Printcap Entry

RFC1179 is used to transfer print jobs between a client (user) and a print spooler, or between two print spoolers. Jobs are transferred as a set of files, and the only information exchanged during the transfer process is the success or failure of the transfer. In order to get status about the actual job printing, a separate query status (lpq) is sent to the print spooler.

Many, if not all, printers with a network interface that supports the TCP/IP protocol support the RFC1179 protocol for job transfer. However, their support for print job status is usually minimal to non-existent. If you want to send a job to a printer using the RFC1179 protocol, please be aware of the following problems.

Normally a print spooler (System 5 lp, BSD lpd, LPRng) does not modify a print job when forwarding it to another print spooler. This means that your print job will normally pass from the originating lp or lpr program to the destination printer with no changes. This can have disastrous results if the job requires filter processing.

If you are using the LPRng print spooler, job transfers using RFC1179 is specified by using :lp=spoolqueue@host or :rp=spoolqueue:rh=host printcap entries. For example:

raw:
  :lp=raw@host
  :sh:sf:mx=0
  :sd=/var/spool/lp
cooked:
  :rp=cooked:rm=host
  :sh:sf:mx=0
  :sd=/var/spool/lp

Please note that no filters specified as the job is not modified, only transferred from one server to another. Even if filters were specified they would be ignored. The lpd_bounce flag causes the LPRng spooler to pass the print job through the specified filter and then send the filter output to the actual network printer. The lpd print spooler will open a temporary file for to hold the filter output, and then proceed to start the specified filter with its STDOUT attached to the temporary file, its STDIN attached to the file to be processed, and its STDERR redirected to an error log. The single resulting file is then transferred to the destination system using the RFC1179 protocol.

When a job is created the job format is specified (default is f), and a filter named by the :i>format option is selected for use. For example:

raw:
  :lpd_bounce
  :lp=raw@host
  :sh:sf:mx=0
  :sd=/var/spool/lp
  :ifhp=model=XXX,status@
  # for 'f' format
  :if=/usr/local/libexec/filters/ifhp
cooked:
  :lpd_bounce
  :rp=cooked:rm=host
  :sh:sf:mx=0
  :sd=/var/spool/lp
  :ifhp=model=XXX,status@
  # for 'f' format
  :if=/usr/local/libexec/filters/ifhp

Unfortunately, some print spooling systems also use the v format by default. You may find the following printcap entry useful in this case. The :filter option specifies a default filter that is used if one is not specified for the format.

raw:
  :lpd_bounce
  :lp=raw@host
  :sh:sf:mx=0
  :sd=/var/spool/lp
  :ifhp=model=XXX,status@
  # for 'f' format
  :filter=/usr/local/libexec/filters/ifhp

The lpr -l or lpr -b flag is used to specify that a job has the special binary flag. In this case, most filters will perform only the most perfunctory processing and pass the job directly to the printer.

3.4 Socket Protocol (TCP/IP) Operation Printcap Entry

Many printers with a network interface provide a TCP/IP port that is a direct connection to the internal print engine. If a TCP/IP connection is made to this port and a file is sent over this connection, then the print engine will process the file. More importantly, the connection is bidirectional, and the printer will report errors and status conditions over the connection. PJL and PostScript status request commands can be sent to the printer and the printer will respond with information.

The ifhp filter makes extensive use of this protocol, and provides support for status and error reporting. In cooperation with the LPRng print spooler, it will provide a detailed description of the actual print job progress and any error conditions that arise.

To use a Socket connection with LPRng, you use the :lp=host%port printcap entry shown below. The lpd print spooler will open a connection to the TCP/IP port on host and passes the (bidirectional) connection to the ifhp filter on file descriptor 1 (STDOUT) and the file to be printed on file descriptor 0 (STDIN). Errors and status information are reported by the ifhp filter on file descriptor 2 (STDOUT) and placed in the error status log by the lpd print spooler.

The connection made by the lpd server to the printer is persistent over the entire job; all file transfers for the same job are made over the same connection. This is important as it prevents other printer users from hijacking the printer in the middle of print a job and getting your job outputs mixed together.

The following is a typical printcap entry using the socket protocol.

raw:
  :lp=host%9100
  :sh:sf:mx=0
  :sd=/var/spool/lp
  :if=/usr/local/libexec/filters/ifhp

3.5 Appsocket Protocol (TCP/IP) Operation Printcap Entry

The Tektronics Phaser Series printers and QMS printers use the Appsocket protocol when sending a job to the printer. This protocol uses two ports: a TCP/IP listening port which accepts TCP/IP connections and a UDP query port that is used to obtain status information. Unfortunately, the UDP port is almost totally useless for job monitoring and status purposes and is not used except in an advisory role.

The Appsocket protocol is (briefly):

1. When a UDP packet is received on the UDP port a reply packet containing the status is returned to the originator's address. This packet contains an status indication in a undefined format but usually is readable or has a clearly defined format.
2. To send a job to the printer, a TCP/IP connection is opened to the TCP/IP port and a PostScript job is sent. Only a single job can be sent at a time - a EOJ in the job, i.e.- CTRL-D for PostScript or ESC E for PCL will cause the printer to terminate reading from the TCP/IP port, and after job processing has finished, to close the TCP/IP connection. All input after the EOJ may be ignored by the printer and not processed.
3. While processing the job, if bidirectional support is available and has been enabled the printer will return job status or information until all of the print job which is has received has been processed. This support is usually not enabled by default and must be enabled by using a specialized administration interface or configuration tool.
4. Unfortunately, some printers will also close the connection when the EOJ has been received. These printers are virtually useless when trying to get error or status information about a job.
5. While processing the job, the printer will ignore any connection requests, and only until the job has been processed will the printer accept connections.
6. During job processing, status and error indications can be obtained by sending a query to the UDP port. However, the error conditions and other information are not very precise as the status may change dramatically during job processing.

The Appsocket protocol does not use a persistent connection. If two people are sending jobs to the printer simultaneously it is very likely that the jobs will get intermixed.

The appsocket option causes the ifhp filter to open and close a TCP/IP connections to the printer. Since it is handling connections, you should specify :lp=/dev/null in the printcap to trick the lpd server into allowing the ifhp filter to make the connections. The following is a sample printcap entry for this printer:

# Phaser Setup # no status reporting - write only to the printer lp:server
  :lp=/dev/null
  :sd=spooldir
  :...
  :ifhp=model=ps,appsocket,status@,dev=10.0.0.1%9100
  #path to ifhp filter
  :if=/.../ifhp


# Phaser Setup # bidirectional connection, status reporting lp:server
  :lp=/dev/null
  :sd=spooldir
  :...
  :ifhp=model=ps,appsocket,dev=10.0.0.1%9100
  #path to ifhp filter
  :if=/.../ifhp


The lp=/dev/null/ is necessary to force the lpd print server to open a connection to a dummy device. This is passed to the ifhp filter on file descriptor 1. The appsocket option causes the filter to ignore this connection and to open a connection directly to dev=10.0.0.1%9100, that is, port 9100 on IP address 10.0.0.1. This address can also be a DNS host entry. The status@ tells it not to expect any status back from the printer.

For your convenience, the model=tek entry is suitable for use with the appsocket protocol.

3.6 Common Print Server Boxes Configuration Information

The following is a list of print server manufacturers, models, and with hints on how to access these boxes with various protocols.

All company, brand, and product names are properties of their respective owners.

3.7 IFHP Filter and Timeout Problems

As described later in this document, the ifhp filter may need to run a program such as ghostscript to do format conversion. For large files this can take quite a bit of time. Most printers have a connection timeout and if the printer is idle and no data is received for this time the printer will close the connection. By default this timeout is fairly short: 30 or 90 seconds on most printers.

If you are sending large jobs to the printer using the socket protocol and are getting timeout problems due to conversion timeouts, then there are two solutions: a) use the Appsocket protocol, which will open and close the connection for each file, and only when the converted file is available, or b) do your conversions first and then spooling the converted job to be sent directly to the printer.

# Method a) Appsocket
lp:server
  :lp=/dev/null
  :sd=spooldir
  :...
  :ifhp=model=printer,dev=10.0.0.1%9100,appsocket
  #path to ifhp filter
  :if=/.../ifhp

# Method b) Bounce Queue
# this queue does the conversion if required
lp:server:lpd_bounce
  :lp=real@localhost
  :sd=spooldir
  :...
  :ifhp=model=printer
  #path to ifhp filter
  :if=/.../ifhp

# this queue does to transmission using the socket protocol
raw:server
  :lp=/dev/null
  :ifhp=model=printer,dev=10.0.0.1%9100
  :sd=spooldir
  :...
  #path to ifhp filter
  :if=/.../ifhp


For method a), the Appsocket protocol is used and the ifhp filter will be invoked before sending a job. For method b), you use two queues: a bounce queue that does the format conversion and then sends the job to the real queue, and the real queue that actually talks to the printer.

3.8 PS, PCL, PJL Printer with TPC/IP Network Interface

The most common TCP/IP protocols used for transferring jobs to network printers are RFC 1179, a direct TCP/IP socket, connection to the print engine, and the very odd Appsocket protocol described in previous sections. Here is a reprise of the various printcaps and methods to use them.

# printer setup
# force clients (lpr, lpq, to use server)
lp:lp=lp@serverhost
# server information
lp:server
  :sd=spooldir
  :...

  # No filtering, transfer using RFC1179   :lp=queue@10.1.1.1
  # or
  :rp=queue:rm=10.1.1.1

  # Filtering and then transfer using RFC1179   :lpd_bounce:lp=queue@10.1.1.1
  # or
  :lpd_bounce:rp=queue:rm=10.1.1.1
  :ifhp=model=name
  :if=/.../ifhp

  # Filter, transfer using socket   :lp=10.1.1.1%9100
  :ifhp=model=name
  :if=/.../ifhp

  # Filter, transfer using Appsocket   :lp=/dev/null
  :ifhp=model=name,appsocket,dev=10.1.1.1%9100
  :if=/.../ifhp


If your printer is a parallel port printer connected to an external Network Print Spooler such as an HP JetDirect box, then while the network connection to the Network Print Spooler is bidirectional the connection from the Network Print Spooler to the printer may be unidirectional and no status information will be returned from the Network Print Spooler. In this case you must add the status@ option to tell ifhp not to expect status:

  # Filter, transfer using socket   :lp=10.1.1.1%9100
  :ifhp=model=name,status@
  :if=/.../ifhp

  # Filter, transfer using Appsocket   :lp=/dev/null
  :ifhp=model=name,appsocket,status@,dev=10.1.1.1%9100
  :if=/.../ifhp


3.9 PS, PCL, PJL Printer with Parallel Port Connection

Even if your printer is connected to a parallel port and parallel port is bidirectional you may still not reliably read status from the printer. Use the status@ option to prevent the ifhp filter from expecting status, and do not use the :rw (open connection read-write) option:

# printer setup
# force clients (lpr, lpq, to use server)
lp:lp=lp@serverhost
# server information
lp:server
  # no :rw option!
  :sd=spooldir
  :...
  # parallel port
  :lp=/dev/lpt
  :ifhp=status@
  #path to ifhp filter
  :if=/.../ifhp


3.10 PS, PCL, PJL Printer with Serial Port

It is strongly advised that serial ports not be used for high speed data transfers. The main problem is trying to configure them in such as way that they do not lose characters due to data overruns or parity errors. LPRng is strongly deprecating support for serial port printers.

The LPRng print spooler will open and set the serial line characteristics, and pass the open connection to the ifhp filter. The tty connection must pass all 8 bits with no parity, and should use hardware flow control if at all possible. Unfortunately, the various stty options needed to do this vary from system to system. Also, you may discover that your serial connection does not support hardware flow control. If this is the case, then you will have to use software flow control which is rather unreliable for high speed (over 9600) serial lines due to the timing latencies involved.

# printer setup
# force clients (lpr, lpq, to use server)
lp:lp=lp@serverhost
# server information
lp:server
  :sd=spooldir
  :...
  # serial port
  :lp=/dev/ttyxxx
  :stty=38400 -echo -crmod -raw -oddp -evenp \
   ixon pass8 -ixany cbreak crtscts
  #path to ifhp filter
  :if=/.../ifhp


3.11 PostScript Only Printer

Use the configuration appropriate to the printer connection, and then specify model=ps.

# printer setup
# force clients (lpr, lpq, to use server)
lp:lp=lp@serverhost
# server information
lp:server
  :sd=spooldir
  :...
  :ifhp=model=ps
  #path to ifhp filter
  :if=/.../ifhp


If you have a parallel port printer with no PostScript support, you would use:

:ifhp=model=ps,status@

If your printer does not like PostScript EOJ (Control-D) flags at the start of a job, use the no_ps_eoj (No PS EOJ at Start) flag to cause ifhp to remove them. Similarly, the no_pcl_eoj (No PCL EOJ at Start) flag will remove the PCL EOJ (Esc E) command string from the start of a PCL job file.

:ifhp=model=ps,no_ps_eoj

3.12 PostScript Only Printer Text Conversion

If ifhp.conf can be configured to invoke a text to PostScript converter. See the section on File Conversion Support.

3.13 GhostScript and ifhp

Generating a raster image from a PostScript or PCL file in a timely manner requires a high speed processor and substantial amounts of memory. Many of the low cost printers require the user's system to do the raster conversion, and a raster file is then transferred to the printer. These files are usually in a proprietary format.

The GhostScript program can process PostScript files and produce raster output for a wide range of devices. See the GhostScript documentation for details. The ghostscript printer configuration is intended to be used with these printers. See Using GhostScript with ifhp for details.

3.14 Tektronics Phaser, QMS, and Appsocket Protocol

The Tektronics Phaser, QMS Network Printers, and a few others use the Appsocket protocol described in a previous section. The Tektronics (model=tek) configuration entry has the required options for these printers:

[ tek qms ]
appsocket
ps
pjl@
pcl

The following shows a typical printcap entry:

# force clients (lpr, lpq, to use server)
lp:lp=lp@serverhost
# server information
lp:server
  :sd=spooldir
  :lp=/dev/null
  :...
  :ifhp=model=tek,dev=10.1.1.1%35
  #path to ifhp filter
  :if=/.../ifhp