Printing details and troubleshooting

This file provides more detailed information about setting up printing with the hpoj software, including possible troubleshooting steps in case something goes wrong.

Additional information may be found in the separate document pertaining to ptal-printd.

Also, be sure to consult the connectivity details and troubleshooting document, because some issues here may actually be connectivity-related.

General issues

Question: What is the difference between all these "drivers" on my system (hpoj, hpijs, ghostscript, CUPS, GIMP-Print, etc.)?

hpoj at the lowest level (libptal and ptal-mlcd) merely provides data pipes to the different functions on a multi-function peripheral. Although hpoj also provides drivers for scanning and photo-card access, it relies completely on other software to serve the roles of a print spooler (such as lpd or CUPS, to accept and queue print jobs from applications) and a print driver (to convert the device-independent PostScript or raster image data from applications to a device-dependent page description language such as HP PCL or LIDIL, if the device doesn't provide native PostScript support).

The combination of ghostscript, hpijs, and various "filter" scripts to glue them into your system's print spooler and overall print pipeline, is the recommended print-driver solution for converting PostScript to PCL for most HP printers. However, some applications, such as GIMP, are able to bypass the intermediate PostScript step by providing their own set of print drivers, such as GIMP-Print, which are separate from ghostscript and hpijs and may result in less-optimal print quality.

Question: Why didn't you provide specific instructions for my distribution, print spooler, printer-setup tool, or application?

Due to the wide variety of printing solutions (spoolers, print drivers, setup tools, etc.) available for Unix-like operating systems, this documentation cannot possibly provide information specific to each one. Instead, it presents the general procedure for setting up printing and emphasizes what you need to do differently (compared to the "traditional" case of a single-function printer) so that printing co-exists properly with other hpoj functions such as scanning or photo-card access. For more specific instructions, also consult your distribution's printing-setup documentation and/or the Linux Printing HOWTO.

Question: How do I print a PostScript or PDF file from the command line?

Issue a command such as "lpr foo.ps" or "lpr foo.pdf".

On some systems, you may need to convert PDF files to PostScript first (using xpdf, pdf2ps, or pdftops).

Question: I have multiple print queues. How do I print to a particular queue from an application?

If you are presented with an lpr command line to edit, add the command-line switch "-Pdestination", where destination is the name of the queue you previously created.

If all else fails, try telling the application to "print" PostScript output to a disk file, and then send it to the printer from the command line.

Question: How can I change printer options on a per-job basis from an application?

Try using one of either xpp, kprinter, or gtklp. Refer to the specific documentation for those commands for more information.

Problem: I can't print more than one job (or at all) to a DeskJet-600-class device (OfficeJet 500, 600, 700, or PSC 300 series) using hpijs.

The earliest hpijs versions had trouble printing at all to these models. This was fixed in hpijs version 0.96.

Later hpijs versions caused the device to stop accepting print jobs after printing one job, requiring a power-cycle of the device in order to print one more job. This was fixed in hpijs version 1.3.1.

Problem: When printing to a LaserJet 1200 series (or possibly other LaserJet models), the "printing" light continues to blink after finishing the job, and/or the printer doesn't accept any more jobs.

Chances are the print driver and/or print-filter pipeline isn't terminating the job properly, and ideally this issue should be fixed at that level. As a workaround, you can try arranging for the -uel command-line switch to get passed to the relevant hpoj utilities. This isn't the default behavior anymore, because it may cause problems in some situations, especially LIDIL-only (non-PCL) models.

Problem: I submitted several small jobs and pressed the Cancel button on the front panel, but all the jobs after that got flushed also.

The Cancel button on the front panel generally tells the printer to discard all buffered data and any data that's still coming in. As explained in the next problem, that could mean multiple jobs in your view of things.

Problem: I submitted several small jobs and would like to cancel one, but none of them are listed in the queue anymore even though the first job is still printing.

The hpoj driver merely acts as a data pipe to the printer, so if the printer has lots of memory for buffering jobs then the queue will empty very quickly. Currently there's no job pacing to ensure that only one job goes to the printer at a time.

Problem: I configured a DeskJet 900-series printer to print via hpoj, but the printer locks up when I send several small jobs.

This is a known problem with certain DeskJet 900-series models (990, 980, 960, and 995), which goes away if you print directly to the device instead of through ptal-mlcd. Print job pacing would help, but this is not currently supported. In any case, single-function printers are not currently targeted or tested for support by the hpoj driver.

Problem: When printing from GIMP, the print quality isn't very good.

You're probably (unwittingly) printing through GIMP-print (GIMP's built-in print driver) and bypassing the more optimal hpijs driver. Try "printing" to a PostScript file and then printing that file from the command line.

Question: How can I bypass the spooler to test the print driver and low-level I/O?

The hpijs website has instructions for manually invoking ghostscript using the following two interfaces. Run "gs -h" to determine which one is available on your system:

Here is a sample command line using the newer and more capable ijs interface: 

	cat foo.ps | gs -q -sDEVICE=ijs -sIjsServer=hpijs \
		-dIjsUseOutputFD -sDeviceManufacturer="Hewlett-Packard" \
		-sDeviceModel="DESKJET 970" \
		-r300x300 -sPAPERSIZE=letter -dNOPAUSE -dSAFER \
		-sOutputFile=- - | ptal-print mlc:usb:PSC_750
Here is a sample command line using the now-obsolete hpijs interface: 
	cat foo.ps | gs -q -sDEVICE=hpijs -sDeviceName=DJ9xx \
		-r300x300 -sPAPERSIZE=letter -dNOPAUSE -dSAFER \
		-sOutputFile=- - | ptal-print mlc:usb:PSC_750
Note that that last command in the pipeline is ptal-print, without the "d" suffix.

You can also redirect the gs standard output to a file instead of piping it to ptal-print. This can be useful for pre-rendering a print job and then more rapidly printing multiple copies of it.

Problem: I tried to send a text file directly to the printer, but nothing was printed.

Perhaps your printer doesn't support PCL or ASCII-text printing. This is probably the case with LIDIL-only or PCLXL-only models.

Problem: I bypassed the spooler and sent a text file directly to the printer, but successive lines are stair-stepped.

This is due to the different in text-file line endings between Unix (linefeed only) and DOS/Windows (carriage return and linefeed). You could try the following addcr script: 
	#!/usr/bin/perl

	# This script takes data on standard input,
	# changes newlines from LF to CR-LF,
	# and writes to standard output.

	while (<STDIN>) {
		s/\n/\r\n/;
		print $_;
	}
You could then use a command line such as: 
	cat foo.txt | addcr | ptal-print [mlc:usb:PSC_750]
Or eliminating the addcr script, a command line such as: 
	cat foo.txt | perl -p -e "s/\n/\r\n/" | ptal-print [mlc:usb:PSC_750]

Question: How can I share my printer with other clients on the network?

Both CUPS and lpd have ways to do this, but the specific procedures are beyond the scope of this document. To share printing with Windows clients, refer to Kurt Pfeifle's Samba printing HOWTO.

Problem: When printing, either the queue stalls or the job disappears without printing.

Make sure you configured printing correctly:

Assuming the queue is set up properly, there may be a connectivity problem. See the information elsewhere in this document about bypassing the spooler to print, in order to rule out a spooler or queue configuration problem.

Some USB-connected models will not be able to print unless you built hpoj with libusb support. Refer to the connectivity details and troubleshooting document for more information.

Problem: Printing is slow and/or has a high CPU utilization.

The complex raster-image processing in ghostscript and hpijs can be somewhat slow, especially on a slower CPU. Also, ptal-mlcd tends to use a lot of CPU time during periods of active device I/O.

Refer to the connectivity details and troubleshooting document for other possible causes, especially if you're using a USB connection.

Question: How can I print to a JetDirect-connected device without using the lpd network protocol?

If you're given the option for direct printing to a TCP/IP port (sometimes called "AppSocket"), you may configure the queue to print to TCP/IP port 9100 on the JetDirect (9100, 9101, or 9102 for the three-port 500X).

Some JetDirect models with recent firmware versions also support printing via IPP (Internet Printing Protocol), so this might be a good option for CUPS.

If you're not using CUPS, you may enable ptal-printd to be started for JetDirect-connected devices and use the setup method described for locally-connected devices. Edit the device configuration file in /etc/ptal, un-comment the line "init.printd.start=1", and re-run "ptal-init start".

CUPS-specific issues

Problem: I wasn't able to restart the CUPS daemon.

Perhaps it wasn't running in the first place. Make sure you actually have CUPS installed on your system and that it is set to be your default print spooler. Start it if necessary (possibly with a command such as "/etc/init.d/cups start" or "/etc/init.d/cupsd start").

If all else fails, you can simply reboot your computer. As long as ptal-init is configured to start at bootup before your print spooler, CUPS should see your new device at that time.

Problem: I couldn't access the CUPS web-administration interface.

Make sure the CUPS daemon is running (check with a command such as "ps aux | grep cups"), and start it if necessary (see above).

After (re)starting CUPS, you may need to wait a minute or two before trying to access the CUPS web-administration interface.

Check your web browser's proxy settings, and try disabling the web proxy if enabled.

Run /sbin/ifconfig and make sure the lo (loopback) interface is in the UP state and has the IP address 127.0.0.1.

Try http://127.0.0.1:631 (or whatever the loopback IP address above is) instead.

Refer to the CUPS documentation for more troubleshooting information.

Problem: The CUPS web-administration interface returns stale information, or doesn't move from one step to the next.

Try clearing the browser cache.

Check your browser's cache settings and make sure it's configured to load a fresh copy of web pages rather than always using a cached copy.

Question: Why can't I just print to something under /var/run/ptal-printd?

Newer versions of CUPS removed the ability to print to arbitrary file URIs for security reasons.

Problem: CUPS didn't list a "PTAL" entry for my device.

Make sure /usr[/local]/lib/cups/backend/ptal exists. Normally it should be a symlink to /usr[/local]/sbin/ptal-cups, but sometimes it may be the actual file. Make sure the actual file (wherever it is and whatever it's called) is present and marked as executable.

Problem: The only "PTAL" entry I saw said something like "PTAL device not found".

Question: When selecting the manufacturer, I saw both "HP" and "Hewlett-Packard" listed. Which one should I pick?

Pick either one of them for now. If you subsequently find that your model isn't listed, click on your browser's Back button and try the other manufacturer name.

Question: How do I set the default print queue?

Ideally this should be possible from the CUPS web-administration interface, but there doesn't seem to be such an option, at least not on the version of CUPS in RedHat 8.

You can do this on the command line by running (as root) "lpadmin -d destination", where destination is the name of the queue.

Question: What is the "URI" for hpoj/PTAL devices?

It is of the form "ptal:/devname". Note the single (not double) slash after the colon. You can see the URI when you run "lpinfo -v" or directly invoke the /usr[/local]/lib/cups/backend/ptal script, and you may need to use it for some operations with the lpadmin command.

Question: Where is the CUPS PTAL backend? It wasn't mentioned in the CUPS documentation.

The PTAL backend is part of hpoj, not CUPS. It is normally installed as something like /usr[/local]/sbin/ptal-cups and symlinked from /usr[/local]/lib/cups/backend/ptal. There isn't a separate manual page for ptal-cups, but you can find some more information in the comments at the beginning of that file.

Question: I set up all my print queues with CUPS and therefore have no need for ptal-printd. How can I prevent ptal-printd from getting started?

Edit the device configuration file in /etc/ptal, un-comment the line "init.printd.start=0", and re-run "ptal-init start".

LPRng- or lpd-specific issues

Question: How do I set up hpoj printing with non-CUPS print spoolers?

Be sure to follow the instructions to compile and install the hpoj software and set up basic device connectivity if you haven't already. In particular, ptal-init must be set up to start at bootup before your print spooler, or you may experience hangs during subsequent bootups.

Follow these general steps to set up printing. For more detailed information, consult your distribution's printing-setup documentation and/or the Linux Printing HOWTO.

It is recommended that you use your distribution's printer-setup utility (printtool, PrinterDrake, YAST2, etc.) if possible.

  1. Create a print queue.

  2. Select an appropriate print driver. See the main printing-setup documentation page for some tips and links to additional information, ignoring the CUPS-specific instructions.

  3. After creating the print queue(s), you may need to restart your print spooler to cause it to re-read its configuration file(s) and notice the new queue(s).

  4. Try printing a test page, either from your print-setup utility or from some other application. Also, ghostscript supplies some PostScript test pages, possibly in a directory such as /usr/share/ghostscript/6.51/examples.

Problem: When using RedHat 8.0's printconf utility, I can't enter a device path/filename longer than 20 characters.

This is a known bug in the RedHat 8.0 version of printconf, which makes it impossible to directly enter the necessary /var/run/ptal-printd/mlc:... filename. There are several possible workarounds ([1], [2]), such as creating a short-named symlink (such as /dev/officejet) to the actual file in /var/run/ptal-printd. Or better yet, just use CUPS instead.

Question: I'm using lpd and hand-editing /etc/printcap. What fields do I need to set specially for hpoj-managed devices?

For local (parallel and USB) queues, set the lp= field to the path and filename of the ptal-printd pipe file.

For remote (JetDirect) queues, set the rm= field to the hostname or IP address of the JetDirect and rp= to the remote queue name.

Question: I upgraded from hpoj-0.8, and my existing print queues are configured to print to files in /dev/ptal-printd. Why has this changed to /var/run/ptal-printd? Do I need to reconfigure my queues?

This was changed in the interest of LSB (Linux Standards Base) compliance, and because some systems have a non-persistent and/or read-only /dev file system.

For the sake of backwards compatibility, ptal-init attempts to create a symlink from /dev/ptal-printd to /var/run/ptal-printd, so if it works as is, then you probably don't need to change anything.

Question: As suggested, I looked in /var/run/ptal-printd to determine what pipe file to use, but found many similar-looking names. Which one should I use?

If you're setting up just one print queue for this device, then just use the first one (without the numbered "__N" suffix).

If you're setting up multiple queues for this device, then see the answer to the next problem.

Problem: I created multiple queues to print to the same device. If I send jobs to more than one of these queues at the same time, then the printer starts printing garbage.

By default, "ptal-init start" instructs ptal-printd to create nine additional pipe files, in case you want to set up multiple print queues for the same device. The additional pipes have the same base name as the main pipe but have a numbered suffix of the form "__N", for example, /var/run/ptal-printd/mlc_usb_PSC_750, /var/run/ptal-printd/mlc_usb_PSC_750__1, /var/run/ptal-printd/mlc_usb_PSC_750__2, etc.

Simply configure each print queue to print to a different one of these pipes, to ensure that print data from multiple queues doesn't get mixed together. ptal-printd cycles through each one in a round-robin fashion.

Question: I want to set up more than nine print queues to the same device. How can I get ptal-printd to create enough additional pipes?

Edit the device configuration file in /etc/ptal, look for and un-comment the line with "init.printd.append+=", and add "-morepipes 20" (assuming you want 20 additional pipes beyond the single base pipe). Then run "ptal-init start" so the change will take effect.

Problem: After setting up a print queue with LPRng, (re-)starting lpd hangs (i.e. during bootup).

This may happen when LPRng's init script invokes checkpc, which may hang when attempting to open a stale pipe file if ptal-printd isn't already running.

To recover from this hang at startup, you probably need to press Ctrl-Alt-Del to reboot your system. When the bootloader (LILO or grub) comes up, boot into single-user mode (pass the "single" keyword to the kernel), make the necessary changes, and reboot. Alternatively, if your distribution's startup sequence has an "interactive" mode, where it prompts you before starting each init script, you could use it to avoid starting lpd.

To prevent this problem from happening again, make sure "ptal-init start" has already happened so that ptal-printd is running for the device before the spooler is started. See the Compiling and installing details document for instructions on how to enable ptal-init to be started at the right place in the boot sequence.

Also, if you ever delete a device using "ptal-init setup", make sure you also remove the associated print queue(s).

Another way of working around this problem is to edit the lpd init script and comment out the line that calls the checkpc command.

Problem: I upgraded from a previous hpoj version, and now none of my existing print queues work.

The PTAL device name format has changed somewhat from version 0.7 and earlier. Also, the default device name for parallel-connected devices is different from that in version 0.8, where it was just "mlc:par:0" instead of being based on the model name. You likely need to reconfigure your queue(s) to print to a different destination pipe filename. Also note that ptal-printd pipe files are now placed in /var/run/ptal-printd instead of /dev/ptal-printd, but with a backwards-compatibility symlink whenever possible.

Next steps

Use the Back button on your browser to return to the previous document, or click here to return to the index.