Print queue eventually installed but printer invisibleon the network

[debiantriage]

Adding a print queue to the gutenprint Application seemed to be straightforward:

root@test-new:~# gutenprint-printer-app devices
snmp://NPI2CA3D7
usb://EPSON/Stylus%20Photo%20RX420?serial=LJ4O40407152301540

gutenprint-printer-app add -d RX420 -m epson--stylus-photo-rx-420--en -v usb://EPSON...

The response was

gutenprint-printer-app: Unable to add printer: Unsupported smi55357-device-uri uri value.

I looked at the stae file after using the web interface and altered the URI to cups:usb://EPSON... and the queue was added successfully. What is going on here?

Continuing:

root@test-new:~# lpstat -e
ENVY4500
root@test-new:~#

No sign of the printer until systemctl restarts the gutenprint-printer-app service. Why can this not be done automatically on successful queue installation?

[tillkamppeter]

This looks like that you Printer Application did not correctly do the Avahi registration the first time you started it. After the restart it did and therefore the printer got visible. I do not know why on the first start the Avahi registration failed.

Normally, you do not need to restart a PAPPL-based Printer Application after adding a printer. On its very first start, when there is still no printer added, it should already register at Avahi. avahi-browse and avahi-discover should already show entries for the web interface and IPP System Service interface of the Printer Application. If so, if you add a printer, it will also appear immediately, as "Internet Printer" (IPP), "Secure Internet Printer" (IPPS), and "UNIX Printer".

When you use the command line to add a print queue, put the URI in single quotes. It contains many characters which get messed up by the shell

gutenprint-printer-app add -d RX420 -m epson--stylus-photo-rx-420--en -v 'usb://EPSON...'

[tillkamppeter]

Also there is a bug in the CUPS package in Debian and also in Ubuntu 22.10 which prevents the Printer Application from correctly working (at least the web interface does not work);

• https://launchpad.net/ubuntu/+source/cups/2.4.2-1ubuntu4
• http://launchpadlibrarian.net/650318292/cups_2.4.2-1ubuntu2_2.4.2-1ubuntu4.diff.gz

The links show my fix in the Ubuntu package. ./configure must be called with --with-tls=gnutls and not any more with --enable-gnutls.

[debiantriage]

Ok. Thanks. I'll look into this a bit more. However, what is the the significance of

-v cups:usb://EPSON...

as opposed to

-v usb://EPSON...

The first form is implemented by the web UI and works. The second form doesn't work. I did try double and single quotes round the URU - with no effect.

[tillkamppeter]

pappl-retrofit supports both the backends which come with PAPPL and any CUPS backends. The PAPPL backends have the schemes usb:, socket:, ... and to support the CUPS backends one needs to add custom backends to the PAPPL-based Printer Application. A custom backend has a custom scheme. So I created a custom umbrella backend with the scheme cups:. The scheme name always ends with a colon, an URI starts with the scheme and after the colon it is completely to the backend which syntax the rest of the URI has.

So I created the custom scheme cups: to support the CUPS backends. The syntax for the URIs is simple, cups: plus the original URI of the CUPS backend. so

-v cups:usb://EPSON...

means that the "usb" backend of CUPS is used by the Printer Application, and

-v usb://EPSON...

means that PAPPL's built-in "usb" backend is used.

Which backends are available through the cups: scheme depends on which backend executables are in the directory where the Printer Application is searching and also on the Printer Applications configuration settings as there one can use an include list and an exclude list for backends.

The Legacy Printer Application of pappl-retro-fit for example should make all classically installed CUPS drivers available as Printer Application, therefore it points its search directory for CUPS backends to /usr/lib/cups/backend/ to have the same backends available as CUPS has.

With all this pappl-retrofit can also retro-fit classic CUPS printer drivers which come with their own backends.

[tillkamppeter]

If you do not get the URIs cleanly submitted into the Printer Application via the command line interface, there is probably a bug in PAPPL. You need to report it there with a debug log of the Printer Application attached.

[tillkamppeter]

I have fixed michaelrsweet/pappl#253, as michaelrsweet/pappl#262 so the bug is actually in PAPPL and therefore I am closing this bug report.