Red Hat Bugzilla – Bug 117860
"bjccolor" device support missing in ghostscript
Last modified: 2007-11-30 17:10:38 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
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'
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):
Steps to Reproduce:
1.run redhat-config-printer on a Canon BJC-255SP parallel port printer
2.try and print a test page
Actual Results: no page printed; CUPS error_log reports unknown
Expected Results: bjccolor device available; test page prints
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:
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:
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
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
/var/log/cups/error_log likewise, shows nothing pointing to any kinds
After each new job submitted, it merrily tells me that everything
[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] 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?
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
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
Woops! I'll leave resolution to you guys in future. :-)
Test update released:
Official update released: