When using "printtool" to add or modify a printer settings, by clicking the "filter" button one gets the following error : Error in Tcl Script Error: can't read "printerdb_descr"(Lexmark5700m)": no such element in array To resolve this, edit the "/usr/lib/rhs/rhs-printfilters/printerdb" file then replace "descripton" by "description" in the "Lexmark5700m" entry.
Fixed in 1.71
*** Bug 13187 has been marked as a duplicate of this bug. ***
*** Bug 14022 has been marked as a duplicate of this bug. ***
*** Bug 13933 has been marked as a duplicate of this bug. ***
Catching up on my mail, I saw a message that droped throught the cracks. So I went to look at this bug, and I found this lurking in rhs-printfilters's printer database. There are 2 entries for the Lexmark5700, and printtool does not handle this gracefully. So the question is, which one do we axe? StartEntry: Lexmark5700 GSDriver: lxm5700m Descripton: {Lexmark 5700 inkjet printer (B/W only)} About: { \ Driver for the Lexmark 5700 inkjet printer. \ This driver supports only black-and-white, 1200dpi \ printing. Contributed by Stephen Taylor \ <setaylor.com>. \ } Resolution: {1200} {1200} {} BitsPerPixel: {1} {Normal B&W printing} EndEntry StartEntry: Lexmark5700 GSDriver: lex5700 Description: {Lexmark 5700 BW} About: { \ This driver supports the Lexmark 5700 ink \ "GDI" printers. It prints Black and White only. \ Do *NOT* check 'Fast Text Printing' field. \ } Resolution: {300} {300} {} Resolution: {600} {600} {tested} Resolution: {1200} {1200} {} BitsPerPixel: {1} {Normal B&W printing} EndEntry
okay, here is the fix we're going with. 1) Entry/Description pairs must have a one to one mapping (its a limitation in printtool), so the first entry is getting clobbered in printtool by the second. So they need different keys. I've given the first entry the key 'Lexmark5700a', as it is now the 'alternate' driver. I've changed it's description to indicate this. which brings up... 2) If you note, the first entry has a missspelled 'Descripton' keyword. printtool didn't see this while the collide was occuring, but it was the cause of the original bug. So that is fixed now. Took me much nashing of teeth to notice that little detail... I am closing this bug.