[cups-devel] job status monitoring for AppSocket

[Sam Hanes]

Michael,

(There's a question in here, I promise. Look for "*cupsPortMonitor".)

On 07/12/2016 08:00 AM, Michael Sweet wrote:
>> On Jul 12, 2016, at 9:50 AM, Sam Hanes wrote:
>> I have an HP LaserJet printer with an EIO JetDirect card set up in CUPS
>> via AppSocket (socket://printer:9100). It prints fine, but CUPS marks
>> the job completed as soon as it finishes sending the PostScript data. I
>> want it to report the printing status page-by-page and not mark the job
>> completed until the last page is in the output tray. Extensive
>> Google-ing hasn't revealed a documented way of getting that in CUPS.
>
> Well, for HP printers we rely on the half-close mechanism to wait for
> the job to complete. The socket backend closes the outbound socket as
> soon as all data is sent, then we wait for the printer to close the
> other side, indicating that it has finished all pages.

The particular JetDirect card I have (615n/J6057A) doesn't appear to
support that mechanism. According to the error_log at debug2, the socket
backend is indeed entering the half-closed state and waiting (it logs
"Waiting for printer to finish"). However it consistently receives the
remote close (logs "Job completed") within a few seconds, even for huge
jobs that take more than a minute to print.

> PJL and other mechanisms do not scale and suffer from versioning and
> communication issues.  And quite frankly AppSocket (and LPD) are dead
> as far as future development goes.  All modern (since 2010) network
> printers support IPP and IPP's rich job monitoring, even for (legacy)
> PostScript jobs.  Prior to then you might have issues with PostScript
> printing over IPP...

Quite. Unfortunately I'm constrained to old, cheap printers and
interface cards like the LaserJet 4050 and the JetDirect 615n.

The JetDirect 615n does support IPP, but the job status is always
`completed` in the response to `Print-Job`. Either it doesn't support
status reporting or it's reporting completion as soon as it finishes
sending the data through the EIO port.

> ...
> The advantage of doing it as a port monitor is that it will work with
> all PPDs without change, but the disadvantage is that you need to
> enable it for every queue that needs it.

Huh. That wasn't working for me. I installed the binary as
`/usr/lib/cups/monitor/pjl`, but `pjl` didn't show up in the
`port-monitor-supported` attribute until I added this to the PPD:

     *cupsPortMonitor socket/PJL Status: "pjl"

Is there some additional install step I need to perform to make my port
monitor supported by default for all printers?

> Doing it as a filter limits you to those PPDs you have updated to use
> it, but has the advantage of working automatically whenever you use
> those PPDs.

Even if custom port monitors need to be added to each printer's PPD I
think it still makes sense to make it a port monitor. Whether the PJL
monitor is necessary is determined by the JetDirect model. The PPD, of
course, describes only the printer model. A LaserJet 4050, for example,
could have any extant EIO JetDirect model, including a JetDirect 615n
which needs the PJL monitor or a JetDirect 695n which doesn't. It would,
therefore, actually be bad to activate it based on the PPD alone.

>> Is this something that should be contributed to CUPS proper?
>
> Maybe the cups-filters project, but I can tell you we won't accept this
> into CUPS itself due to the support burden and the lack of need for
> current, vendor-supported printers.

Fair enough. I'll aim to keep it as a stand-alone project, then.

--
Sam Hanes
sam at maltera.com