Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#75246 - Autodiscovered driverless printers do not appear in Qt print dialog
Attached to Project:
Arch Linux
Opened by Sergio Callegari (callegar) - Tuesday, 05 July 2022, 08:22 GMT
Last edited by Antonio Rojas (arojas) - Friday, 29 July 2022, 06:56 GMT
Opened by Sergio Callegari (callegar) - Tuesday, 05 July 2022, 08:22 GMT
Last edited by Antonio Rojas (arojas) - Friday, 29 July 2022, 06:56 GMT
|
DetailsDescription:
Cups supports autodiscovery of network printers supporting driverless operation. This is increasingly important in office environments as large shared printers and multifunction devices more and more often only support driverless operation for linux. Using autodiscovered printers is generally possible in arch. In KDE they correctly appear in the "system settings" "Printers" page. Most applications print just fine on these autodiscovered printers (e.g. libreoffice, gimp, etc.). Unfortunately, it is impossible to print on these autodiscovered printers from Qt applications, because the Qt print dialog does not list these autodiscovered printers among the possible destinations, so it is not possible to target them for printing. This is a problem affecting all KDE applications including okular, kate, etc. The issue is not present on other distros (e.g., ubuntu 22.04). Additional info: Qt 5.15.5 Steps to reproduce: 1. activate `cups-browsed` if not active 2. check that you have some auto-discoverd printer in the system settings printers page or accessing localhost:631 3. open a document in okular 4. Pick print from the file menu 5. Observe the print dialog opening and note that the auto discovered printer is not there, so you cannot print on it |
This task depends upon
Closed by Antonio Rojas (arojas)
Friday, 29 July 2022, 06:56 GMT
Reason for closing: Fixed
Additional comments about closing: qt5-base 5.15.5+kde+r174-1
Friday, 29 July 2022, 06:56 GMT
Reason for closing: Fixed
Additional comments about closing: qt5-base 5.15.5+kde+r174-1
Now what is unclear is what arch does in this sense. IMHO, a way to enable the listing of autodiscovered printers in Qt applications should be introduced (or just documented if it is already there), otherwise users won't be able to print at all in certain office environments. I also suggest enabling the listing of autodiscovered printers by default, letting experienced users opt-out (rather than the other way round), otherwise Qt applications are inconsistent with anything else.
I have questioned people at openprinting and this is what they say toghether with some considerations of mine:
- cups developers say the list of available printers should be obtained via the the `cupsGetDests` and `cupsEnumDests` APIs that also report auto discovered printers. These should be used together with the corresponding CUPS APIs that handle creating a temporary print queue (for the auto-discovered printers) as needed. This is the recommended way. I suspect that some patched version of the Qt print dialog were probably doing it differently, so the delay.
- one of the reasons for *not* showing the autodiscovered printers (apart from the delay) is that in certain environments the print dialog may end up with a list of printers that is huge or very messy. Clearly, installing locally only the interesting printers and not showing the autodiscovered ones avoids this (and indeed only shows the interesting printers!). However, this has two major disadvantages: it does not work for those printers that can print driverless and so do not have drivers for linux; and it does not work well in environments where printers get routinely replaced with different models (e.g. because of leasing) without giving proper notice about the new ones and their drivers, so that trying to print, realizing there is a different printer, having to interrupt whatever task was done to install the new one looking for the drivers is not nice. The cups people say that the issue of the messiness of the printers list should be solved using *filters*, that unfortunately do not yet have a nice GUI for configuration.