Bugzilla – Bug 136818
Cannot print text to an hp deskjet 870cxi printer
Last modified: 2006-01-27 09:56:14 UTC
When using an hp deskjet 870cxi printer connected to the parallel port, the following command produces a blank page. #lp /etc/fstab Various sections of printed pdf documents and HTML web pages loose some text in the print also. The same hardware using SuSE-9.3 functions correctly.
This problem is NOT related to the one described in the release notes.
Which PPD file (i.e. which printer driver) do you use? The PPD file is /etc/cups/ppd/<queuename>.ppd What is in the CUPS error_log - see http://portal.suse.com/sdb/en/2004/05/jsmeix_print-cups-in-a-nutshell.html --------------------------------------------------------------------------- If problems are encountered: 1. Set the "LogLevel debug" in /etc/cups/cupsd.conf. 2. Stop cupsd. 3. Move /var/log/cups/error_log* to another location (or delete it) in order to avoid having to search through gigantic log files. 4. Start cupsd. 5. Retry the action leading to the problem. 6. Now /var/log/cups/error_log* contains many messages that are useful for troubleshooting. --------------------------------------------------------------------------- Attach the PPD file and the error_log for exactly one failed printout as mime type "text/plain" to this bug.
Created attachment 61783 [details] cups error_log file with debug on Cups debug log file for "lp /etc/fstab" command
(In reply to comment #2) > Which PPD file (i.e. which printer driver) do you use? > The PPD file is /etc/cups/ppd/<queuename>.ppd > > What is in the CUPS error_log - see > http://portal.suse.com/sdb/en/2004/05/jsmeix_print-cups-in-a-nutshell.html > --------------------------------------------------------------------------- > If problems are encountered: > > 1. Set the "LogLevel debug" in /etc/cups/cupsd.conf. > 2. Stop cupsd. > 3. Move /var/log/cups/error_log* to another location (or delete it) > in order to avoid having to search through gigantic log files. > 4. Start cupsd. > 5. Retry the action leading to the problem. > 6. Now /var/log/cups/error_log* contains many messages that are useful > for troubleshooting. > --------------------------------------------------------------------------- > > Attach the PPD file and the error_log for exactly one failed printout > as mime type "text/plain" to this bug. > The PPD File in /etc/cups/ppd/printer.ppd is *NickName: "HP DeskJet 870C Foomatic/hpijs (recommended)"
There is no error in your CUPS error_log and I cannot reproduce it. I don't have a DeskJet 870C but a DeskJet 990C. My 990C prints fine with the "HP DeskJet 870C Foomatic/hpijs (recommended)" PPD file. Try another driver (i.e. another PPD for this printer) to test whether or not it is the driver. At the moment you use the driver "hpijs" Try "gimp-print", "cdj850" and "pcl3" which are also available for the 870C. Use the [Edit] button in YaST for this. Finally try the simple bw-only driver "deskjet" via this PPD /usr/share/cups/model/HP/DeskJet-deskjet.ppd.gz "HP DeskJet Foomatic/deskjet" Select the model "DeskJet" in YaST.
OK I tried all the suggestions in comment #5 to no avail. The command "lpr /etc/fstab" prints a blank page.
What results echo -e '\f' | cat /etc/fstab - | recode 'lat1..ibmpc' >/dev/lp0 What results grep 'parport' /var/log/messages | tail -n20
echo -e '\f' | cat /etc/fstab - | recode 'lat1..ibmpc' >/dev/lp0 printed a blank page grep 'parport' /var/log/messages | tail -n20 Jan 23 04:45:04 softtail kernel: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP] Jan 23 04:45:04 softtail kernel: parport0: irq 7 detected Jan 23 04:45:04 softtail kernel: parport0: Printer, HEWLETT-PACKARD DESKJET 870C Jan 23 04:45:04 softtail kernel: lp0: using parport0 (polling). Jan 23 04:45:04 softtail kernel: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP] Jan 23 04:45:04 softtail kernel: parport0: irq 7 detected Jan 23 04:45:04 softtail kernel: parport0: Printer, HEWLETT-PACKARD DESKJET 870C Jan 23 04:45:04 softtail kernel: lp0: using parport0 (polling).
Because echo -e '\f' | cat /etc/fstab - | recode 'lat1..ibmpc' >/dev/lp0 printed a blank page, the problem is not in the printing system but in the low level parallel port stuff. Check the low level parallel port stuff until the above command prints /etc/fstab. In particular follow at least for testing the recommendations regarding the parallel port in our Administration Manual and/or in our support database.
echo -e '\f' | cat /etc/fstab - | recode 'lat1..ibmpc' >/dev/lp0 entered as shown even prints a blank page with my 9.3 disk that prints to this printer fine. Is 'lat1..ibmpc' exactly what should be entered? Also on the 10.0 disk that can't print text to this printer, a PDF file or an HTML web page mostly prints OK, with the exception of some text missing. I have seen nothing in the Manual or the support database that addresses this problem.
To avoid any encoding problems, try the "echo" commands as shown in our maunals or in our support database, e.g. in http://portal.suse.com/sdb/en/2002/04/jsmeix_print-device-parallel.html I have no idea why it prints PDF and HTPM partially but no plain ASCII text (as in the "echo ..." command.) The DeskJet 870 can print plain ASCII text directly. If this is no longer possible it looks as if the printer internally has "forgotten" how to print plain ASCII text. Do you use the printer also with Windows? If yes, disconnect the computer and the printer from the power supply and re-connect them, then boot Linux and try again printing plain ASCII text directly (with "echo ..."). Please note that this Bugzilla is no support forum.
I am not looking for a support forum. I only reported a bug in SuSE-10.0 and was trying to help you resolve it. I am happily and "successfully" using this printer with SuSE-9.3. The machine it is connected to is used by windows(samba) and 2 other SuSE-10.0 boxes as a print server. Even when running SuSE-9.3 on this box, the command "echo -en "Hello\f" >/dev/lp0" prints a blank page. The command "lpr /etc/fstab" prints the fstab file correctly. That would indicate to me that this printer may not be capable of printing text directly.
I know the DeskJet 850 series printers from the past, they print plain ASCII text directly and this is also reported at http://www.linuxprinting.org/show_printer.cgi?recnum=HP-DeskJet_870C Your Windows driver may have switched it to any non-standard mode so that it may no longer print plain text directy. What did the complete power-off and power-on result? From your point of view it looks like a bug in Suse Linux 10.0 but I cannot reproduce it and if it was a general bug, I should have got several similar bug reports (assuming you are not the only user with a DeskJet 850 series printer) but up to now I don't know about any similar bug report.
What are the results with the recommended parport settings?
By "recommended parport settings" I assume you mean # Load lp after parport install parport /sbin/modprobe -i parport && /sbin/modprobe lp alias parport_lowlevel parport_pc options parport_pc io=0x378 irq=none,none **** in /etc/modprobe.conf? If so the same results on both 9.x ad 10.x The power off cycle (10 min) and no Windows box powered up resulted in the same with the above settings. I am also back to the HPIJS driver on both. I understand its difficult to pin down when it can't be reproduced there. I've been thinking of getting a more modern printer. Maybe I could donate this one to you?
Not /etc/modprobe.conf. You must set the mode in the BIOS, see our support database: http://portal.suse.com/sdb/en/2002/04/jsmeix_print-device-parallel.html http://portal.suse.com/sdb/en/2000/08/jsmeix_print-einrichten.html Most important is the mode setting in the BIOS. Try "Normal" or "SPP" or "Output-Only". Additionally it might happen that in your particular case the polling mode is somewhat instable. Try out if it works better with an interrupt. This must be set in /etc/modprobe.conf for example like options parport_pc io=0x378 irq=7 See the Administration Manual how to set up the parallel port so that an interrupt is used. Nevertheless the fact that PDFs and HTML result some printout seems to indicate that the parallel port stuff is working o.k. but as changing the printer drivers doesn't help, I still think that something is wrong on the low level parallel port stuff.
The BIOS is now set to SPP and I am using irq=7 mode. No change. Note that I have also moved this printer to another machine of a completly MB that dual boots from 9.0 and 10.0. The same results were found there. When I boot 9.0 it works fine. When I boot 10.0 it does the same as on the other machine.
I meant completely different mother board
I have no idea what is wrong here. Next blind test (now again regarding the printer driver). Try out the old simple b/w-only PCL3 driver "deskjet": 1. Convert the PostScript color ellipse into a PCL3 file: gs -dNOPAUSE -dBATCH -sDEVICE="deskjet" -sOutputFile=/tmp/out.prn \ /usr/share/doc/packages/ghostscript/examples/colorcir.ps 2. Send the PCL3 file directly to the printer: cat /tmp/out.prn >/dev/lp0 3. If there was a printout, verify if it looks o.k. (on the printout it is only grayscale). View the PostScript color ellipse on the screen: gs -r60 /usr/share/doc/packages/ghostscript/examples/colorcir.ps Please report about the results. If there are error mesages post the exact message.
Using the b/w-only PCL3 driver "deskjet" on both 9.x and 10.x results in a blank page for "lpr /etc/fstab" or anything else I try to print. I assume the requested steps 1 and 2 are in fact circumventing the CUPS print system all together. On both 9.x and 10.x steps 1 and 2 print a blank page no matter what driver I am using. No error messages were noted. Loading NimbusRomNo9L-Regu font from /usr/share/ghostscript/fonts/n021003l.pfb... 2252164 881503 1656248 348703 1 done.
Yes, steps 1 and 2 are to circumvent the whole printing system to get direct results regarding the driver. As the "deskjet" driver produces simplest old-stlye PCL3, it seems your printer understands neither PCL3 nor plain ASCII text but a normal DeskJet 870 does understand PCL3 (and plain ASCII), see for example /usr/share/doc/packages/ghostscript/doc/pcl3/gs-pcl3.html and http://www.linuxprinting.org/show_printer.cgi?recnum=HP-DeskJet_870C "Works also with the pcl3 driver." You may try to experiment with the "pcl3" driver like gs -dNOPAUSE -dBATCH -sDEVICE="pcl3" -sSubdevice="hpdj870c" \ -sOutputFile=/tmp/out.prn \ /usr/share/doc/packages/ghostscript/examples/colorcir.ps For the various "pcl3" driver options (e.g. -sColorModel) see /usr/share/doc/packages/ghostscript/doc/pcl3/gs-pcl3.html Does "print a blank page" mean that the print head is moving as if something real would be printed or does it mean that only a blank page is ejected? Do you really have a "870" not an "820"?
"print a blank page" It does not just eject a page. It loads the paper and it spaces forward as if it were printing a line at a time. I can actually count the upspaces and they match the number of lines, +- 1 or 2, in my fstab file. The printer is an HP Deskjet 870Cxi Professional Series. I will experiment with your suggestions and report back. I will even try it as if it were an 820 just in case the cover of the printer is wrong??
Don't try the 820 - it is a completely different type. The 820 understands only the HP PPA printer language and no ASCII. The 870 understands PCL3 and plain ASCII text. If your 870 was in fact a 820 it would never have printed in previous versions when you selected the model "DeskJet 870C". Because it moves the head as if it was printing, it reminds me of a problem in Ghostscript with black-only printing when Suse Linux 9.3 was made: https://bugzilla.novell.com/show_bug.cgi?id=90551 There was no black-only print output for some old-style drivers in Ghostscript 8.x (i.e. when "-dBitsPerPixel=1" was set for drivers like bjc600, cdj500, ...) But this is solved for Suse Linux 10.0, see rpm -q --changelog ghostscript-library ----------------------------------------------------------- Make a real fix of the bjc drivers (bug #90551) ----------------------------------------------------------- Even if you still had this problem in 10.0, it would print black-only when you send ASCII directly to the printer via echo -en "\rHello\f" >/dev/lp0 because then no Ghostscript driver is involved. Furthermore you should get at least the color-parts of the color ellipse when you print it via Ghostscript. Finally it should print well when you use a modern driver (like the recommended and default driver in YaST: "hpijs"). I still have no idea what is going wrong here.