search

OpenPrinting / cups

OpenPrinting CUPS Sources
https://openprinting.github.io/cups
Apache License 2.0
1.04k stars 187 forks source link

Confusing user experience due to delay in generation of PPDs for IPP everywhere. #347

Closed VorpalBlade closed 5 months ago

VorpalBlade commented 2 years ago

Split out from issue OpenPrinting/cups#340 and issue OpenPrinting/cups#343 as a separate issue:

When adding an IPP everywhere printer, via web UI or lpadmin it first appears as a raw printer. Then in the background it is converted into the proper printer, for my printer this took about 15-45 seconds (seems to vary from run to run). This seems problematic and potentially confusing to users.

In addition when adding a printer via the web UI and selecting the discovered IPPS (via mdns for example) printer: The last step of the "wizard" is to set default printer options. As the printer is still a raw printer at this stage, the only options available are banner pages and policy. This is also a confusing user experience, having to wait a bit and then go back into the printer settings to set page size etc.

According to @michaelrsweet:

Unfortunately, the current implementation of cupsd is essentially single-threaded. The whole "resolve and generate the PPD in the background" trick can't be done in the (main) IPP request processing thread, so there is no way with the current implementation to delay a response to the CUPS-Add-Modify-Printer request. But we might be able to do something in admin.cgi to special-case the IPP Everywhere driver and wait until a PPD is found. If you can file a separate bug on that specifically I'll see what can be done...

Note that special casing web GUI seems fine (presumably an user using lpadmin is more knowledgeable?). However, the most common case is probably an user adding the printer via Gnome settings or similar (I presume KDE has such a settings panel too? Cinnamon (which I use) just uses system-config-printer, which appears to be DE agnostic). For this reason I did some experiments with the GUI options I had installed. Here is what I found:

system-config-printer

It thus seems this case already works fine, it simply doesn't need the delay at all (for the one case where I could select IPP Everywhere).

Gnome printer settings

Gnome-system-settings apparently depend on system-config-printer in order to have a somewhat dumbed down Printers tab in it's settings?

It simply seems to always select the "Fax, driverless, cups-filters" driver no matter what I do, so I have not been able to test it's behaviour with IPP Everywhere.

Ghost printer?

Gnome printer settings display the printer one extra time without a local queue created (as "HP_Color_LaserJet_MFP_M281fdw_Home"). This instance is however completely broken:

This extra "printer without the local queue" also shows up in for example okular's print dialog. It is broken there too and does nothing and has not available printer options. This seems more like issue OpenPrinting/cups#343 reoccurring in a new variant? Should I open a new bug about this?

Software versions

zdohnal commented 2 years ago

Hi @VorpalBlade ,

I'll put a background here regarding printer installation tools.

Currently (with some exceptions like default Firefox and Chrome dialogs, PCLm only printers) desktop users don't need to install their relatively new (about 2010+ for network printers, USB printers about 2012+ or so, when they started to support IPP-over-USB) personal printers permanently in common home environment (printer is connected to a PC via USB or network printer is in local network) - they can use a temporary queue, which appears right you open a print dialog, you print to it and the queue disappears after successful printing. Additionally, CUPS Local server (CUPS will be split into modules in 3.0 - local server is a daemon tailored for desktops), which is supposed to be default on desktops, won't support permanent queues.

Permanent queues can be useful on servers or in enterprise environments, where company doesn't want to have printers in the same network as users. This type of queues, together with CUPS Web Interface, will be available in CUPS Sharing server. IMO permanent queues will be there for more experienced users, which care about different printing defaults etc.

To sum it up, common users are expected to use temporary queues - so what does it mean for current configuration tools?

GNOME control center took an approach to show temporary queues in the tool itself - that's the ghost printer you've seen - gnome-settings-daemon, the daemon which runs under the control center - actually checks mDNS messages directly and creates the entry based on them. However, it send requests to CUPS about it (like printing a test page), thinking it exists in CUPS, but it doesn't until a specific function is called, iirc it is cupsCopyDestInfo() or cupsEnumDests() or IPP request IPP_OP_CUPS_CREATE_LOCAL_PRINTER is sent - the last happens in the actual GTK print dialog, where the queue itself works because GTK sends the IPP request. IMHO sending the request from control center is redundant, because most times you are not printing from there. I'd talked with Control Center devs and I've suggested a different naming for their entries, so users would be able to tell it is a temporary queue, which will be fully available in the print dialog, but it hasn't been implemented yet or they've scratched it.

System-config-printer itself ignores temporary queues and works only with permanent ones.

There were been talks about printer configuration tools on the printer-architecture mailing list and during annual PWG & OpenPrinting meetups - it crystalized into two ideas:

A) configuration for older printers can be part of print dialog, and classic configuration tools won't be needed - CUPS and printer applications provides their web interfaces if needed B) configuration tools will be migrated to work with IPP services and printer applications

I'm a supporter of A) here.

* Their native print dialogs currently don't support temporary queues feature - I've asked Fedora Firefox maintainers to leverage this upstream...

** PCLm-only printers are currently supported only in PPD generator from cups-filters, so you need to install a permanent queue by hand using 'driverless', or run cups-browsed for such printers.

*** Older printers which don't support any driverless standard (Airprint, IPP Everywhere, Mopria, Wifi Direct, IPP-over-USB) can be supported by printer applications (which makes them look like they support IPP Everywhere) and OpenPrinting group have already covered common drivers by new printer application

@michaelrsweet Mike, do I guess correctly we can use select on the PPD file and delay lpadmin/Web UI until PPD is in place?

VorpalBlade commented 2 years ago

@zdohnal If that "ghost printer" is a temporary queue, the next question (and likely separate bug) is why it doesn't actually work. And why it has no print options etc.

Also, how on earth are temporary queues supposed to work when auto discovery doesn't work, such as printing to a printer on a different subnet? I'm in that situation at my work at university. Linux support is non-existant, only some of us at comp-sci use self-administrered laptops with Linux. Someone (probably not IT, no one knows for sure?) figured out printing there can be done from linux using a specific lpd:// URI, a specific PPD from the printer manufacture website and setting the CUPS_USER environment variable. Presumably this is connected to a printer server as you can then log in on any printer with your badge to print things. The printer queue only accepts postscript, not PDF (I tried messing with the PPD to get better results that would prevent rasterisation and blurry text on pages with certain types of vector graphics, I got nowhere). For printing from mobile devices they have their own proprietary app.

The driverless & configurationless future sounds nice in theory. But a lot of people care about their existing hardware continuing to work, or have no control over the setup at workplaces. Will this be supported via "printer applications" by the time that legacy printing is removed? Will the legacy CUPS be packaged as one of those printer applications to solve this? I have been looking for any sort of roadmap on this on the CUPS website or in this repo and found nothing. I think clearly communicating the plans would help a lot. Your answer above addressed some of this, in generic terms. But a clear roadmap or FAQ about this might not be a bad idea.

I assume it is still quite a ways away since the current state seems quite unreliable. (But again, I haven't seen any information about a timeline at all.)

Also also: What exactly do you mean by "printer configuration" above? Do you mean settings such as duplex/colour/number of copies? Or the type of settings I can adjust in the web UI of my printer (admin & network settings)? Or something else? How do I save default settings for my temporary queue printer, like the page size being A4? Will it be remembered next time I reconnect to that printer?

debiantriage commented 2 years ago

I think clearly communicating the plans would help a lot.

@VorpalBlade You may find OpenPrinting/cups-local#2 informative and heartening as regards the future direction of CUPS.

An excerpt from that issue

@zdohnal So the point of my "profiles" featurette in my CUPS slides was not to provide a way to further inject PPDs into the system but to provide a simple way for enterprises to configure/deploy IPP Everywhere queues (pointed at real printers, a central CUPS server, etc.) when mDNS/DNS-SD wasn't feasible - basically duplicating what Apple has done for iOS/iPadOS/macOS and what hundreds of users have been asking for over the years on Linux (re: supporting multiple ServerName directives in client.conf).

-- Brian.

VorpalBlade commented 2 years ago

@debiantriage Thanks, that answers part of the question yes. Still there is no comprehensive answer anywhere (that I managed to find anyway), just bits and pieces spread out in various places.

Also, from that bug it isn't clear if this would only work with remote IPP servers or also with more legacy servers (like the one I'm stuck with at the university). I assume it will be possible to combine this with printer applications somehow in case your remote server is not an IPP one but requires a PPD?

The question is if someone will create a printer application for the printer you are interested in. It seems unclear to me. Also unclear why multiple printer applications are needed: Couldn't you just package up legacy cups as a generic "legacy printer application"? Wouldn't that be less effort than separate printer applications while at the same time guaranteeing anything currently supported won't be dropped. Otherwise there seems to be a real risk dropping support for less popular hardware.

Is there anywhere I can find a list of planned printer applications and what they will support? And what will end up not being supported unless some enthusiast steps up and does the work?

debiantriage commented 2 years ago

I assume it will be possible to combine this with printer applications somehow in case your remote server is not an IPP one but requires a PPD?

@VorpalBlade We hope you took a glance at https://ftp.pwg.org/pub/pwg/liaison/openprinting/presentations/cups-plenary-may-2021.pdf. I think the planned Sharing Server plus a Printer Application is intended for the use case you wish to be handled.

Printer Applications in the pipeline are at https://github.com/OpenPrinting. I thlnk they cover most existing free PPDs and drivers. A single package would be very large!

michaelrsweet commented 2 years ago

@VorpalBlade The profile stuff would only work with IPP servers and printers. LPD is a legacy protocol that you'd need some sort of printer application for - @tillkamppeter has done a printer application to support PostScript printers with PPDs, so maybe you can ask him to add LPD support to that application?

tillkamppeter commented 2 years ago

When I created pappl-retrofit and the 4 driver retro-fitting Printer Applications I assumed that the printers to be supported by the Printer Applications are physical printers connected by USB or network. For this the usb and socket (CUPS and PAPPL) backends are usually good enough, as network printers have the socket (port 9100) interface and that is easier to handle than LPD or legacy IPP (1.x, non-driverless).

I did not take into account print servers, computers (or network appliances) which make printers available in a network. If they are old enough they are LPD servers, nothing more, LPD on port 515. For this I could add the lpd CUPS backend to the Printer Applications, but in many (in most?) cases LPD servers are not auto-discoverable, as they do not necessarily advertise themselves via DNS-SD. Actual printers probably do (but do the oldest ones already?), but then they are also capable of receiving jobs via socket. So we need to allow to enter the IP or hostname (and perhaps also the port) manually in the Printer Application's web interface. Here I am not sure whether PAPPL's support for custom backends/devices supports that. This would be essential for adding correct LPD support with the lpd CUPS backend covering the LPD print servers in question.

If custom devices in PAPPL only support fully automatic mode (discover discrete devices and list them, then pick desired device from list) I will not be able to add support for LPD to my Printer Applications. I did not investigate yet whether PAPPL supports manual parameter input for custom devices.

Note that the "Hostname/IP Address" field on the "Add Printer" web interface page of the PAPPL-based Printer Applications is used for the (always available) choice "Network Printer" under "Device" and is for manually add a printer accessed via socket on port 9100.

tillkamppeter commented 2 years ago

And LPD usually also needs a queue name on the server, so manual LPD queue setup would need 2 parameters, host name/IP address AND queue name.

VorpalBlade commented 2 years ago

@debiantriage No, I had not found that. Thanks.

@tillkamppeter The lpd server I need is indeed not auto discoverable, and need CUPS_USER set to send a different user name than I have on my computer. So that may be 3 parameters if CUPS_USER won't be supported in the future. If it is not something that can be supported I will simply have to stick with an outdated cups indefinitely. Not sure if that will work without conflicting with system libraries etc though...

zdohnal commented 2 years ago

To sum the things up which are problematic in CUPS since moving local printer installation into background thread and has to be tackled in the future:

michaelrsweet commented 5 months ago

[master 8dda6c2b2] Update CUPS-Add-Modify-Printer and CUPS-Create-Local-Printer code to delay responding until the PPD is successfully generated (Issue #347)

michaelrsweet commented 5 months ago

[2.4.x df3718b09] Update CUPS-Add-Modify-Printer and CUPS-Create-Local-Printer code to delay responding until the PPD is successfully generated (Issue #347)

andreas-karlson commented 5 months ago

FYI - this bug-fix introduces the following bug: https://github.com/OpenPrinting/cups/issues/934