richard (MQ) wrote:
Constantine 'Gus' Fantanas wrote:
The printer prints the test page from inside YAST perfectly well. And it also prints the test page from inside the CUPS administration tool (http://127.0.0.1:631) without any problem, even the fine radial lines 1 degree apart. It also works fine from inside openoffice. But when I try to print from inside firefox or Thunderbird, it seems it wants to print the Postscript instructions rather than executing them.
I have the same problems with an old HP laserjet, both on AMD64 and i386 installations (and various SuSE / openSuSE versions since about 9.3 right up to 10.2. Yet to try it in 10.3a2). Solution was to select a different PPD during YaST install - I usually use LJ5 - then it all works nicely.
One other thought: if mozilla (FF. TB or whatever) lists the printer (in the print dialogue) as CUPS/xxxx it's going through CUPS, if it shows anything else at the start of the device name then it probably isn't
Hope this helps...
Thank you for responding. The printer in question is displayed as CUPS/xxxxx. I did some more troubleshooting by watching the output of 'tail -n 200 -f /var/log/cups/error_log' and 'tail -n 200 -f /var/log/cups/access_log'. In the former (which apparently does not log only errors but also other important information), I realized that cups goes exactly through the same steps when it prints the test page from inside YAST or the test page from inside the CUPS GUI (at http://127.0.0.1:631) or the troublesome firefox output. Here is a snippet: I [13/Apr/2007:01:37:51 -0400] Adding start banner page "none" to job 180. I [13/Apr/2007:01:37:51 -0400] Adding end banner page "none" to job 180. I [13/Apr/2007:01:37:51 -0400] Job 180 queued on "HP8450" by "gus". I [13/Apr/2007:01:37:51 -0400] Started filter /usr/lib64/cups/filter/pstops (PID 16960) for job 180. I [13/Apr/2007:01:37:51 -0400] Started filter /usr/lib64/cups/filter/foomatic-rip (PID 16961) for job 180. I [13/Apr/2007:01:37:51 -0400] Started backend /usr/lib64/cups/backend/socket (PID 16962) for job 180. (The "I" obviously means "information.") The steps are always the same: invoke 'pstops', then the 'foomatic-rip' filter, and then the 'socket' backend. I guess this is done by the PPD file for the printer. So, with exactly the same sequence, the firefox output on the printer is PS commands (garbage) while the output of the test files is what it should be. Going further, I asked firefox to print to a file. Here it gets interesting. If I open the file with KGhostscript and then print it from inside KGHostscript, the file prints fine! If I do the same from other PS viewers (e.g. 'gv'), the output is garbage again. I also get the same garbage if I queue a PDF file directly to the printer. All this seems to point towards some incompatibility of the Postscript format with the 'foomatic-rip' filter. It seems that KGhostview somehow makes some (perhaps minor) reformatting, which makes its output compatible with the 'foomatic-rip' filter. I have done sooooo much googling trying to solve this problem! I think I read somewhere that the 'foomatic-rip' filter should be avoided. I am not sure where I read it. The driver invoked by CUPS is the generic 'Foomatic/hpijs' driver, which is provided by HP and is used on many other HP printers. I guess it was the same driver I was using under SuSE 10.0_x64. -- Running 64-bit Linux on AMD64 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-amd64+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-amd64+help@opensuse.org