Bug 478400

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.

thanks

Domingo Becker

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

Hi,
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.

  Thank you

    Marek

That patch looks wrong.

I think what you really want to do is send a CUPS_GET_DEFAULT IPP request.

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.
What is wrong with this approach?
(except the remote default printer handling)
(local lpoptions, $LPDEST and $PRINTER are handled in the code)

  Regards

    Marek

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[0].integer & 0x00020000) &&
+               !(attr->values[0].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.

kind regards

Created attachment 329607 [details]
modified patch

Hi,
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.

  Regards

    Marek

Hi Domingo,
is the delay, you are talking about, between click to "Print" and dialog show or between dialog show and populating the dialog with printers?

  Regards

    Marek

Hi Marek,

When populating the dialog with printers.

regards

(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.

regards

Hi Domingo,
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

    Marek

Hi Marek,

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.

regards

Domingo Becker

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.