Bug 1765328
Summary: | [RFE] gnome-control-center should handle cups temporary queues in some way | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Pierre-YvesChibon <pingou> |
Component: | gnome-control-center | Assignee: | Marek Kašík <mkasik> |
Status: | ASSIGNED --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | bugs.kde.attila, gnome-sig, juliusvonkohout, mihai, mixask8, mkasik, twaugh, walter.pete, zdohnal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | Type: | Bug | |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Pierre-YvesChibon
2019-10-24 20:31:38 UTC
Hi Pierre, thank you for reporting the issue! I'll underscore the questions in the text below, because it will be quite long :) Would you mind telling me your network topology? Because if the printer is in the same network as your machine, it would explain a lot. ------------------------------------------------ Let's assume it is true. CUPS, since aprox 2.2.0 IIRC, has a feature of CUPS temporary queues for IPP everywhere enabled printers - that means you do not need any print queue installation and no drivers for to be able to print. When you check 'lpstat -a' which usually shows you local print queues, there is nothing. And that's the correct behavior. The print queue will appear only when you really want to print - that means it will appear only when you are in print dialog of an application and it will disappear after successful printing. The problem is, not all apps are actually aware of/support this feature, because they use old CUPS API or someone's else API. The point is, from what I found out, LibreOffice is capable of CUPS temporary queues, but at least evince is not. That's all the case if the printer is in your local network. Other questions: ---------------- 1) What did you mean by 'installed'? There are several means of installation - GNOME printers, CUPS web ui, found by cups-browsed, system-config-printer, by command line... 2) Would you mind attaching ppd of the print queue which is created by app you used for installation? Tip: ---- If your printer supports ipp everywhere (it probably does, based on libreoffice behavior) and have port 631 opened, you can even create permanent print queue too, either by command (uri has common structure, but some vendors do not respect it, if it won't work, run 'sudo lpinfo -l -v' and use ipp uri found there): $ sudo lpadmin -p <your_print_queue_name> -v ipp://<IP or hostname of printer>:631/ipp/print -m everywhere or by CUPS web ui (when cups service is running) - choose 'Administration' -> 'Add printer' -> 'ipp printer' -> enter uri -> choose 'Epson' manufacturer -> model 'IPP everywhere'. I tried it only on network printer, I do not have usb ipp everywhere printer, so I'm not sure how it will work for usb printer with IPP eve. Sorry for the late reply. > Would you mind telling me your network topology? Because if the printer is in the same network as your machine, it would explain a lot. The printer is in the same house-network indeed. > What did you mean by 'installed'? There are several means of installation - GNOME printers, CUPS web ui, found by cups-browsed, system-config-printer, by command line... I have installed it via the GNOME UI for printer, so I guess GNOME printers. > Would you mind attaching ppd of the print queue which is created by app you used for installation? Happy to, do you know where I'll find it? ``lpinfo -l -v`` points me to: ```` 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 = ```` in > $ sudo lpadmin -p <your_print_queue_name> -v ipp://<IP or hostname of printer>:631/ipp/print -m everywhere Where/how can I define the value of <your_print_queue_name>? Can I pick anything or are there standard I should follow? Thank you for your detailed answer, the explanation you gave sounds quite close to the behavior I am seeing! (In reply to Pierre-YvesChibon from comment #2) > Happy to, do you know where I'll find it? You can find ppds in /etc/cups/ppd dir. > in > > $ sudo lpadmin -p <your_print_queue_name> -v ipp://<IP or hostname of printer>:631/ipp/print -m everywhere I'm sorry, I forgot you need to have '-E' at the end of command too. > > Where/how can I define the value of <your_print_queue_name>? Can I pick > anything or are there standard I should follow? It cannot contain symbols from the start of ASCII table to ' ' (space) included, '/', 'DEL' (symbol from ascii table at value 127) and '/'. > > > Thank you for your detailed answer, the explanation you gave sounds quite > close to the behavior I am seeing! Sorry for the response time. I have got the printer working nicely using: `` sudo lpadmin -p EPSON_WF_C5710 -v ipp://EPSONAB3686.local:631/ipp/print -m everywhere -E `` I can now print fine from evince, firefox without having to print an empty page in libreoffice first :) Thanks for your help. I don't know what we want to do about this ticket, technically we got things working but it feels like a workaround more than a proper fix, but I don't that this ticket is the right place to track the proper fix. What do you think/recommend? Hi Pierre, in my opinion gnome control center/evince/gtk should support cups temporary queues correctly instead of needing to add print queue as permanent. So I'll reassign the bug and change the component. Hi Pete, there is cups temporary queues feature in CUPS since 2.1.x and it would be good if gnome-control-center 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]. GNOME control center now supports those temporary queues in kind of way, which confuses users - it tries to install them with ppd found by scp-dbus-service instead of does not installing them at all or making temporary queue permanent. I have several ideas on my mind: 1) control-center will show temporary queues when user will search for printers, noting that they are temporary and if you will install them, you will make them permanent 2) control-center will show temporary queues by default when user opens 'Printers' tab - when user clicks on one of them, he will show that it is temporary queue and you can make them permanent (printing options for temporary queue are available only during printing dialog, so options in GNOME control center should be unavailable) 3) ignore such queues 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, mkasik works on the printers support, not me. Reassigning. *** Bug 1567984 has been marked as a duplicate of this bug. *** *** Bug 1910013 has been marked as a duplicate of this bug. *** *** Bug 2221364 has been marked as a duplicate of this bug. *** |