[cups-devel] IPP backend bug

Tue Sep 8 01:31:17 PDT 2015

Hello Michael,

On Sep 7 17:01 Michael Sweet wrote (excerpt):
>> On Sep 7, 2015, at 9:25 AM, Johannes Meixner <jsmeix at suse.de> wrote:
...
>> I think it should work to run the filtering (including
>> the printer driver) on the client system and then use
>> the IPP backend to send printer-specific data to the
>> final recipient (either a queue or a printer device).
>
> The issue is the MIME typing on the CUPS server - if the
> server doesn't recognize the MIME media type then you
> may end up with extra filtering.
>
> I'm not saying it can't work (because we have customers
> that use that configuration all of the time), it is just
> that we get a lot of support calls when people try to do
> Microsoft-style printer sharing to a server that is also
> hosting a CUPS printer driver on the same queue.

Many thanks for clarification!

Your description matches perfectly what I wrote about
"Enforce 'raw' printing" and "Via IPP to a CUPS print server" in
https://en.opensuse.org/SDB:Printing_from_Windows_to_Linux

Not only when printing from Windows to a CUPS server
but in general when sending printer-specific data to a CUPS
server one must ensure that no duplicate filtering happens.

It seems when printer-specific data is sent via IPP to CUPS
there is no option for the ipp://... device URI to enforce
"raw" printing for the receiving queue on the CUPS server,
at least no such option is described for "IPP" in
https://www.cups.org/documentation.php/doc-2.1/network.html

In contrast for the lpd://... device URI there is the option:
   format=l  Specifies that the print data is
             a raw (preformatted) print file.

But it seems this option does not work (I use CUPS 2.0.3)
or I misunderstand how this option is meant to be used:
----------------------------------------------------------------------
# lpadmin -p testy -v file:/tmp/testy.out -m Postscript.ppd.gz -E

# lpadmin -p totestyvialpd -v lpd://localhost/testy?format=l -E

# echo hello4 | lp -d totestyvialpd
request id is totestyvialpd-7 (0 file(s))

# egrep 'PID|File of type|Queued on' /var/log/cups/error_log
...
I [Job 7] Queued on "totestyvialpd" by "root".
I [Job 7] File of type text/plain queued by "root".
I [Job 7] Started backend /usr/lib/cups/backend/lpd (PID 1613)
I [Job 8] Queued on "testy" by "root".
I [Job 8] File of type text/plain queued by "root".
I [Job 8] Started filter /usr/lib/cups/filter/texttopdf (PID 1616)
I [Job 8] Started filter /usr/lib/cups/filter/pdftopdf (PID 1617)
I [Job 8] Started filter /usr/lib/cups/filter/pdftops (PID 1618)
D [Job 7] PID 1613 (/usr/lib/cups/backend/lpd) exited with no errors.
D [Job 8] PID 1616 (/usr/lib/cups/filter/texttopdf) exited with no errors.
D [Job 8] Started filter pdftops (PID 1623)
D [Job 8] Started filter pstops (PID 1624)
D [Job 8] PID 1617 (/usr/lib/cups/filter/pdftopdf) exited with no errors.
D [Job 8] PID 1624 (pstops) exited with no errors.
D [Job 8] PID 1623 (pdftops) exited with no errors.
D [Job 8] PID 1618 (/usr/lib/cups/filter/pdftops) exited with no errors.
...
----------------------------------------------------------------------

Regardless that I have specified 'format=l' the receiving queue "testy"
does filtering.

FYI some more details from error_log (excerpt):
-----------------------------------------------------------------------
# grep 'Job 7' /var/log/cups/error_log
...
D [Job 7] envp[23]="DEVICE_URI=lpd://localhost/testy?format=l"
...
I [Job 7] Started backend /usr/lib/cups/backend/lpd (PID 1613)
D [Job 7] STATE: +connecting-to-device
D [Job 7] Looking up "localhost"...
D [Job 7] Connecting to localhost:515 for printer testy
I [Job 7] Connecting to printer.
D [Job 7] Set job-printer-state-message to "Connecting to printer.",
  current level=INFO
D [Job 7] STATE: -connecting-to-device
I [Job 7] Connected to printer.
D [Job 7] Set job-printer-state-message to "Connected to printer.",
  current level=INFO
D [Job 7] Connected to [v1.::1]:515 (local port 1023)...
D [Job 7] lpd_command 02 testy
D [Job 7] Sending command string (7 bytes)...
D [Job 7] Reading command status...
D [Job 7] lpd_command returning 0
D [Job 7] Control file is:
D [Job 7] Hlinux-fes0
D [Job 7] Proot
D [Job 7] J_stdin_
D [Job 7] ldfA613linux-fes0
D [Job 7] UdfA613linux-fes0
D [Job 7] N_stdin_
D [Job 7] lpd_command 02 72 cfA613linux-fes0
D [Job 7] Sending command string (21 bytes)...
D [Job 7] Reading command status...
D [Job 7] lpd_command returning 0
D [Job 7] Sending control file (72 bytes)
I [Job 7] Control file sent successfully.
D [Job 7] Set job-printer-state-message to "Control file sent successfully.",
  current level=INFO
D [Job 7] lpd_command 03 7 dfA613linux-fes0
D [Job 7] Sending command string (20 bytes)...
D [Job 7] Reading command status...
D [Job 7] lpd_command returning 0
D [Job 7] Sending data file (7 bytes)
I [Job 7] Spooling job, 0% complete.
D [Job 7] Set job-printer-state-message to "Spooling job, 0% complete.",
  current level=INFO
I [Job 7] Data file sent successfully.
D [Job 7] Set job-printer-state-message to "Data file sent successfully.", 
current level=INFO
D [Job 7] STATE: +cups-waiting-for-job-completed
D [Job 7] PAGE: 1 1
D [Job 7] PID 1613 (/usr/lib/cups/backend/lpd) exited with no errors.
...
-----------------------------------------------------------------------

I think the information in the LPD control file is not correct
(but I am not a sufficient LPD expert).

Is there a bug or do I misunderstand how the 'format=l' option
is meant to be used?

Kind Regards
Johannes Meixner
-- 
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)