On 18/09/2021 22:30, Daniel Haid wrote:
The entry is not in the 'lpstat -t' output. You are not using the Brother drivers too, are you? I'm without a good idea here.No, but I have read that the GTK printing dialog does its own searching for IPP everywhere printers and moreover only sends PDF to the printer. Maybe the problem is that my printer does not support PDF.
If the GTK dialog does this, you should report it to GTK as a bug. IPP printers advertise themselves via DNS-SD (this way the dialog finds them) and in the DNS-SD record they tell what exactly they support, especially which job data formats. So the print dialog should not send blindly PDF to any IPP printer.
Driverless IPP does not include by default the capabilities of spooling and of understanding PDF. Therefore we need CUPS. It spools print jobs and converts data formats. So a print dialog should print through CUPS and not directly to IPP devices.
Anyway, do this: lpadmin -p L2550 -v URI_FROM_PREVIOUSLY -E -m everywhere > and print to the L2550 queue.I did it and now the error message in the log file does not appear anymore. The error still appears when using the old queue. But what is the difference between the queues? Should the command above not be what cups-browsed runs when it finds a printer?
cups-browsed does not do exactly the same. cups-browsed does not only create single queues for single printers. it has the capability of creating printer clusters, for distributing high amounts of jobs in a load-balanced group of (usually equal) printers (what CUPS did before version 1.6, the clusters being called classes), or, for having a queue which by the job option settings passes on the job to the most suitable of (typically completely different) printers.
For the latter use case, having completely different printers in a cluster, each member printer would need a completely different filter chain (at least the filters after pdftopdf) as the printers use different types of drivers. The queue which cups-browsed creates on CUPS has only one PPD file where the options are merged from the member printer's PPDs and the final data format to send off to the backend is always PDF. The backend is cups-browsed's own "implicitclass" then.
This backend asks cups-browsed to check the option settings and to determine the cluster member(s) which can fulfill them, to select one of the suitable printers, and tell which final data format the printer needs. The backend then passes the print data through filters to convert the data into the member printer's final format and send the job off to the printer.
Due to this technique filter chains can vary between a cups-browsed-generated queue and a manually created queue. We will need your error_log (in debug mode) to find out what is wrong with cups-browsed's filter chain.
And can I remove the old queue without cups-browsed recreating it again immediately?
Generally cups-browsed does not auto-create queues to printers for which there is already a manually created queue. You do not even need to remove the queue created by cups-browsed. Stop cups-browsed and start it again and the queue should go away.
If it is your only printer, you do not need cups-browsed once after having created a queue manually, you can disable it. Only if you are in a network with many printers or you roam with a laptop between different networks with different sets of printers, cups-browsed comes in handy.
By the way, the printing dialog still shows a printer error, but I do not really care about that. It seems to be buggy anyway with its detection of everywhere-printers with the wrong capabilities.
Please report a bug on the GTK print dialog, to GTK. Till