Bug 117860 - "bjccolor" device support missing in ghostscript
Summary: "bjccolor" device support missing in ghostscript
Alias: None
Product: Fedora
Classification: Fedora
Component: ghostscript (Show other bugs)
(Show other bugs)
Version: 1
Hardware: athlon Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-09 12:49 UTC by Matt Hansen
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-05 11:27:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Matt Hansen 2004-03-09 12:49:09 UTC
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
-sDEVICE=bjccolor-sPrinterType=BJC-250' <snip rest of line>
D[09/Mar/2004:18:31:51 +1000] [Job 7] foomatic-gswrapper: gs'-dBATCH'
'-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):

How reproducible:

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
device "bjccolor"

Expected Results:  bjccolor device available; test page prints

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:


Also tried the latest devel version of ghostscript (7.07-24), but
problem still evident.

Comment 1 Tim Waugh 2004-03-09 13:17:05 UTC
Fixed in ghostscript-7.07-25, which should show up in rawhide
tomorrow.  I'll build a test update for Fedora Core 1.

Comment 2 Tim Waugh 2004-03-09 14:52:33 UTC
Please try the packages at:


and let me know if they fix the problem on Fedora Core 1.  Thanks.

Comment 3 Matt Hansen 2004-03-09 15:46:53 UTC
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.

Comment 4 Tim Waugh 2004-03-09 15:57:00 UTC
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

Comment 5 Matt Hansen 2004-03-09 16:28:08 UTC
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

Comment 6 Tim Waugh 2004-03-09 16:30:53 UTC
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?

Comment 7 Matt Hansen 2004-03-09 16:38:02 UTC
Indeed it does. Lots of binary garbage that my terminal didn't like
too much. :-)

So, something wrong with my /dev/lp0 I presume?

Comment 8 Tim Waugh 2004-03-09 17:04:57 UTC
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):

-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

Comment 9 Matt Hansen 2004-03-09 17:36:57 UTC
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. 

Comment 10 Tim Waugh 2004-03-09 18:03:10 UTC
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

Comment 11 Matt Hansen 2004-03-10 09:47:29 UTC
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.

Comment 12 Tim Waugh 2004-03-10 09:51:07 UTC
Please open a separate bug report for that.  That should come from

Comment 13 Matt Hansen 2004-03-10 10:47:31 UTC
Thank you, desktop-printing now installed; problem fixed. I'll close
this bug report.

Comment 14 Tim Waugh 2004-03-10 11:51:26 UTC
Not so fast!  Need to keep this open to track the test update to final

Comment 15 Matt Hansen 2004-03-10 12:32:42 UTC
Woops! I'll leave resolution to you guys in future. :-)

Comment 16 Tim Waugh 2004-03-10 16:21:16 UTC
Test update released:


Comment 17 Tim Waugh 2004-05-05 11:27:28 UTC
Official update released:


Note You need to log in before you can comment on or make changes to this bug.