Printing using IPP without drivers (IPP Client)

Question

I have a device/appliance that you cannot install drivers for. I would like to add the ability to support network/IPP/AirPrint printers by having the user add the IP Addresses.

Since I am not printing through windows (which would use the IPP), how do I use IPP myself? Is there a c# client (or any windows library) out there that allows you to interact with IPP printers with the IPP protocol?

Solution 1

There are a few IPP client implementations and IPP libraries available for different programming languages (java/php/python). A practical solution could be to use the ipptool available at http://cups.org/software.php. Create an ipp-command-file called printjob.ipp:

{
 OPERATION Print-Job
 GROUP operation-attributes-tag
  ATTR charset attributes-charset utf-8
  ATTR language attributes-natural-language en
  ATTR uri printer-uri $uri
 FILE $filename
}

Now you should be able to print a PDF file using these options:

ipptool -tv -f mydoc.pdf ipp://192.168.2.207 printjob.ipp

Make sure the printer (or print server) supports the document format you send. I assume you're familiar with how to execute an external command in your application.

Even though the ipptool is provided by CUPS it works perfect with any IPP printer. Check RFC 3510 or your printers documentation for the appropriate printer-uri-scheme or use ippfind.

Experienced developers should be able to implement the print job operation in their preferred programming language and ecosystem. I have implemented the use case from above in kotlin with 100 lines of code: https://github.com/gmuth/ipp-printjob-kotlin.

This is my minimal PrintJob implementation in Java: https://github.com/gmuth/ipp-printjob-java

Solution 2

IPP Sample Software

Meanwhile the IPP Sample Software (which includes ipptool mentioned above) is a separate project on Github. It is now under the auspices of the Printer Working Group (PWG), the body which standardized IPP (Internet Printing Protocol).

While the software currently still is in beta, is already very functional. It ships two main command line tools:

1. ippserver. Start it (with the appropriate options) and you will have a fully-fledged IPP server instance on your network, serving as virtual IPP printer (or an IPP server hosting multiple virtual IPP queues) which you can use to test any (or your self-written) IPP client software against.

2. ipptool. This is an IPP client program which can send any combination of IPP requests to any IPP instance on the network (CUPS server, ippserver, IPP-capable printer hardware) and validate its responses. The software ships with a few prepared text files containing example IPP requests, all with a .test suffix for their filenames.

For your purpose, you could run these commands:

1. ipptool -t -v ipp://xxx.xxx.xxx.xxx/ipp/print get-printer-attributes.test. This command will query any IPP printer about its supported IPP attributes. This should include an item telling about its supposed IPP versions support. For example reporting as ipp-versions-supported (1setOf keyword) = 1.0,1.1,2.0.

2. ipptool -t -v ipp://xxx.xxx.xxx.xxx/ipp/print ipp-1.1.test. This command will run a complete validation suite against the printer to test for its real-world IPP-1.1 compliance.

3. ipptool -t -v ipp://xxx.xxx.xxx.xxx/ipp/print ipp-2.0.test. This command will run a complete validation suite against the printer to test for its real-world IPP-2.0 compliance.

4. ipptool -t -v ipp://xxx.xxx.xxx.xxx/ipp/print ipp-2.0.test. This command will run a complete validation suite against the printer to test for its real-world IPP-2.0 compliance.

5. ipptool -t -v ipp://xxx.xxx.xxx.xxx/ipp/print ipp-2.1.test. This command will run a complete validation suite against the printer to test for its real-world IPP-2.2 compliance.

6. ipptool -t -v ipp://xxx.xxx.xxx.xxx/ipp/print ipp-2.2.test. This command will run a complete validation suite against the printer to test for its real-world IPP-2.2 compliance.

7. ipptool -t -v ipp://xxx.xxx.xxx.xxx/ipp/print ipp-everywhere.test. This command will run a complete IPP Everywhere (which is the latest IPP Standard) validation suite against the printer to test for its real-world IPP Everywhere compliance.

---

AppImage of the IPP Sample Software

To make this type of testing easy for you guys, I created a ready-made executable AppImage from the IPP Sample software that should be able to directly run (no "installation" needed!) on all x86_64 Linux distros.

You can use it on (almost) any Linux system without having CUPS or ippsample installed!

The AppImage has embedded all the major executable command line tools of the IPP Sample Software project. These exacutables will run as 'sub-commands' of the AppImage. See further down for examples.

1. Download:

   wget https://github.com/KurtPfeifle/ippsample/releases/download/continuous/ippsample-x86_64.AppImage
   

2. Make AppImage executable (and optionally rename it to ippsample):

   chmod a+x ippsample-x86_64.AppImage
   mv ippsample-x86_64.AppImage ippsample
   

3. Have a look at its built-in help screen:

   ./ippsample --ai-usage
   

4. Run it:

   ./ippsample ipptool -t -v ipp://xxx.xxx.xxx.xxx/ipp/print ipp-2.0.test
   

5. Find all IPP-capable printers nearby:

   ./ippsample ippfind
   

   will yield s.th. like:

   ipp://HPA0B3CCF051B9.local:631/ipp/printer
   ipp://lenjessie2.local:8444/ipp/print
   ipp://mbp14.papercut-ipv4.local:631/printers/OJ6500
   ipp://mbp14.papercut-ipv4.local:631/printers/libreoffice-pin-code-drucker
   

6. Pick one printer, print a job:

   ./ippsample ipptool       \
           -tv               \
           -f ./printjob.pdf \
            ipp://HPA0B3CCF051B9.local:631/ipp/printer \
            print-job.test
   

---

ASCIinema ASCIIcast

Here is an (older) ASCIinema ascii-cast acting as an illustration of what I wrote about and how to use the IPP Sample Software (and its AppImage):

Comments

[Kurt Pfeifle]

The printer does not need to "support the document format you send."! It is CUPS which needs to support the document format. (Your command line suggests you are printing via a CUPS server, not directly to an IPP printer -- why else would you use "ipp://localhost/printers/laser" as the URI?). CUPS will auto-type the file you sent, and will auto-create an appropriate file format filtering chain to generate the jobfile type the printer wants. You can send PDF with ipptool, and the target printer could be a PCL device. CUPS will take care of the required translations....

[IPP Nerd]

Paul's original question is not related to CUPS. It's true that some (better) printers or print-servers use application/octet-stream as default-document-format and therefore need to auto-type the data received. Printing without drivers works best with PDF and printers that accept PDF (e.g. LaserJet M175nw or imagePRESS C7010VP). Using CUPS can not be considered printing without driver as CUPS itself always needs a "driver" or filter. People asking questions about IPP or "driverless-printing" tend to avoid middleware like CUPS.

[Kurt Pfeifle]

"Paul's original question is not related to CUPS." True. -- However, your answer assumes that the job goes via CUPS. The IPP URI scheme you use does not match ANY IPP print device's URI I know (and I know more than a hundred). But it matches what CUPS uses.

[Kurt Pfeifle]

If you want to use an IPP URI to address a print device directly, then use either ipp://printername-or-ip/ or ipp://printername-or-ip/ipp or ipp://printername-or-ip/printer/ or ipp://printername-or-ip/ipp/port1 or ipp://printername-or-ip/ipp/print. These cover about 95% of all real IPP devices out there. Unfortunately, this isn't really standardized. (None of the devices I ever tested supported ipp://printername-or-ip/printers/queuename ).

[Kurt Pfeifle]

BTW, above sample most likely will not work, if the IPP printer you try to send the file to is a CUPS queue: because then you also need an additional line 'ATTR name requesting-user-name $user'. Also, most hardware IPP printers also want to know which user prints...

[Kurt Pfeifle]

@IPPGeek: Now it does, now even geeks can reproduce it.

[Kurt Pfeifle]

I talked about CUPS ("if the IPP printer you try to send the file to is a CUPS queue"), and I didn't say every hardware IPP printer requires it, but I talked about "most" of them...

[Kurt Pfeifle]

You assume that CUPS implements the IPP in all details 1:1. This assumption is wrong. Also, if the spec says SHOULD, do not assume that CUPS does NOT do it. -- I do not get what part of my statements you regard as "false"...

[Doktor J]

@KurtPfeifle why do you keep talking about CUPS? The only place CUPS is mentioned is that the tools in use here (ipptool, ippfind) are provided by CUPS. Depending on your distro you can also get them independent of it and they work exactly as described here, so CUPS is largely irrelevant beyond being a means to an end: a place you can get them from (e.g. cups-ipp-utils package on Ubuntu).

[Kurt Pfeifle]

@DoktorJ: I mention CUPS because ipptool originated in CUPS. If you do not like that just replace this word with 4 placeholders like **** when you read it. Issue solved...