Red Hat Bugzilla – Bug 29170
printing text to deskjet 890C does nothing
Last modified: 2008-05-01 11:37:59 EDT
If I lpr a text file to my HP Deskjet 890C, nothing happens. lpq shows the
Printer: draft@soup (dest auto@printer)
Queue: 1 printable job
Server: pid 1869 active
Unspooler: pid 1870 active
Status: sending data file 'dfA868soup.in.ql.org' to auto@printer at
Rank Owner/ID Class Job Files Size Time
active ejb@soup+868 A 868 login/zsh/do_global_s 1063
Active connection from 10.160.59.17
As far as I can tell, no traffic is actually going to the printer at all.
Printing PostScript to this printer works. (It didn't under Fisher.)
This is reproducible with the deskjet, cdj550, and cdj890 drivers. In all
cases, the printers were configured with printconf-gui.
Manually appending ESC-e (with no newline) to the file doesn't help.
I don't know lprng well enough to diagnose further without considerable
There were a number of bugs in Fisher relating to issues such as sending
EOF after PostScript/text jobs... most of the problems that I can reproduce
seem fixed, but this plain text printing seems completely broken now...
We (Red Hat) should really try to resolve this before next release.
If you write the text file directly directly to the port (I'm assuming it's a
directly-connected parallel port printer), does that work?
cat textfile > /dev/lp0
It's not a directly connected printer. It's hanging off of an old external
JetDirect device. I've been using this device with this printer for ages with
no problem. I'm using the lpd interface rather than the JetDirect interface.
My JetDirect device has the latest firmware.
Hmm, try replacing /usr/share/printconf/mf_rules/mf99-printer_language_filters
with this attachement.
Additionally, send me a copy of /var/spool/lpd/?spoolname?/mf.cfg
and /etc/alchemist/namespace/printconf/local.adl (which is just gziped XML)
And, are you using the lpd interface for preference, or because the Jetdirect
Created attachment 11320 [details]
Replacing mf99-printer_language_filters had no effect. I had been using lpd
because jetdirect didn't work at all in Fisher but I also had a very old
jetdirect device and couldn't get printing to work even through a parallel port.
I forgot to go back and retest. I just tested using jetdirect now and it works
the same as lpd -- postscript prints fine, text doesn't print at all.
I'm attaching a tarfile containing the files you've requested along with
/etc/printcap just for kicks. Note that the problem with text printing doing
nothing applies to all six printer definitions which all point to the same
printer. PostScript printing works on all six definitions. (I use deskjet,
cdj550, and cdj890 depending upon what kind of print speed/quality I want.)
The exact behavior with my deskjet 890C is that printing text through the cdj890
or cdj550 drivers results in a flashing green light on the printer followed by a
flashing orange light and no output. Printing text with the deskjet driver
results in no signs from the printer at all.
Some operations seem to get the jet direct device into a state where it needs to
be physically reset.
It also appears that printing text and then printing PostScript will cause the
text to come out and then the PostScript to come out.
I'm not sure how much of this is jet-direct related. I don't have a way of
attaching the printer locally to a machine running Wolverine, but I do have a
machine running Fisher that is physically close to the printer. I can upgrade
the necessary rpms or install wolverine on that machine, but not tonight....
Let me know if there are more things you want me to try. If necessary, I can go
through and test this more systematically reporting my findings more precisely.
I've just done this informally tonight since I have to get to bed....
What's definite is that whether I use the JetDirect's lpd or jetdirect interface
I seem to get the same results which are that postscript printing works and text
printing does not work. The details of how it doesn't work vary depending upon
the driver and perhaps other variables that I haven't systematically isolated
Hmm. I'm going to have to study this new print system sometime. There's a lot
going on here that is new. After using Berkeley lpd for 13+ years, I guess I no
longer know exactly what's going on behind the scenes here.... :-)
Created attachment 11420 [details]
printer configuration files
Okay, I think I know whats going on.
I think the fact that you are not printing a form-feed character is confusing
your printer's mind. To test this theory, try the following:
echo -e 'test text\014' | lpr -Pprintername
If it prints, then that's the problem. If that's the problem, then I've fixed it
If this is the fix, and you want to be brave, and patch the system you've got
for now, edit the file /usr/share/printconf/util/make_mf_config.pl and find the
place where $text_filter gets assigned the value:
and change it to the value:
'text "" \14 ' <- the space after the \14 is important, there is a bug in the
magicfilter you have.
If this is not your problem, then we will try something else.
I seriously doubt it will work since I've tried various things with \004, \014,
and even \032 (which some devices, perhaps based on a DOS legacy, have treated
as an EOF character). Even last night, I tried echo -n ^L (as in CTRL-v CTRL-l)
| lpr in hopes of just getting a blank page but I got nothing. Then upon
printing a postscript file, I got my previously printed text on a page by itself
followed by my postscript on a page by itself thus leading me to suspect that it
was more likely to be an EOF problem than a form feed problem. Anyway, I'll
make the changes you suggest and perhaps poke around a little more by carefully
examining what happens in RH6.2 tonight when I get home. I have a nifty print
filter (consisting of just a couple of lines of code) that captures whatever is
being sent over the wire and saves it to a file. I use it in my test suite for
some batch-mode printing utilities I've written. Using these tools, I should be
able to investigate more and provide better information than I have been so far.
I'm getting a nasty feeling that I'm gonna need to add a whole subpage of
manually set termination options.
I love standards, there's so many of them!
Keep in mind in your tests on your printer that many printers have /different/
end of file characters for postscript and text.
Btw, I'm keeping the most recent printing rpms at:
Very interested in what you find out.
Sorry -- I didn't have any computer time this weekend (until now) but I'll try
to get a chance to gather this information ASAP. I've upgraded to 0.2-1 with no
changes to these problems.
One other argument in favor of having a subpage for termination options: what if
you just have a text/postscript/raw queue print configuration? There certainly
can't be any kind of reasonable default for whether to send EOF or do newline
translation in these cases but I'll bet different printers still have different
requirements in this case. It should definitely be possible to control whether
or not EOF is generated for a text-only or PostScript-only printer. (One could
better argue against this for raw queue....)
Also, I misspoke earlier -- echo -n test^L | lpr does work. I thought I had
tried it before, but I guess I remembered wrong.
Hmm. After I typed all this, I downloaded the new alchemist and LPRng packages
from the URL you mentioned above, and now echo -n test^L | lpr doesn't work
anymore. I'm confused and tired and am going to stop now. I think I'll start
from scratch and retest everything.
% rpm -qa | egrep '(printconf|alchemist|ghostscript|LPRng)'
both text and PostScript printing work fine using UNIX LPD and the deskjet,
cdj550, and cdj890 drivers. I'm having some trouble if I select jetdirect
printing, but this may be related to the print server. I'm also not able to get
anywhere with the spt driver but I don't really care right now.
FYI, if you try to set up a printer using the stp driver and click on "Grayscale
only", you get python errors:
Traceback (innermost last):
File "/usr/lib/python1.5/site-packages/libglade.py", line 28, in __call__
ret = apply(self.func, a)
File "/usr/sbin/printconf-gui", line 1843, in on_qld_edit_button_clicked
q_obj = qed_run(queue)
File "/usr/sbin/printconf-gui", line 607, in qed_run
File "/usr/sbin/printconf-gui", line 1372, in qed_driver_section_teardown
File "/usr/lib/python1.5/site-packages/Alchemist.py", line 176, in setValue
string_setValue (self._dat, v)
SystemError: NULL result without error in call_object
Even without this, I get errors when I actually print, so I have not pursued the
stp driver further.
Right now, my printing problems are resolved with the current versions from
up2date which I think are at least as recent as your test versions in
Please let me know if you require additional testing from me. Otherwise, I'm
considering this resolved to the point where it works at least as well as in
previous releases and to where I can get printing configured fully to my
Jetdirect printing, text printing to non-ascii capable printers, and the