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.

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, 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.

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.

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

As explained on the main Printing setup document, make sure you're printing through ptal-printd rather than directly to something like /dev/lp0 or /dev/usb/lp0. On the other hand, for CUPS, make sure you're printing through the ptal backend rather than the parallel, usb, or file backends.

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.

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 /usr/local/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.

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 /usr/local/etc/ptal, un-comment the line "init.printd.start=1", and re-run "ptal-init start".

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 /usr/local/etc/ptal, un-comment the line "init.printd.start=0", and re-run "ptal-init start".

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: CUPS doesn't notice the device I just added.

Make sure you re-start CUPS after running "ptal-init setup" while the device is still connected and powered on, because this is the only time it probes for new devices for purposes of setting up new print queues.

Also, see the previous problem about ensuring that ptal-init gets started at bootup before your print spooler (in this case, CUPS).

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.

Problem: I'm using an hpijs version prior to 0.96, and I can't print through ptal-mlcd using the DJ6xx driver.

Older hpijs versions had a bug that made the DJ6xx and DJ6xxPhoto device-class drivers not work in conjunction with ptal-mlcd. This problem was fixed starting in version 0.96.

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 older 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 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.

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 ~/.profile | addcr | ptal-print mlc:usb:PSC_750

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 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 previous problem, that could mean multiple jobs in your view of things.

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: The ghostscript output is too light or too dark.

Thanks to Joe Piolunek for providing this information.

If you need to adjust the brightness of one of the ghostscript drivers (probably not necessary with the hpinkjet drivers), then create the file /usr/local/etc/gamma.ps (or in a different location if you'd like). Specify this filename (with the full path) in the "Extra GS options" field for the print filter configuration dialog box (for RedHat printtool). In general, this file should be passed to ghostscript before the actual file you're trying to print.

My gamma.ps contains the following text (between the "cut" lines). Blank lines and lines starting with '%' are ignored by ghostscript.

cut------------------------------------------------

%!
% filename: /usr/local/etc/gamma.ps
%
% Blank lines and lines starting with '%' are ignored by ghostscript.
%
% For additional information, see 'Devices.htm' or 'devices.txt' in your
% ghostscript documentation.
%
% Enable only one line by removing the '%'
% from the beginning. You may need to play with
% these settings to see which works best
% on your printer model. Your ghostscript
% version may also make a difference.
%
% Some models may prefer three gamma correction parameters, some four.
%
% This is the currently enabled setting. It works with my OfficeJet 600:
{0.333 exp} {0.333 exp} {0.333 exp} currenttransfer setcolortransfer
%
% If the first doesn't work, try this:
%{0.333 exp} {0.333 exp} {0.333 exp} {0.333 exp} currenttransfer setcolortransfer
%
% Settings can be abbreviated.
% {0.333 exp} dup dup currenttransfer setcolortransfer
%
% The floating-point numbers in the curly braces
% can be used to lighten or darken individual colors,
% but it is probably better to keep them equal to each other.
%
% Decreasing the size of the floating-point numbers
% in the parameter set will lighten the printing.
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% This section is taken from the SuSE Linux Support web site. It is meant for
% use with apsfilter, but it may be useful in other cases:
%
% Note: these don't work for me. I'm including them only
%       as information in case you want to try them.
%
% Assuming your printer uses CMYK colors, just remove the '%'
% sign from the line you'd like to use as follows:
%
%%   CYAN      MAGENTA     YELLOW      BLACK
%{0.217 exp} {0.217 exp} {0.217 exp} {0.217 exp} setcolortransfer
%{0.256 exp} {0.256 exp} {0.256 exp} {0.256 exp} setcolortransfer
%{0.333 exp} {0.333 exp} {0.333 exp} {0.333 exp} setcolortransfer
%{0.450 exp} {0.450 exp} {0.450 exp} {0.450 exp} setcolortransfer
%
% The values must be between 0.001 and 0.999
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
cut------------------------------------------------

Setting ownership and permissions for gamma.ps:

	$ su
	# cd /usr/local/etc
	# chown root:root gamma.ps
	# chmod 644 gamma.ps
It's not necessary to restart lpd if you're only modifying gamma.ps.

The SuSE Linux Support site has more information on printer gamma setting. A Google search for gamma.ps will turn up more information.

Next steps

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