If I lpr a text file to my HP Deskjet 890C, nothing happens. lpq shows the following: 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 01:38:48.117 Rank Owner/ID Class Job Files Size Time active ejb@soup+868 A 868 login/zsh/do_global_s 1063 01:38:47 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 digging. 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.
interseting. Will investigate.
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?
Created attachment 11320 [details] /usr/share/printconf/mf_rules/mf99-printer_language_filters
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 yet. 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 already. 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: 'text' 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: http://people.redhat.com/crutcher/printing/ 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.
Right now: % rpm -qa | egrep '(printconf|alchemist|ghostscript|LPRng)' ghostscript-5.50-17 ghostscript-fonts-5.50-3 alchemist-0.16-2 printconf-gui-0.2.2-1 LPRng-3.7.4-17 printconf-0.2.2-1 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 qed_driver_section_teardown(q_obj) 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 people.redhat.com/crutcher/printing. 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 satisfaction.
Jetdirect printing, text printing to non-ascii capable printers, and the traceback solved.