[cups] ippeveprinter - how to set up with real printer?

[Till Kamppeter]

On 08/10/2019 22:41, Kurt Pfeifle wrote:
> Am Di., 8. Okt. 2019 um 16:18 Uhr schrieb Zdenek Dohnal zdohnal at redhat.com
> <http://mailto:zdohnal@redhat.com>:
> 
> 
>> I'm trying to test ippeveprinter printer application which comes with
>> CUPS-2.3.0:
>>
>> # ippeveprinter -D socket://<printer-ipv4-addr>:9100 -c
>> /usr/lib/cups/command/ippeveps -P /etc/cups/ppd/BRQ-TPBC-1D124-North.ppd
>> -d /var/spool/cups brno4-tpbc-1st-north -v
>>
> Why do you connect an *IPP Everywhere* printer to a *socket://* backend?
> Any reason which I’m not aware of?

Kurt, Zdenek does not want to speak IPP through an AppSocket connection 
here.

ippeveprinter is a so-called Printer Application, a daemon which 
emulates an IPP printer on localhost. The print jobs it takes it passes 
on to a physical printer and this physical printer does not necessarily 
need to be an IPP printer. The -D option tells how to communicate with 
the printer via a CUPS URI which determines the CUPS backend and its 
arguments, -C defines a command to be called to convert the input into 
the printer's native language, -P is a PPD file describing the printer 
(the content will be converted to the answer to a get-printer-attributes 
IPP request from the client).

The printer in this example is a PostScript printer. The PPD comes from 
the printer manufacturer. the ippeveps command turns incoming PDF into 
PostScript. To get the output onto the printer the "socket" backend of 
CUPS is called.

IPP is only spoken by clients to communicate with the IPP printer 
emulated by ippeveprinter. Once ippeveprinter is running you find the 
URI of the emulated printer with the ippfind command, something like

ipp://localhost:PORT/ipp/print

PORT is some port which is not 631 (as 631 is occupied by CUPS), see 
documentation of ippeveprinter what gets auto-selected here. Note that 
this URI is generated automatically by ippeveprinter and does not need 
to be specified on its command line.

A client (print dialog, cups-browsed, or CUPS) starts to send a 
get-printer-attributes IPP request to know about the printer's 
capabilities. ippeveprinter will then read the PPD file supplied to it 
via -P to generate the answer. The client, in case of a print dialog 
will then diaplay appropriate options, in case of cups-browsed or CUPS, 
generate a PPD file and create a temporary CUPS queue. If the client 
sends a job ippeveprinter receives it, converts it with the utility 
specified by -C and the calls the backend specified by -D to send it off 
to the printers.

The problem here is most probably that ippeveprinter has a bug and 
therefore does not answer the get-printer-attributes IPP requests from 
the clients correctly.

    Till