From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 Description of problem: After setting up my Canon BJC-255SP printer with redhat-config-printer, I tried to print a test page, but this failed. Upon analysis of the resulting error_log box, a message specifying that device "bjccolor" was unknown was displayed: D [09/Mar/2004:18:31:51+1000] [Job 7] renderer command: gs -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=bjccolor-sPrinterType=BJC-250' <snip rest of line> D[09/Mar/2004:18:31:51 +1000] [Job 7] foomatic-gswrapper: gs'-dBATCH' '-dPARANOIDSAFER' '-dQUIET''-dNOPAUSE''-sDEVICE=bjccolor''-sPrinterType=BJC-250' <snip rest of line> D[09/Mar/2004:18:31:51+1000] [Job 7] Unknown device: bjccolor ^^^^^^^^^^^^^^^^^^^^^^^^ Tim Waugh specified that foomatic somehow missed this device (and the others I mention in section "Additional Information") and as such, the driver wasn't compiled in. Version-Release number of selected component (if applicable): ghostscript-7.07-15.1 How reproducible: Always Steps to Reproduce: 1.run redhat-config-printer on a Canon BJC-255SP parallel port printer 2.try and print a test page 3. Actual Results: no page printed; CUPS error_log reports unknown device "bjccolor" Expected Results: bjccolor device available; test page prints successfully Additional info: The other devices that should also be compiled in along with "bjccolor", as listed at http://bjc250gs.sourceforge.net/, the printer model's driver homepage, are: *bjcmono *bjcgray *bjccmyk foomatic-3.0.0-21.3 Also tried the latest devel version of ghostscript (7.07-24), but problem still evident.
Fixed in ghostscript-7.07-25, which should show up in rawhide tomorrow. I'll build a test update for Fedora Core 1.
Please try the packages at: http://cyberelk.net/tim/data/tmp/117860 and let me know if they fix the problem on Fedora Core 1. Thanks.
Ok, the packages fixed the unknown device error; `gs -h` now lists "bjccolor", "bjcmono".. etc. The test page still wouldn't print however, but the following log data contained no errors or hints at the problem at all. It seemed to show the operation being successful. So I would assume this is now a configuration related problem, not to do with this bug any longer? Thanks.
Please try putting 'debug: 1' in /etc/foomatic/filter.conf and trying again. Then there will be /tmp/foomatic-rip.log -- does that give any clue?
Ok, /tmp/foomatic-rip.log showed no errors or signs of a problem. KID3, KID4 and renderer all exited with status code '0'. Which is normal behaviour.. /var/log/cups/error_log likewise, shows nothing pointing to any kinds of problem.. After each new job submitted, it merrily tells me that everything completed fine: [Job 18] Closing renderer [Job 18] KID3 exited with status 0 [Job 18] tail process done writing data to STDOUT [Job 18] KID4 exited with status 0 [Job 18] Renderer exit stat: 0 [Job 18] KID4 finished [Job 18] KID3 finished [Job 18] Renderer process finished [Job 18] [Job 18] Closing foomatic-rip UpdateJob: job 18, file 1 is complete. CancelJob: id = 18 StopJob: id = 18, force = 0 StopJob: printer state is 3
How about setting up a queue to print to a file? touch /tmp/lp0 chown lp /tmp/lp0 chmod u+w /tmp/lp0 and set the 'custom device' to be /tmp/lp0. Does that file end up with content after printing to its queue?
Indeed it does. Lots of binary garbage that my terminal didn't like too much. :-) So, something wrong with my /dev/lp0 I presume?
Possibly. Is this printer known to work? Try this as root, to minimise the path between the driver and the printer (in case there are cups/foomatic bugs): gs -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=bjccolor -sPrinterType=BJC-250 -sFeeder=Auto -sQuality=Normal -dInverse=false -dSmooth=false -dCompress=true -dComposeK=false -dLimitCheck=false -dPaperRed=255 -dPaperGreen=255 -dPaperBlue=255 -dRedGamma=1.000000 -dGreenGamma=1.000000 -dBlueGamma=1.000000 -dGamma=1.000000 -dRandom=15 -sOutputFile=/dev/lp0 /usr/share/cups/data/testprint.ps
That command-line produced no output (which means the software components are working fine?). This printer is known to work on a Win98 box. I haven't got it working in RH previously, though, that was lack of good driver support, unrelated to this problem in FC1. Which seems more likely of getting it to work now thanks to full driver support. In case it matters, parport and parport_pc are successfully loaded. Maybe a parallel port problem? Any diagnosis commands I can send the port to verify that it's functioning properly? Because that must be the problem if the printer and cable are functional.
Hmm, that command was supposed to actually print a test page. Well, www.linuxprinting.org says that this printer supports ASCII text printing. So try: cat /etc/fstab > /dev/lp0
Great news! Printing works!! It turns out that kudzu hadn't detected the printer properly (I should have realised that..), and as such the print jobs where ending up in the ether of lost bytes..(or something like that :-) ) I now have perfect printouts as should be expected. Thank you Tim for your extended help and the updated packages. :) One final note: (Slightly OT) Clicking the "Print Manager" icon on gnome-panel brings up an error dialog with: Error: Cannot launch icon. Details: Failed to execute child process "tryprint.pl" (no such file or directory) And sure enough a search for "tryprint.pl" produced no results. Am I somehow missing a package containing this? The proerties of the launcher specify the command "tryprint.pl %F". Feel free to direct my to the fedora-list if this isn't a bug.
Please open a separate bug report for that. That should come from desktop-printing.
Thank you, desktop-printing now installed; problem fixed. I'll close this bug report.
Not so fast! Need to keep this open to track the test update to final release.
Woops! I'll leave resolution to you guys in future. :-)
Test update released: http://www.redhat.com/archives/fedora-test-list/2004-March/msg00677.html
Official update released: http://www.redhat.com/archives/fedora-announce-list/2004-March/msg00019.html