Bug 6601 - printtool creates invalid postscript.cfg for "uniprint" driver
printtool creates invalid postscript.cfg for "uniprint" driver
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: printtool (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-01 10:49 EST by peterw
Modified: 2014-03-16 22:11 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-11-08 11:51:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description peterw 1999-11-01 10:49:28 EST
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
Comment 1 Bill Nottingham 1999-11-01 11:18:59 EST
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?
Comment 2 peterw 1999-11-01 12:08:59 EST
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)
Comment 3 Bill Nottingham 1999-11-01 12:14:59 EST
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'.

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