[ Re-posting for Daniel Haid, original poster ]
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
