GNOME Bugzilla – Bug 452348
Print UI does not seed from pre-chosen print queue defaults
Last modified: 2008-08-24 18:51:01 UTC
I have a cups printer setup, and I use an lpoptions file to set certain default printer options on that queue (e.g. paper type). If I use the lpoptions -l command on the printer queue, I see all the available options for that printer, and I see the settings I have set via the lpoptions file are honoured (the output of this command puts an asterisk by the settings that would apply - these are either the original default for the printer, or my chosen settings for the options I have specified in the file). If I print with a cups command such as lp, and don't specify any special options on the command line, the printer will use the options set in the lpoptions file as one would expect. However, if I go to print to that queue using a program that uses gtk+ print ui, e.g. EOG or gThumb, then when I look through the printer options under the various UI tabs, I see that it has adopted the original printer default for every option, even the ones I set in the lpoptions file. It has thus not seeded the UI with my lpoptions file based settings. Furthermore, if I then just print without changing any settings on the UI, the printer uses what is shown on the UI, i.e. the original printer defaults and not my chosen settings. Thus my lpoptions settings are completely ignored and rendered worthless by programs using this UI. The gtk+ print system should seed the options based on the 'set' defaults, and not on the original (ppd based) defaults. Or put another way, it should be based on the same set that a simple 'lp' command usage would use, i.e. those highlighted by lpoptions -l
The gtk cups printbackend now has code to parse options from ~/.lpoptions. Actually, it looks at several locations: static const char *lpoptions_locations[] = { "/etc/cups/lpoptions", ".lpoptions", ".cups/lpoptions" }; Does that not work for you with current GTK+ ? (apart from the fact that /etc/cups/lpoptions should probably use $sysconfdir...)
Yes this bug is really a duplicate of 469210 - which is fixed satifactorily. *** This bug has been marked as a duplicate of 469210 ***