Printing

In the intervening time, I’ve been working lots more on printing via IPP. I think the time is approaching when I can send out stuff to willing testers, that’s much more likely to work.

There has been a lot to learn in this area. Rasterising to PWG-Raster and URF formats is far and away the easy part.

👍 The hard part is getting the raster to the printers, and their various (sometimes nonsensical) behaviours.

However, I’m pleased to report that I have had a correct page output from every WiFi printer that I own, whether it be AirPrint it IPP Everywhere, laser or inkjet.

The process is still a bit manual, one cannot simply prod the Print key, but compared to before when only the laser worked (as it accepts HP LaserJet data thrown at port 9100), this is a massive step forward.

And it’s a massive step forward for RISC OS as well, being able to print to devices created this century, with no faffing around with drivers and such like in the old days. It’s either AirPrint (URF) or IPP (PWG), and Dave’s tool will sort out which automatically.

I’ve not attempted to connect a printer to the Pi. I just send stuff to the Mac and print from there…too lazy I am.

I think the time is approaching when I can send out stuff to willing testers; that’s much more likely to work.

Happy to help Dave; email sent.

I could only currently test on an IPP-but-not-Airprint-and-not-Everywhere laser printer, so probably not helpful…

A little postscript to my problems calling PDriver_MiscOp. It seems that R2 must be a valid strip type. This is not what the docs say, and it looks like a bug to me.

Anyway… if my current experiments work, it should be possible to print in a single stage. It looked like it was necessary to print to file, then drag the file to my IPPTrnspt application to get the data transported to the printer. I now think I can invoke IPPTrnspt directly. This means that, if IPPTrnspt is running, printing from RISC OS apps to IPP-enabled printers will be seamless.

Don’t forget the “if” in the first line.

Well, the “if” went in the favourable direction. So, if a printer supports IPP and the PWG-Raster format, requesting a printout from any RISC OS application should result in the job going straight to the printer.

Sadly it’s not the same for printers that support IPP and URF but not PWG-Raster; this remains as a two stage process, for now at least. This means that the request to print results in a printout file that must, as a separate operation, be dragged onto the IPPTrnspt app.

I have some vague ideas as to how both formats might be supported automatically, but they are not worked out in detail.

I’ll get stuff in its present state sent out to my faithful band of testers.

Well done you derseve a pint or two

Keep this up and I’ll have to buy an IPP-capable printer!

I know how you feel… I still don’t own one…

During the development, I’ve been helped by the kindness of strangers, the kindness of family, and the legendary ability of Linux to do almost everything.

I think I have a method to make IPPTrnspt respond directly to printouts coming from either the PWG-Raster or URF dumpers. But it’s doing my head in, and it’s a bugger to test. Maybe I’ll feel clearer tomorrow.

I’ve sent out another set of stuff to my beta testers. The first report has come back as OK.

Here’s a quick overview of what is involved.

There’s an app called mDNS whose job it is to find printers and print servers that support IPP, and generate Printer Definition Files for them. (I now think it ought to be renamed, maybe something like FindIPP?)

There are two printer dumper modules, PDumperIPP (which supports PWG-Raster format) and PDumperURF (which supports URF).

Finally there’s an app called IPPTrnspt whose job it is to transport printout files to the chosen IPP-capable printer. Printer Manager can’t do this because the data have to be sent by HTTP with a prologue. It’s not even possible to use AcornHTTP because the latter can only send files in one go, therefore they must reside in RAM, and printout files can easily exceed available RAM space.

The chosen printer must be configured to print to file. The Printer Definition File must also be dragged to IPPTrnspt so as to give the printer’s URL. Then apps can print just as normal, and the file automatically gets transported to the printer.

So it’s very close to the existing method of printing.

Thanks for your hard work on this, Dave.

Apparently it should work with any printer that works via WiFi, but can anyone clarify if the printer needs to be connected via WiFi? My PX700W has USB, Ethernet & WiFi, but is always connected via USB to RISC OS (& Ethernet to others). The detection programs have not shown any evidence if compatibility. Might using the WiFi improve matters?

Interesting thought, Martin. Not one I’m able to test.

Are you able to print to the PX700W directly from RISC OS? If so, what driver do you use?

My assumption has been that any IPP-capable printer has to be accessible over a network, as the interrogation and data transport are done with HTTP, which requires a URL, which requires a network connection. I don’t know how you would communicate via HTTP over a USB link.

A network connection can be either over Ethernet or over WiFi. Finding the printer via mDNS requires that the printer and RISC OS host can exchange mDNS messages, so need to be local to each other. Data transfer, as I’ve proved, can be over the Internet.

I see the PX700W manuals on Epson’s site are dated 2008, which predates IPP, so I don’t think my software can help you. It can only work with IPP-capable printers.

There is one interesting way, though, if you have a Linux box. I’ve shared out my printer (which is even older than yours) from the Linux box, and I discovered that the share is IPP-capable – which the printer itself emphatically is NOT. Linux does a complete protocol translation. Thus I’m able to print via IPP to my old printer.

This facility has been enormously useful during development.

I don’t think my software can help you.

Having a look at the documentation on-line, it’s a bit peculiar. It seems to be able to hook into a network (wired or WiFi) to run a peer-to-peer printing service using custom Epson software.
Sounds to me like this was being aimed at small office configurations in the days before AirPrint was a well known thing.

I don’t see any mention of firmware upgrades to bring better options. For example, my dead Epson was only advertised as being AirPrint/URF compliant, but a firmware upgrade (that happened as I was setting it up for the first time) added IPP Everywhere/PWG support.

Hmm… The tech spec says the PX800FW series can cope with HD MJPEGs at 15fps, or SD MJPEGs/MPEG1 at 30fps. So, uh, maybe a stupid question but how d’you print video? ;)

So, uh, maybe a stupid question but how d’you print video?

With a printer capable of at least 25 pages a second?

Are you able to print to the PX700W directly from RISC OS? If so, what driver do you use?

Gutenprint.

I don’t know how you would communicate via HTTP over a USB link.

Sorry, I may have misled you – I print from RO using USB, but RO is also connected to my network, so is also connected to the printer via Ethernet, which is what IPP would use.

Thanks for the other replies – it all confirms my thoughts that it is not IPP capable. (except possibly via Linux).

Is there any way of turning duplexing on/off for non-PS printers?

Depends upon what the printer understands.

A quick Google for PCL suggests ?&l#S where # is 0 for single sided, 1 for duplex long edge binding, and 2 for duplex short edge binding.

There’s probably something in the IPP spec for similar behaviour…?

Yeah, what I really meant was is it possible (via Printer Manager) to tell a printer to print on one or both sides of the page.

There are feeds for PS, but I can’t find any way to tell PM what to do in the case of non-PS printers.

There is indeed stuff in IPP to control duplexing.

Yeah, what I really meant was is it possible (via Printer Manager) to tell a printer to print on one or both sides of the page.

I believe Richard Darby’s PCL printer drivers available via plingstore can provide that facility if needed. Other option is most printers configuration screen will allow you to change from duplex to single sided.

The only way to achieve this with the current design is to define duplicate graphics modes in !PrintEdit with names such as “360dpi” and “360dpi (duplex)" with appropriate commands in the Page Start string.

It’s not a very satisfactory solution, and I haven’t actually tried it.