After (finally!) getting /dev/lp0 to work after a 5.1 -> 6.1 upgrade (that really _should_ be easier!), I discovered a problem with printtool. It does not put a value for COLOR in the postscript.cfg file for print queues it creates. For instance, for my BJC610 print queue, it made a file like this (comments removed): GSDEVICE=uniprint RESOLUTION=360x360 COLOR= PAPERSIZE=letter EXTRA_GS_OPTIONS="@/usr/share/ghostscript/5.10/bjc610a0.upp" REVERSE_ORDER= PS_SEND_EOF=NO NUP=1 RTLFTMAR=18 TOPBOTMAR=18 But /usr/lib/rhs/rhs-printfilters/ps-to-printer.fpi looks for a value for COLOR, and defaults to use the "stcany" .upp file if no value is set. I fixed this by manually changing the COLOR line to read COLOR=bjc610a0 but I think printtool should have done that for me. Using printtool-3.41-2 -Peter
I can't reproduce this here. Selecting 'Canon BJC-610 (UP)' and 'bjc610a0...' under 'Color Depth / Uniprint Mode', I get the following postscript.cfg: GSDEVICE=uniprint RESOLUTION=NAxNA COLOR=bjc610a0 PAPERSIZE=letter EXTRA_GS_OPTIONS="" REVERSE_ORDER= PS_SEND_EOF=NO which should work fine. Are you setting yours up differently?
The 5.1 -> 6.1 upgrade did not replace my "printerdb" file, possibly because I had manually edited it before. Which explains why you see a "UP" option for BJC610 while I did not. The "printtool" package verified cleanly, and "rhs-printfilters" (1.57-3) verified _except_ for the printerdb. I copied printerdb.rpmnew back over printerdb, and now printtool itself crashes on me. I have a bad feeling I need to manually edit /etc/printcap if I want to use the new printerdb, since printtool is not catching exceptions. (Here my printcap lists the printer as "Uniprint" where there is no Uniprint printer entry in the new printerdb.) Thanks. Here's the dump when running printtool with my existing /etc/printcap and queues, after putting the "correct" printerdb back so that both printtool and rhs-printfilters verify cleanly: rror in startup script: can't read "printerdb_descr(Uniprint)": no such element in array while executing "set printer $printerdb_descr([lindex $info 4])" (procedure "FILTERED_summaryline" line 7) invoked from within "FILTERED_summaryline $i "local printer"" (procedure "LOCAL_summaryline" line 5) invoked from within "$printer_type($i)_summaryline $i" (procedure "redisplay" line 6) invoked from within "redisplay" (file "/usr/bin/printtool" line 3239)
Ok; that's why RPM creates the new printerdb as .rpmnew as opposed to overwriting the old one; so the old configuration stands at least a chance of working. (And yes, printtool does crash if it sees a configuration in /etc/printcap that doesn't match a printer in the database.) What you'll need to do is either remove that entry from /etc/printcap and create a new one, or simply edit the comment line in printtool so it points to something like 'U_CanonBJC610' as opposed to 'Uniprint'.