Red Hat Bugzilla – Bug 478400
default printer in a network
Last modified: 2009-03-23 11:59:03 EDT
Description of problem:
I have several shared printers in a network, all of them are the same make and model. OO.o seems to get the default printer and then use the first listed one of the same make and model.
Example: a net with 2 computer (PC1 and PC2), both with a HP LaserJet 1150 usb printer connected to it, both shared. If I start configuring PC1, when I go to configure PC2 it has the network printer in PC1 already detected and configured, then I add the local printer (it would be the second listed) and set it as the default for PC2. If I open OO.o's Calc or Writer in PC2 and press the printer icon, it will print on PC1's printer instead of the default local printer.
It happens with firefox too.
It does not happen with software I develop with wxWidgets, where it prints to the right default printer.
I think it's not a cups error, but an application error in the way it selects the default printer.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. In 2 computers in a network connect the same model of printer and share it on the local network. Both PC with Fedora 10 with the default installation options. Firewall open for printing (client and server).
2. Open OO.o Writer and try to print a document with the printer icon. In one of the two computers will print on the network printer instead of the local default printer.
Does not set the correct default printer in the application.
Is 'lpstat -d' showing the default printer you expect?
[me@proglinux ~]$ lpstat -d
destino por omisión del sistema: hp-LaserJet-1150
Yes, it is.
Currently, in this computer (proglinux) there's a local hp 1150 and two more in the network. Depending on the computer that is turned on first, it may set one of the three printers as the default,and it happens for OO.o applications or for firefox.
My concern is that I usually use the printer icon in OO.o Writer, where the application just prints without asking. And if the printer owner had some numbered sheets in the tray, then I accidentally use their paper, which gives us trouble because we have to explain what happened with those prenumbered sheets.
But does 'lpstat -d' continue to show the default printer you expect, or does it depend which computer is switched on first? In other words, is 'lpstat -d' showing you the same behaviour as the OpenOffice.org print dialog?
I think you are seeing behaviour due to CUPS, but I want to make sure.
'lpstat -d' shows the right default printer no matter the order I switch computers on.
I made some test this morning and I saw that the first description of the problem is inexact.
If I use the printer icon in OO.o it prints to the right default printer.
If I print through the menu option File->Print (Ctrl+P) it opens a dialog where it shows the wrong default printer.
The remote's printer name is hp-1150-co and my local printer name is hp-LaserJet-1150.
In the File->Print dialog, I saw the following:
1. If the second computer is off, system-config-printer does not show the printer. When I try to print with the menu option, the dialog seems to be looking for the printer, and as it's not there, it selects automatically the next printer in name order.
2. If I switch the computer on, it appears in system-config-printer, and the printer selection dialog of the menu option shows it too. But it selects the network printer instead of the local default one.
3. I tried changing the name of the remote printer. The new name is hp-z-1150-co. When I print with the printer icon, it prints to the right default printer. If I print with the menu option, it takes some seconds to open the dialog as if it would be looking for the network printer. Is that dialog saving the last selected printer somewhere? As the printer doesn't exist, it selects the next printer in name order, which happens to be another network printer and not the default one.
It seems that I remembered wrong when I written the description of the problem the first time. Sorry. :-(
Don't hesitate to ask if you need me to test something.
It sounds like the problem is with the dialog then. Reassigning to OpenOffice.org.
"It happens with firefox too.", how about in evince ?
As I said in comment #2, it happens in firefox too. I saw this morning that it also happens in evince. So I think the problem is in the cups' dialog, which I think is accessed through the api library.
That common dialog actually comes from GTK+.
Created attachment 329351 [details]
default printer patch
the problem is that Gtk+ takes the information about the default printer from the "printer-type" attribute. This can state that the actual printer is default for more than one printer (if there are some remote printers).
I added a test of remote destination to the code.
Patch is committed to the CVS of F10 and to the CVS of rawhide. I'll file this upstream.
That patch looks wrong.
I think what you really want to do is send a CUPS_GET_DEFAULT IPP request.
the CUPS_GET_DEFAULT IPP request is not used because we don't want to wait for the request. If we use the "printer-type" we have this information instantly with attributes of printers.
Otherwise there is a delay between showing list of printers and selecting the default printer.
What is wrong with this approach?
(except the remote default printer handling)
(local lpoptions, $LPDEST and $PRINTER are handled in the code)
In the case where there are two CUPS servers on the network both advertising a default printer, both of those printers will have CUPS_PRINTER_DEFAULT set in printer-type.
In the case where the default printer is connected to the local system, the CUPS_PRINTER_REMOTE bit will *not* be set in printer-type. There may additionally be a remote printer that has CUPS_PRINTER_DEFAULT set, but the default will remain the locally connected printer.
If you really want to avoid sending a CUPS_GET_DEFAULT IPP request, you'll have to first check to see if there is a printer where CUPS_PRINTER_DEFAULT is set but CUPS_PRINTER_REMOTE is not (i.e. a locally connected default printer, and if there is not, then you can check to find the first printer with CUPS_PRINTER_DEFAULT set.
In other words, it is not sufficient to only check the CUPS_DEFAULT_PRINTER bit, but neither is this check sufficient in itself:
+ if ((attr->values.integer & 0x00020000) &&
+ !(attr->values.integer & 0x00000002))
(i.e. checking for a locally connected default printer).
I *think* the rules I've detailed above are correct and cover all the cases, but I may have missed something.
We have to wait for the response to a CUPS-Get-Printers request anyway don't we? The vastly common case is that cupsd is running on the local machine, so it really doesn't add that much time before the dialog can be displayed (or at least, before a printer in the dialog is pre-selected).
The IPP request approach guarantees you'll be consistent with all the other tools.
(In reply to comment #11)
> Hi Tim,
> the CUPS_GET_DEFAULT IPP request is not used because we don't want to wait for
> the request. If we use the "printer-type" we have this information instantly
> with attributes of printers.
> Otherwise there is a delay between showing list of printers and selecting the
> default printer.
There's a long delay anyway (more than 5 seconds sometimes) between selecting the menu option and the dialog creation, for situations where some network printers connected to other computers and the computers are switched off. Looks like the dialog is testing for availability. I humbly think that what the dialog have to show is the same list of printers shown by system-config-printer when it's started, the available printers, and s-c-p is fast in getting that list, even when printers are offline because the computers are switched off.
Also, a couple of seconds more for an IPP request is not too much, and guarantees consistency.
Created attachment 329607 [details]
thank you for your advice Tim. I modified the patch accordingly.
Requests in Gtk+ are implemented with gdk_threads_add_timeout function to be able to call them in non-blocking way ( + connection test). This causes the delay of the second request.
is the delay, you are talking about, between click to "Print" and dialog show or between dialog show and populating the dialog with printers?
When populating the dialog with printers.
(In reply to comment #16)
> When populating the dialog with printers.
To reproduce the delay when opening the dialog:
1. 2 computers in a network with the same make and model of printer. Both shared and with different names.
2. In one of the two, the dialog will select the other computer's printer, even if the local printer is the default one.
3. Once you found the computer where the dialog select the wrong default printer, switch the other computer off.
4. Use File->Print in a GTK application (OO.o, firefox, etc.) and you will see the delay.
you are right. The delay is caused by testing of availability. The delay is longer because it is performed in a non blocking way.
This is an expected behaviour (considering that some of configured printers are not available).
Thank you for your comments
But take a look at system-config-printer in Fedora 10.
In the same situation, s-c-p is faster than the gtk+ dialog.
Is it possible to have it work that fast ?
If not, then selecting the correct default printer is enough for this bug.
gtk2-2.14.7-7.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.