After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 452348 - Print UI does not seed from pre-chosen print queue defaults
Print UI does not seed from pre-chosen print queue defaults
Status: RESOLVED DUPLICATE of bug 469210
Product: gtk+
Classification: Platform
Component: Printing
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-06-29 19:36 UTC by Karl Relton
Modified: 2008-08-24 18:51 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18



Description Karl Relton 2007-06-29 19:36:57 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
Comment 1 Matthias Clasen 2008-08-15 20:19:29 UTC
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...)
Comment 2 Karl Relton 2008-08-24 18:51:01 UTC
Yes this bug is really a duplicate of 469210 - which is fixed satifactorily.

*** This bug has been marked as a duplicate of 469210 ***