Printing

There doesn’t seem to be much standardisation on what path to look for on a printer’s (or print server’s) port 631. Not a problem if you can use mDNS, of course, but those using RPCEmu or the like almost certainly can’t because they can’t open the correct multicast address/port because the host already has it open.

using GetIPP with http:// The Printers Ip address:631/ipp/print works and generates a Printer Definition file

On my Linux box, no such luck. “No useful printer found”. A browser just gets a 404.

The Linux box responds to just http://LinuxBox:631 with a CUPS page with loads of information, a menu bar, and clicking the “Printers” menu bar gives the URLs of the two shared printers: http://LinuxBox:631/printers/CUPS-BRF-Printer and http://LinuxBox:631/printers/Epson-Stylus-Photo-RH620.

@Rick:

Please note that it’s common for there to be lots of plain HTTP destinations available via port 631, not requiring the binary payload etc. of the IPP protocol.

I might have to collate a list of paths to try, for people who can’t use FindIPP and have to use GetIPP instead.

are sufficient to enable printing?

Yes, no, maybe. 😉

It is my understanding that those modules deal with the low level side of things, so will get a bitmap to the printer.

PM, however, deals with setting the options and which printer is “current”, and possibly job control if the driver is set to spool.

I think, if one only intends to use IPP, then something a little less clueless than PM that better understands modern requirements would be a boon…

…but at the same time it probably ought to coexist with PM and work in basic mode if PM is loaded, because I’d imagine a number of people may also want access to PDF output and the like.

that prevented error-free startup of the printing system when an IPP printer definition file was the default.

Brilliant! It did get a bit tedious wiping the settings, restarting, setting up Printers again…

bore no relation to the causal error.

Throwing a fault somewhere in PDriverDP, yeah? That’s how it goes – if nothing catches an error, eventually something else will fall over. 😐

Let me know if you have an updated scanner you’d like tested. The one to retrieve IPP settings works (but can be simplified as I said previously). It’s the mDNS that wasn’t working for me.

Please note that it’s common for there to be lots of plain HTTP destinations available via port 631, not requiring the binary payload etc. of the IPP protocol.

That’s up to the printer manufacturer. Like I said, my older HP rejects the request, the newer one redirects to the normal port (80).

RFC 2901 (IPP transport 1.1) says:

It is REQUIRED that a printer implementation support HTTP over the IANA assigned Well Known Port 631 (the IPP default port), though a printer implementation may support HTTP over some other port as well.
Each HTTP operation MUST use the POST method where the request-URI is the object target of the operation, and where the “Content-Type” of the message-body in each request and response MUST be “application/ipp”. The message-body MUST contain the operation layer and MUST have the syntax described in section 3.2 “Syntax of Encoding”.

Therefore, I think pointing a browser at port 631 will have “implementation defined” results.

Therefore, I think pointing a browser at port 631 will have “implementation defined” results.

Absolutely. The part of the universe we’re referring to is not uniform or standardised.

I’ve updated the IPP Printing page of my web site, https://davehigton.me.uk

FindIPP is updated to version 0.02 – it now waits 10 seconds for responses.

I’ve put the current non-debug versions of the Printer Dumper modules, PDumperIPP and PDumperURF, there.

Brilliant! It did get a bit tedious wiping the settings, restarting, setting up Printers again…

I hope these will fix that for you!

The remaining thing is to get a full and correct set of instructions for printing using IPPTrnspt, and then put that up.

FindIPP… Sorry…

FindIPP 0.01 (2023 May 27) starting up
17:34:22.99 Exec
Result of bind: 0
Socket: 52
Transaction ID: 0x43AF
Result of sendto: 33
Message from 192.168.1.15
   1B9A0 |43 AF 00 00·00 01 00 00¦00 00 00 00·04 5F 69 70 : C¯..........._ip : +0 
   1B9B0 |70 04 5F 74·63 70 05 6C¦6F 63 61 6C·00 00 0C 00 : p._tcp.local.... : +16 
   1B9C0 |01         ·           ¦           ·            : .                : +32 
ID: 0x43af, bits: 0x0000, index: 4
This is a request
Finished dequeueing and processing, false, false
process_state: 0
Closing down; 0 printers found
17:34:28.01 Exec

Interesting, the program says at the top “0.02 (2024 November 17)” and that message is a little further down as “FindIPP %s starting up”. I don’t see any “0.01” or “%d.%2d” (etc) in the file so I wonder where the version number is coming from?
Not important, just wanted you to know that I wasn’t mistakenly running the older one…

just wanted you to know that I wasn’t mistakenly running the older one…

I checked. The one on my web site definitely is version 0.02. The RunImageD is of today’s date. Please check yours. There’s another clue: from Exec to Exec is 5 seconds, which is consistent with version 0.01; version 0.02 would take 13 seconds.

OK, folks, IPPTrnspt is up there too. Please follow the instructions in IPPTrnspt’s Help file; printing via IPP isn’t going to work for you unless you do.

All hell starts breaking loose real soon now…

Weird. Did it again and it reported itself as version 2. <shrug> I was running !RunD for it.

Anyhoo, same result, just took longer…

All hell starts breaking loose real soon now…

Sweet. Now everybody can fiddle with their WiFi printers from RISC OS. ;)

Just a quick note, probably nothing as I’m not using URF here, but I thought I’d mention it…

Call to PDumperIPP_MiscOp succeeded; pollword = 206371FC
Call to PDumperURF_MiscOp resulted in an error

Happens once a second.

Call to PDumperURF_MiscOp resulted in an error

Unless the PDumperURF module is loaded, this error message will occur. It has no adverse consequences.

FindIPP is updated to version 0.02 – it now waits 10 seconds for responses.

Still doesn’t find my HP M254DW laserjet, just waits longer.

The good news is that as previously stated I did get a PDF for the printer and I’ve installed your PDumpers,IPP TRansport and the PDF and I can get it to successfully print out via IPP, so thanks for this.

One other point is that it doesn’t work with Ian Hamilton’s Print Spooler so you have to set a local configuration setting for it not to be handled by that program as it creates an abort otherwise.

Anyhoo, same result, just took longer…

The debug logs you have posted both show requests but no responses.

The only reasons I can thknk of are:

The printer is having to wake up from some sleepy state;

Your LAN has a segment that does not transmit multicast traffic.

I’d have thought that a wait of 10 seconds was enough.

ResRec version 0.45 is available from my site. While FindIPP is running, do you see UDP port 5353 open?

While FindIPP is running, do you see UDP port 5353 open

Yes that port is open.

Using port 631 one printer (Canon) did kind of reply; the others (Kyocera and HP) did not – but with GetIPP two did give results.

I tried FindIPP on my mini.m – starts, tells me it’s searching, disappears from screen and icon bar… so no results on this end.

I tried GetIPP and hoping it is of some interest below are the results for my three printers.

I print to over network using RemotePrinterFS and PostScript 3 (I only purchase printers supporting PostScript since that makes life much easier with RISC OS) – works for all three printers.
Fun note on the side: The Kyocera printer works much better with PostScript opposed to its default language – even from Windows :-)

HP Color LaserJet CP1515n – this is an older system (though a real good color laser printer) that does not seem to support IPP.

1. GetIPP says there is nothing to get

Kyocera Ecosys P4040dn – this is an A3 duplex black/white laser printer (the one I print GAG-News with)

1. PrData file for ‘HZNKYO’, dp class
2. uri: ipps://hznkyo:443/ipp/print
   cl: dp
   pr_nme: ippk
   sh_nme: ipp
   sp_nme: ij
   res: 1
   g_mode:
   module: dumpers:
   number: 26
   name: PDumperIPP
   palette: 0
   options: 1088
   pxres: 600
   pyres: 600
   data:
   flags: 83886081
   gname: 600 × 600 DPI
   gcalib:
   data1: HZNKYO
   data2: 600sw
   data3:
   data4: GemPrintGP2
   data5:
   data6:
   data7:
   data8:
   data9:
   data10:
   data11:
   data12:
   data13:
   data14:
   data15:
   data16:
   data17:
   data18:
   data19:
   data20:

txt_cds: 0
chars: char_maps:
char: 1
||
default_paper_size: A4 paper size
default_xresolution: 600
default_yresolution: 600
default_quality: 258
supports_fast_parallel: 0
default_gname: 600 × 600 DPI

1. Paper X offset= 0
2. Paper Y offset= 0

Canon i-Sensys MF428x – this is an A4 duplex black/white multifunction laser printer/scanner

1. PrData file for ‘MF420x’, dp class
2. uri: ipp://hznmfc:631/ipp/print
   cl: dp
   pr_nme: ipp
   sh_nme: ipp
   sp_nme: ij
   res: 1
   g_mode:
   module: dumpers:
   number: 26
   name: PDumperIPP
   palette: 0
   options: 1088
   pxres: 300
   pyres: 300
   data:
   flags: 83886081
   gname: 300 × 300 DPI
   gcalib:
   data1: MF420x
   data2: 300sw
   data3:
   data4: GemPrintGP2
   data5:
   data6:
   data7:
   data8:
   data9:
   data10:
   data11:
   data12:
   data13:
   data14:
   data15:
   data16:
   data17:
   data18:
   data19:
   data20:

txt_cds: 0
chars: char_maps:
char: 1
||
default_paper_size: A4 paper size
default_xresolution: 300
default_yresolution: 300
default_quality: 258
supports_fast_parallel: 0
default_gname: 300 × 300 DPI

1. Paper X offset= 0
2. Paper Y offset= 0

Cheers, Herbert

Here are my latest findings.

!FindIPP 0.02

On the RiscPC this waits longer on the iconbar but still quits without finding anything.

!GetIPP 0.01

Tried this on the real RiscPC where using: http://192.168.1.50:631/ipp/print/ worked and produced a definition file, so I tried this again on RiscPCemu where it produced no result, although it didn’t stiff the network connection this time.

!IPPTrnspt

This installed beautifully on real and emulated RiscPC and accepted the definition files generated by each computer.

I’ve only tried printing from the emulator so far, which printed at first try a single page PDF. However the printer also printed a second sheet with error messages on it;

URF ERROR - IlleaglResolution

     POSITION : 0x958 (2392)

     SYSTEM   : h6fwsim/xl_dec

     LINE     : 55

     VERSION  : SPL 5.73.04 06-10-2014

     ERROR CODE :11-1113

A quick look at the actual printout didn’t spot anything amiss with it.

So brilliant work Dave, Thank you!

Whilst doing further testing I noticed that the current IPP implementation doesn’t do duplex printing and hence printing out pamphlets/double sided printing is not possible on my HP254dw.

I know this may seem a premature “please sir, can I have more” moment but are there plans to support duplex/double sided printing on printers that have this capability.

@Doug:

I know what to send in the printer stream to do duplexing (including tumble or not), and feed selection, but the difficulties are how to present the user with the choices available for that printer, and how to get the information to the dumper module. Acorn’s printing system wasn’t designed for that.

I have some ideas. Keep the faith, and I hope fuller choices will become available.

To backtrack a little: I know what to send for IPP; the URF specification is not available to the public. What I have done for URF is from a partial reverse engineered specification. But let’s hope URF declines in importance. IPP specifications are freely and openly available, and there has been widespread adoption, so let’s hope it takes over completely.

@Andrew:

Please double check that the same Printer Definition is selected in both Printer Manager and IPPTrnspt. They must be the same.

I must make that clear in the instructions; mea culpa.

If the error occurs with the same definitions selected, please send me the Settings file in use (this is normally in !Boot.Choices.Printers, is of type PrDefn (&FC6), and is in the same directory as a “dp” directory) and the Printer Definition File for the printer. dave at davehigton dot me dot uk

It’s a strange error, as the resolutions are supplied by the printer, and the dumper module recodes the print pixels one for one.

I have some ideas. Keep the faith, and I hope fuller choices will become available

Well I’ve kept the faith since 88, so a little while more isn’t an issue :-)

For using the Hp254DW with postscript drivers I use Richard Darby’s duplex enabled ones that give a lot of options in the print manager.

Thanks for all the work so far in bringing modern printing to the platform.

Hi Dave, yes it was definitely the same PD file loaded by both programs. I hadn’t actually saved the settings from that first test but have now tidied up the installation and saved the choices and running !IPPTrnspt at boot. So I will see if I get any more errors of this type. Also I want to properly install on the Real RiscPC and compare the definition files created by each system.

Ok, here is my second update. Now installed everything on the Real RiscPC. Printing a similar one page PDF produces a near identical error printout, however printing a pretty complex drawfile printed without error, so it could be a bug in !PDF, although it did suffer from the thin line problem which I’ve also had with !PrintPDF.

So all installed on two systems, both printed first go. You’d think this was the finished software not a prototype, very impressed.

@Doug:

How did you create the Printer Definition File? It looks like my FindIPP didn’t work, so did you use GetIPP?

I think I can see how to do duplexing etc. but it requires extra stuff to go into the PrDefn, which means a change to FindIPP and GetIPP; changes to IPPTrnspt to present the possible settings to the user, accept them, and pass them on to the dumper module; and changes to the dumper module to accept the settings.

Give me a few days.

Hi Dave,

How did you create the Printer Definition File?

Via GetIPP.

@Doug:

I hope to be able, a few working hours from now, to send you a version of PDumperIPP that enables duplexing. I’ll need your email address.

In the meantime, please send me the Printer Definition File for your printer.

The plan is becoming much clearer. It’s possible to parse much more information out of the printer’s reply to FindIPP or GetIPP; that just requires some more hours of “cranking the handle” on my part. The extra information can go into a Printer Definition File. IPPTrnspt can use it; Printer Manager doesn’t barf on it. So an enhanced PrDefn is compatible with both its users.

There is a proper mechanism for passing extra configuration information to the dumper module, so extra settings for things like duplexing and media source can go from IPPTrnspt. I didn’t realise this before; I thought everything had to come from PM, hence my concentration on trying to understand and extend it. That no longer appears to be necessary.

Assuming that Doug is able and willing to do a couple of experiments, and assuming that they work, we are on a path to provide much fuller support for modern printers.