Description of problem: Most gnome applications will automatically have the default printer selected when you open the print dialogue but openoffice.org always defaults to the first printer in the list. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Assign BrowsePoll to a cups server in /etc/cups/cupsd.conf 2. Set default printer for user via System->Preferences->More Preferences->Default Printer 3. Open oowriter 4. Type something real quick and go to File->Print 5. The first printer in the list will be selected and not the default we just set. Actual results: Not using default printer Expected results: Default printer already selected. Additional info:
You say "openoffice.org always defaults to the first printer in the list." Is there some reason you then state "Type something real quick and go to File->Print", why "real quick" ?
Let me see then, if one uses a) System->Preferences->More Preferences->Default Printer that launches gnome-default-printer as the current user as a non-root user b) if you set a new default printer here, then that writes Default printername into ~/.cups/lpoptions Now, there was bug 509064 in libgnomecups, I'm going to assume that libgnomecups-0.2.2-9 is installed and that bug is gone, i.e. that if you launch gnome-default-printer again it shows the just selected printer, so the working version of that is installed then... I assume that if you launch e.g. gedit using the libgnomeprintui dialog then this printer is shown as the default, but if you launch e.g. evince that uses the gtk_print_unix_dialog (or OpenOffice.org which currently uses that dialog also), then this printer is not selected as the default. i.e. we're talking about the gtk_print_unix_dialog dialog not honouring ~/.cups/lpoptions
Created attachment 424819 [details] backport of honouring ~/.cups/lpoptions etc.
(In reply to comment #1) > You say "openoffice.org always defaults to the first printer in the list." > Is there some reason you then state "Type something real quick and go to > File->Print", why "real quick" ? Sorry, just a term of expression poorly written from my stream of consciousness:-) You can interpret that as "Write some random text for the purposes of having something to print." Type it quick, take your time, it doesn't matter. Sorry about that.
(In reply to comment #2) > Let me see then, if one uses > a) System->Preferences->More Preferences->Default Printer > that launches gnome-default-printer as the current user > as a non-root user > b) if you set a new default printer here, then that writes Default printername > into ~/.cups/lpoptions > > Now, there was bug 509064 in libgnomecups, I'm going to assume that > libgnomecups-0.2.2-9 is installed and that bug is gone, i.e. that if you launch > gnome-default-printer again it shows the just selected printer, so the working > version of that is installed then... > > I assume that if you launch e.g. gedit using the libgnomeprintui dialog then > this printer is shown as the default, but if you launch e.g. evince that uses > the gtk_print_unix_dialog (or OpenOffice.org which currently uses that dialog > also), then this printer is not selected as the default. > > i.e. we're talking about the gtk_print_unix_dialog dialog not honouring > ~/.cups/lpoptions That would be correct. I tested and it does in fact fail with evince in the same way as in OpenOffice. GEdit on the other hand works as expected.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
The proposed patch has seen plenty of testing and the bug is very clear => ACK. Looking more deeply at the code, I don't think backporting the part of the patch that reads user *options* is a good idea though, since it's not strictly related to this bug report. On the other hand, if we decided to do it, I think we should also backport this [1] other patch, that touches the same options parsing code and adds a more correct translation from the options defined in lpoptions to the values supported by GTK. Marek, what do you think? [1] http://git.gnome.org/browse/gtk+/commit/modules/printbackends/cups?h=gtk-2-22&id=874ccc63a5751e076e77f2f8d2e53027b8301cee
Hi, I would prefer to backport the whole patch for reading user lpoptions. Having the other patch (Parse lpoptions correctly) would be also good. Regards Marek
*** Bug 509066 has been marked as a duplicate of this bug. ***
Built gtk2-2.10.4-24 with the fixes mentioned in this report.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0135.html