Hi, there is cups temporary queues feature in CUPS since 2.1.x and it would be good if evince was able to work with them. What is cups temporary queue? ----------------------------- It is a queue, which is designed to show up only when an user needs it - during printing dialog. It disappears after successful printing. This feature is supported by most printers released 2010 and newer and it uses IPP 2.0 protocol for getting all needed information about printer (instead of installing ppd file) and Avahi for discovering printer. How to find out that printer supports such behavior: ---------------------------------------------------- You can f.e. see it in output of 'sudo lpinfo -l -v': Device: uri = ipp://EPSONAB3686.local:631/ipp/print class = network info = EPSON WF-C5710 Series (driverless) make-and-model = EPSON WF-C5710 Series device-id = MFG:EPSON;MDL:WF-C5710 Series;CMD:PWGRaster,AppleRaster,PWG,URF,JPEG; location = or you can see it by 'lpstat -e'. You can ask for it through CUPS API - more info[1]. Libreoffice already supports this feature correctly, so you can see how the process should look like. Evince currently shows the temporary queue named 'print' which is not working. Would you mind coordinating with upstream and finding out how it should be solved? [1] https://www.cups.org/doc/cupspm.html#finding-available-destinations
Hi Zdenek, I believe, that his should work in current gtk 3.24 upstream. I've finally pushed fixes for this last week. Could you try whether the 2 commits fixes the bug for you? https://gitlab.gnome.org/GNOME/gtk/commit/725892b65362956ef40752dc446cd3dab248a444 https://gitlab.gnome.org/GNOME/gtk/commit/fb2fa8348d87024d94905ed94f9f78149726df88
Nice, thank you! I'll check it this week.
Hi Marek, I'm sorry for the delay - I hope you enjoyed the holidays. I backported commits you mentioned and commit https://gitlab.gnome.org/GNOME/gtk/commit/58cfa3fd4956332797f0dd35563cdccb1e0323ea into gtk3 for Fedora 30, built and installed gtk3, gtk3-devel and gtk-update-icon-cache packages (the ones I had installed before testing), but printing does not work. The job is not created in cupsd at all (did not receive any Create-Job or Print-Job requests which initiate jobs). From the logs, gtk is using CUPS-Get-Printers request which is deprecated for this use case. It returns only locally created permanent queues and does not work for temporary queues - IPP request Get-Printer-Attributes and using destinations works for both cases - for permanent and temporary queues. I'm attaching cupsd log for evince (you can see only Get-Printers requests) and for Libreoffice, which is not following exactly CUPS programming manual (does not use cupsEnumDests, but uses Create-Local-Queue request, which does the trick before sending Get-Printer-Attributes) but it does the trick too.
Created attachment 1649331 [details] cupsd log for evince
Created attachment 1649332 [details] cupsd log for libreoffice
Hi Zdenek, thanks for testing this. I search for the printers via Avahi itself so I don't use CUPS' functions for listing printers. And for printing I connect directly to the remote printer not creating a print job via local CUPS server (but using CUPS for this). Did you use a remote printer for the test or a remote CUPS server? The remote CUPS' logs could shed some light on this.
My printer is in my local network. My laptop has access to it, it is visible via Avahi, but cups-browsed is turned off - so I do not have any cupsd log from server and AFAIK my printer does not have any logs in its web interface. IMO Gtk should be able to see and print to IPP eve printer even without cups-browsed running i.e. be able to support cups temporary queues, because it confuses users. > I search for the printers via Avahi itself so I > don't use CUPS' functions for listing printers. And for printing I connect > directly to the remote printer not creating a print job via local CUPS > server (but using CUPS for this). Unfortunately, your steps do not work for temporary queues, because you do not have any queue in CUPS which you are trying to connect to. IMO you could create it by that Create-Local-Queue request and then connect to it (like libreoffice does it), or use CUPS destinations. When you turn on cups-browsed, it creates local permanent queue based on Avahi response and this queue works - the downside of this you need to have cups-browsed running.
I'm sorry for the obvious question :). Isn't it blocked by firewall or something on your network? What information about the printer do you get from avahi-discover tool (for ipp or ipps services)? (all the TXT and other fields)
Np, I'll check it when I'll be WFH.
(In reply to Marek Kašík from comment #8) > I'm sorry for the obvious question :). Isn't it blocked by firewall or > something on your network? Hmm... I have mdns and ipp enabled in my firewall and I can ping the printer and connect to port 631. > > What information about the printer do you get from avahi-discover tool (for > ipp or ipps services)? (all the TXT and other fields) Service Type: _ipp._tcp Service Name: HP LaserJet M1536dnf MFP (42307C) Domain Name: local Interface: enp0s25 IPv4 Address: NPI42307C.local/192.168.1.112:631 TXT priority = 10 TXT adminurl = http://NPI42307C.local. TXT rp = ipp/printer TXT UUID = 434e4239-4243-4a42-5859-3c4a9242307c TXT Scan = T TXT Duplex = T TXT ty = HP LaserJet M1536dnf MFP TXT product = (HP LaserJet M1536dnf MFP) TXT note = TXT Color = F TXT pdl = application/postscript,application/vnd.hp-PCL,application/vnd.hp-PCLXL,application/pdf,image/urf TXT URF = CP99,W8,OB10,PQ3-4-5,DM1,IS1-4,MT1-2-3-5,MT1-2-3-5,RS600 TXT qtotal = 1 TXT txtvers = 1
But I have tp-link router between laptop and printer - but it is in the same network and accessible via Avahi, so I don't know what else should block communication needed by gtk.
I'm looking at this issue right now. I have a printer here on which I can reproduce it. It seems that there are places where wrong resource path was used inside gtk. But I'm facing another issue. Once I send the print data to the printer via IPP_PRINT_JOB the connection is reset.
It is reset from cupsd side or the printer side? According IPP specification, cupsd should get an response from printer after whole print job is done. Upstream IPP implementator guide: https://ftp.pwg.org/pub/pwg/candidates/cs-ippig20-20150821-5100.19.pdf How to use IPP: https://www.pwg.org/ipp/ippguide.html
It seems that the connection is reset from the printer side. I'm looking at this in wireshark now so it will hopefully help. I'll compare it with an Avahi browsed printer from a CUPS server. Btw, it is HP LaserJet Pro MFP M127fw.
I see that there is TCP Window Full signalized by wireshark, then there is several TCP ZeroWindow and TCP Keep-Alive and then there is RST (probably the reset). So the window is small at that time and for some reason the printer reset the connection. I've tried different router here to see whether it could be something with rejecting keep alive messages but it seems not (and the router is not advanced enough to let me configure this). I've also checked size of this window for the file descriptor given by httpGetFd() but the window doesn't seem 0. But maybe I'm missing something here as I'm not expert over networking. Btw, I'm not even able to print using ipptool on this printer but the issue I have there it does not accept the document format I'm passing to it. The printer advertises support for "image/urf,application/PCLm,image/jpeg".
Even if I try "ipptool -v -t ipp://192.168.1.102/ipp/print ./create-job.test" it fails. It creates the job but Send-Document fails with 0 bytes in response. There is something wrong with the printer probably. Maybe it works with Air-Print/Bonjour only (but declares itself on _ipp._tcp).
Created attachment 1671483 [details] fix for some issues Hi, could you try the attached gtk3 patch on top of the one you've tried before? It could solve some issues with printing. Unfortunately, I'm not able to print with it but maybe you will.
Unfortunately, the patch does not work for me neither. The print dialog is still stuck when I click on the queue, message 'Getting printer information' appears and dialog is loading indefinitely after that. After clicking on the queue following messages appeared in the terminal: (evince:334522): GLib-GObject-CRITICAL **: 07:23:04.898: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (evince:334522): GLib-GObject-CRITICAL **: 07:23:34.286: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (evince:334522): Gtk-CRITICAL **: 07:23:56.713: gtk_list_store_set_valist: assertion 'GTK_IS_LIST_STORE (list_store)' failed Printing via libreoffice with temporary queue still works. I'm planning to implement a simple client which will use only CUPS API and check if it works this way too. If it will work, are you okay if I'll try to implement it in GTK code and possibly reviewing and merging the future patch?
(In reply to Zdenek Dohnal from comment #18) > Unfortunately, the patch does not work for me neither. The print dialog is > still stuck when I click on the queue, message 'Getting printer information' > appears and dialog is loading indefinitely after that. > > After clicking on the queue following messages appeared in the terminal: > > (evince:334522): GLib-GObject-CRITICAL **: 07:23:04.898: g_object_unref: > assertion 'G_IS_OBJECT (object)' failed > > (evince:334522): GLib-GObject-CRITICAL **: 07:23:34.286: g_object_unref: > assertion 'G_IS_OBJECT (object)' failed > > (evince:334522): Gtk-CRITICAL **: 07:23:56.713: gtk_list_store_set_valist: > assertion 'GTK_IS_LIST_STORE (list_store)' failed Thank you for trying it. Could you try to print to it with "GTK_DEBUG=printing gtk3-demo" and send me the log? It should tell us how far it got. > > Printing via libreoffice with temporary queue still works. > > I'm planning to implement a simple client which will use only CUPS API and > check if it works this way too. We use a specific approach to execute CUPS requests because of non-waiting behaviour so it depends on which API you would use. > If it will work, are you okay if I'll try to implement it in GTK code and > possibly reviewing and merging the future patch? I'm still not sure whether to use this approach. Current implementation should support printing on such printers (except storing of the history) so the current situation is a bug which I would like to fix at first. But if it shows that it is not fixable then we can think about this. Does "ipptool" with "create-job.test" or "print-job.test" work for you with the printer?
Created attachment 1690090 [details] gtk debug gtk3-demo is a nice tool, thanks! Here are the logs. My printer doesn't support Send-Document operation (according to get-printer-attributes request): $ ipptool -tv ipp://NPI42307C.local/ipp/printer get-printer-attributes.test ... operations-supported (1setOf enum) = Print-Job,Print-URI,Validate-Job,Create-Job,Send-URI,Cancel-Job,Get-Job-Attributes,Get-Jobs,Get-Printer-Attributes ... so I can test only Print-Job operation: ipptool -tv ipp://NPI42307C.local/ipp/printer -f <file_to_print> print-job.test "/usr/share/cups/ipptool/print-job.test": Print-Job: attributes-charset (charset) = utf-8 attributes-natural-language (naturalLanguage) = en printer-uri (uri) = ipp://NPI42307C.local:631/ipp/printer requesting-user-name (nameWithoutLanguage) = zdohnal document-format (mimeMediaType) = application/pdf copies (integer) = 1 Print file using Print-Job [PASS] RECEIVED: 182 bytes in response status-code = successful-ok (successful-ok) attributes-charset (charset) = utf-8 attributes-natural-language (naturalLanguage) = en job-uri (uri) = ipp://NPI42307C.local/ipp/printer/0039 job-id (integer) = 39 job-state (enum) = pending job-state-reasons (keyword) = none and the file is printed correctly.
It looks like an infinite loop in gtk3 according logs. I stopped it after a while.
Hi Marek, I have new printer 'Canon i-SENSYS MF443dw' and there is the same issue as described here systemctl stop cups-browsed lpstat -e Canon_MF440_Series lpstat -a lpstat: No destinations added. so evince with gtk has queue but its not working ~ 'gathering info about printer' and gray not functional 'print' button. Libreoffice can print. Is there anything how can I help to have this bug fixed ?
Hi Petr, which version of Fedora do you use? Could you paste results of "avahi-browse -rt _ipp._tcp" here?
Hi Petr, could you try whether scratch build of gtk3 from https://koji.fedoraproject.org/koji/taskinfo?taskID=56246930 helps with the issue?
no :( unfortunately not cups-2.3.3-18.fc32.x86_64 gtk3-3.24.23-2.fc32.x86_64 evince-3.36.7-1.fc32.x86_64 firefox-83.0-3.fc32.x86_64 so I did: systemctl stop cups-browsed; cancel -a; lpadmin -x Canon_MF440_Series; [root@localhost ~] # lpstat -t scheduler is running no system default destination lpstat: No destinations added. lpstat: No destinations added. lpstat: No destinations added. lpstat: No destinations added. [root@localhost ~] # lpstat -a lpstat: No destinations added. [root@localhost ~] # lpstat -e Canon_MF440_Series firefox > ctrl +p > click to canon and there were still 'waiting and waiting and waiting' 'print' is still gray I could double click to the printer and it generatess log in journal AND print dialog that page is going to be print [root@localhost ~] # journalctl -f | grep gtk Nov 26 09:32:03 localhost.localdomain firefox[3838]: gtk_list_store_set_valist: assertion 'GTK_IS_LIST_STORE (list_store)' failed Nov 26 09:32:25 localhost.localdomain firefox[3838]: gtk_list_store_set_valist: assertion 'GTK_IS_LIST_STORE (list_store)' failed Nov 26 09:32:29 localhost.localdomain firefox[3838]: gtk_list_store_set_valist: assertion 'GTK_IS_LIST_STORE (list_store)' failed Nov 26 09:32:37 localhost.localdomain firefox[3838]: gtk_list_store_set_valist: assertion 'GTK_IS_LIST_STORE (list_store)' failed BUT NOTHING [root@localhost ~] # lpstat -t scheduler is running no system default destination lpstat: No destinations added. lpstat: No destinations added. lpstat: No destinations added. lpstat: No destinations added. [root@localhost ~] # lpstat -e Canon_MF440_Series [root@localhost ~] # lpstat -a lpstat: No destinations added. [root@localhost ~] # lpq lpq: Error - no default destination available. [root@localhost ~] # lpq -a no entries
Hi Marek, I have a slightly different results - in my case loading of attributes ends in a while (though gtk still constantly bombards cupsd with Get-Printers requests on non-existing print queue) but if I click on 'Print', a print job isn't created. It has the similar behavior as in comment #4.
Hi, I've prepared a patch which adds the support for the temporary queues. You can test it in these scratch builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=56709683 (Fedora 32) https://koji.fedoraproject.org/koji/taskinfo?taskID=56709673 (Fedora 33) It is not finished yet since it needs more testing, removing of some redundant code and handling of some corner cases.
Hi Marek, thanks for the scratch builds! I'm able to print via temporary queue now smoothly! Would you mind attaching the patch once it's finished? I would like to see the implementation for the future reference.
*** Bug 1908134 has been marked as a duplicate of this bug. ***
Findings from #1908134: GTK shouldn't send a 'Delete-printer' request for a print queue which GTK finds via Avahi, unless GTK didn't make the queue permanent afterwards. It causes useless errors, because the queue doesn't exist in CUPS (because temporary queues aren't saved in cupsd).
Hi, the change has been merged upstream. You can find it in gtk 3.24.25 and also current master of gtk 4 upstream.
Thank you for all the work, Marek! It works perfectly!