Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 29170 - printing text to deskjet 890C does nothing
printing text to deskjet 890C does nothing
Product: Red Hat Linux
Classification: Retired
Component: printconf (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Crutcher Dunnavant
Depends On:
  Show dependency treegraph
Reported: 2001-02-24 01:42 EST by Jay Berkenbilt
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-03-06 18:14:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/usr/share/printconf/mf_rules/mf99-printer_language_filters (257 bytes, text/plain)
2001-02-28 03:31 EST, Crutcher Dunnavant
no flags Details
printer configuration files (1.60 KB, application/octet-stream)
2001-02-28 23:42 EST, Jay Berkenbilt
no flags Details

  None (edit)
Description Jay Berkenbilt 2001-02-24 01:42:15 EST
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

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...
Comment 1 Glen Foster 2001-02-26 18:57:38 EST
We (Red Hat) should really try to resolve this before next release.
Comment 2 Tim Waugh 2001-02-27 09:16:50 EST
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
Comment 3 Jay Berkenbilt 2001-02-27 09:38:43 EST
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.
Comment 4 Crutcher Dunnavant 2001-02-27 10:40:48 EST
Will investigate.
Comment 5 Crutcher Dunnavant 2001-02-28 03:29:01 EST
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
interface fails?
Comment 6 Crutcher Dunnavant 2001-02-28 03:31:21 EST
Created attachment 11320 [details]
Comment 7 Jay Berkenbilt 2001-02-28 23:41:19 EST
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.... :-)
Comment 8 Jay Berkenbilt 2001-02-28 23:42:03 EST
Created attachment 11420 [details]
printer configuration files
Comment 9 Crutcher Dunnavant 2001-03-01 01:00:51 EST
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.
Comment 10 Jay Berkenbilt 2001-03-01 09:52:53 EST
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.
Comment 11 Crutcher Dunnavant 2001-03-02 12:48:42 EST
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.
Comment 12 Jay Berkenbilt 2001-03-04 23:59:54 EST
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.
Comment 13 Jay Berkenbilt 2001-03-06 18:14:54 EST
Right now:

% 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
    o_list.addChild(Alchemist.Data.ADM_TYPE_STRING, 'default').setValue(q_def)
  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
Comment 14 Crutcher Dunnavant 2001-03-09 16:11:59 EST
Jetdirect printing, text printing to non-ascii capable printers, and the
traceback solved.

Note You need to log in before you can comment on or make changes to this bug.