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