When is a printjob considered as printed?

Only some general information FYI.

The real answer whether or not HPLIP is a solution
must be provided by a HPLIP developer and I think
it depends very much on the particular printer model
and how it is connected/accessed by the computer
that sends the print job data to the printer.

To determine whether or not something
(i.e. usually one or more sheets of paper)
is really printed by the printer device one must
query the actual printing unit in the printer device
and not any kind of software-representation
of the actual printer device or printing unit
like print queues or whatever else there might be
"in between" - for example another printer spooling
software that runs inside the printer device that is
usually involved when the printing data is sent to the
printer device via a higher level printing protocol
like LPD, IPP, or even things like SMB - in particular on
network printers or when a so called "printserver box"
is in between, cf.
https://en.opensuse.org/SDB:Printing_via_TCP/IP_network

When CUPS is used only the so called CUPS backend
could be talking directly with the actual printer device
provided there is not something else "in between".

Accordingly it is the CUPS backend that could determine
whether or not a sheet of paper was really printed
by the actual printing unit of the printer device.

I don't know to what extent the 'hp' CUPS backend in HPLIP
implements quering the actual printing unit in HP printer
devices.

In general regarding CUPS backends see
https://en.opensuse.org/SDB:Using_Your_Own_Backends_to_Print_with_CUPS

When you have a network printer and you know how to
query its internal page counter (usually via SNMP)
you could even make your own specific CUPS backend
that gets the printer unit page counter value before
each print job data gets submitted and then
your backend must monitor the page counter
until the page counter has the expected value.

The backend must not exit before but wait until
the page counter has the expected value according
to the expected printed pages or sheets of paper
(depending what the page counter counts).

This requires that the backend knows how many
pages or sheets of paper are expected for a print job
so that this expected value must be somehow determined
in advance and provided as additional special print job
option value to the backend (it gets them via argv[5])
e.g. by a special printing application that could
submit a print job via a command like
# lp -d queue -o expectedpages=12 file_to_print
when file_to_print should print 12 pages in this example.
One can submit a print job with arbitrary additional
print job option settings - even nonsense like
# lp -d queue -o foobar=nonsense ...
because the CUPS filters and the backend
(all get that 'foobar=nonsense' in their agrv[5])
ignore print job option settings that are
meaningless for a particular filter or backend.

Unexpected "interesting effects" might appear
in case of duplex printing in particular in case
of duplex printing an odd number of pages and
"even more interesting effects" might appear
when the printer itself re-prints a page e.g. to
recover from a "paper jam" issue or things like that.

In the end determining whether or not something
is really printed is the same task as printer accounting
and regarding printer accounting see
https://en.opensuse.org/SDB:Printer_Accounting

Regarding
"how do I install it on SLES12 SP1":
HPLIP is provided for SLES12 in the hplip* RPM packages.
If you like to try out the latest available HPLIP RPMs for SUSE,
see "Version upgrades for printer driver packages" at
https://en.opensuse.org/SDB:Installing_a_Printer

Regarding
" how do I have to configure a printer to use hplip"
see
https://en.opensuse.org/SDB:How_to_set-up_a_HP_printer
Simply put:
Best run 'hp-setup' directly as 'root' on commandline
unless you really trust "nice graphical frontends"
more than plain command-line tools
cf. "Command-line Tools" in
https://en.opensuse.org/SDB:CUPS_in_a_Nutshell

Dear Johannes,
thank you very much for the detailed response.
To be honest, my hope was that there is a solution available like the one we were using with HP-UX. As far as I understood a HP (JetDirect ) tool called hpnpf was used with a feature
      -w Turn on true end-of-job. By default, hpnpf reports successful as
           soon as all the files are sent successfully. Turning on true
           end-of-job forces hpnpf to hang on until receiving a signal from
           the printer indicating that the job has been completely printed.
           This option is only valid for printers which implement PJL job
           commands, such as LaserJet 4, 4Si, and 4 Plus.
and therfore my hope was, that hplip included a program with comparable features!
Do you have any idea, how I can contact a "HPLIP developer"?
Thank you once again for taking your time.
Best regards
Thomas

Dear Johannes,

and (some time ago) an equivalent program hpnpf existed:
https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0ahUKEwj-yrzupObXAhXEaVAKHQJSAdAQFggyMAQ&url=https%3A%2F%2Fapi.opensuse.org%2Fpublic%2Fsource%2Fhome%3Azhy20120210%3Afailed_1%2Fcups-backends%2Fhpnpf.txt%3Frev%3D40e66ba6c19ae940a19da00bf807a8f1%26&usg=AOvVaw3m72LAfFJ6GSPdu2GRvPzM
...
pnpf A replacement backend for the CUPS socket backend
=========================================================

DESCRIPTION

This backend is based on HP's hpnpf utility (the sources of which have been freely
availabel until 1992) and has been extended to safely report the backchannel messages
from a JetDierect driven HP printer and - for PostScript printers only - to use
the TBCP (Tagged Binary Communications Protocol) as defined by Adobe.

The program can be run either as a CUPS backend or as a standalone utility, depending
on the name it is called by:

- if the name it is called with contains one of the strings '://' or 'backend/hpnpf'
  (the latter for use with the CUPS backend test utility), it runs as a CUPS
  backend, following the CUPS backend calling and input/output conventions.
- otherwise, it runs as a standalone utility and accepts additional switches.
...
but I don't know were to get that file linux_std.mak mentioned in the link above ...
Any idea?

Best regards
THomas

Hello Thomas,

the HPLIP developers are listening here so that
this is the right place to get in contact with them.

Personally I cannot help with HP printer specific things
because I don't know enough here - e.g. 'hpnpf' and
'pnpf' is new to me (I just never investigated in this area).

Perhaps you have a support contract for your HP printers
so that you can ask HP for a currently valid Linux replacement
of their HP-UX hpnpf tool.

Alternatively you may ask on the CUPS users mailing list
https://lists.cups.org/mailman/listinfo/cups

Even if this issue does not actually belong to the
CUPS software (the standard CUPS backends implement
only generic "send data to device" functionality) but
on the CUPS users mailing list several printing experts
are listening who might be able to help you.

By the way:
Many thanks for your explanation how things had worked
under HP-UX. It helped me a lot to understand how things
had worked under HP-UX (no big surprise that 'HP'-UX
provides specific printing tools for 'HP' printers ;-)

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Dear Johannes,

thank you vey much for detailed feedback.
And I'm still hoping that one of the HP developers is contacting me ...

Best reagrds,
Thomas Bauer

Hello Thomas,

hope dies last, cf.
https://answers.launchpad.net/hplip/+question/153568
;-)

Seriously:

I can really recommend to also ask on the CUPS users
mailing list
https://lists.cups.org/mailman/listinfo/cups

On the CUPS users mailing list several "old"
(i.e. very experienced) printing experts are listening
who might be able to help you in particular with
things like "old" software as the 'hpnpf' backend
that had been available as source code at some time
somewhere in the Internet.

Whoops!

Now I had a closer look at the readable parts of the above monster URL

https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0ahUKEwj-yrzupObXAhXEaVAKHQJSAdAQFggyMAQ&url=https%3A%2F%2Fapi.opensuse.org%2Fpublic%2Fsource%2Fhome%3Azhy20120210%3Afailed_1%2Fcups-backends%2Fhpnpf.txt%3Frev%3D40e66ba6c19ae940a19da00bf807a8f1%26&usg=AOvVaw3m72LAfFJ6GSPdu2GRvPzM

It contains

... api.opensuse.org ... home...zhy20120210...failed_1...cups-backends...hpnpf.tx ...

That leads to

https://build.opensuse.org/package/show/home:zhy20120210:failed_1/cups-backends

There an openSUSE user 'zhy20120210' seems to have had the 'hpnpf' backend.
But unfortunately it seems it is or does no longer build since a long time.

I guess that for a somewhat experienced developer it is perhaps not too hard
to decide if one could make it compile again (I mean only the 'hpnpf' backend)
with reasonable effort.

But then there is still the license question - i.e. whether or not
the 'hpnpf' sources are under a sufficiently free license so that
one is allowed to compile it and then even use the result.

I am not a lawyer so that I cannot say anything about
the legal state of the 'hpnpf' sources.

Finally there is the question whether or not that old 'hpnpf' backend
still works within a nowadays CUPS environment but I guess it would
because - as far as I remember - there were no changes how filters
and backends are called by the cupsd so that even old filters and
backends should still work.

This question was expired because it remained in the 'Open' state without activity for the last 15 days.