Rick's b.log - entry 2022/04/02

IPP on RISC OS

Our printer methods date from the early '90s with a driver that accepts data "drawn" to it, translating the drawing into something that can be sent to a printer; either as objects (in the case of PostScript) or as strips to form a bitmap (as in the case of dot matrix, inkjet, laser...).

As is common with devices of that era, there are a plethora of drivers including for different models in the case family. An fx-80 isn't the same as an fx-85, for instance.
As is also common with devices of that era, it is mostly aimed at either printing to file, to serial port, or parallel port (with the latter by far being the most common).
Being Acorn, there is also an option for Econet for use with a print spooler. ☺

It is also rather unidirectional. The user initiates a print, it gets converted into whatever the printer understands, and is then sent to it.

As I'm sure you can appreciate, this means that most printers created in the past twenty odd years are out of the capabilities of RISC OS unless they understand PostScript, HP PCL, or something else that is in common between the printer and RISC OS.
Not to mention, the itty-bitty problem of connectivity. Does RISC OS even understand modern USB printer connections?

The potential solution to this arrived with the explosion of handheld devices. iPads, tablets, phones... with these devices people don't want to fart around with drivers and such. They just want to pick a printer from a list and magically their page will appear.

The leader in this was Apple with their AirPrint protocol. It is very similar to IPP Everywhere except that it uses a proprietory bitmap called "URF" (in various bit depths). There's a pretty good chance that if a printer has WiFi, it will support AirPrint. It will likely support it's own custom formats, but any modern WiFi printer that can't do AirPrint is pretty much dead in the water.

More recently, an IPP working group has created the "IPP Everywhere" specification. This is basically the same as AirPrint, only with an open and documented protocol and bitmap (PWG). Being fully open, there is no hindrance to it being adopted in addition to AirPrint.

Somewhere in between the two is Mopria that aims to provide a universal standard for scanning and printing. This could be of interest, but given the steep price of joining (about $30,000 if I recall), it's only of benefit to printer manufacturers and big players, not for a minority OS such as RISC OS.

Stepping up to the challenge has been Dave Higton, who has created a driver module that outputs a PWG bitmap, either in colour or monochrome.

It has, however, been problematic. Not because of Dave, but because of inherent limitations in the design of the RISC OS printer subsystem.
For example, it is not possible to scan for available printers and pick one. Nor is it possible to query a printer when printing begins to know what sort of features it can work with. To this end, each IPP device should be installed like a regular printer.
Additionally, we have no Bonjour (mDNS) service, so it's not possible to locate printers except by blind scanning. For many, the path /ipp/print is where to direct print jobs. But this is only a recommendation, not a rule. Some printers will accept any path given to port 631, others will return a 404 except for their own weird path (like /ipp/printer or /ipp/jobs).

Additionally, it isn't possible to spool data directly to the printer as it is being generated, because the preamble needs to specify the length of the subsequent data. So it must be printed to a buffer or file and then sent. Note that the bitmap contains various simple data compression techniques like a form of RLE and a "repeat previous line" in order to reduce the amount of data to send, so it's not possible to guess beforehand.

That's not all. There is a quirk in the AcornHTTP module that means that it seems unable to set itself to use HTTP/1.1 for POST requests. If that's gibberish to you, just know that the module understands browser behaviour as it was circa 1998.
While some printers will "just work", some are annoyingly finickety. My HP 3630 will fault an HTTP/1.0 request. It shouldn't, but it does.

As you'll know from a couple of weeks ago, I did manage to get a printout to appear on my Epson XP-345 printer, in the handful of hours when it actually worked. This was a really good start, and proved that the bitmap data was valid and correct. I say this because I know full well that what works on one printer does not necessarily work on another. If you have been particularly evil in life and you are sent to hell, you will not be burned for all eternity. No, you'll instead be reincarnated as a printer technician. That's real torture.

I can communicate with my laser by using RemotePrinterFS to dump LaserJet 6 bitmaps to it. It isn't documented as working, but it does.
I cannot make any use of Dave's IPP driver as the printer is too old, it only understands URF (AirPrint).

And, finally, the HP 3630. Steadfastly rejecting any attempt to send data to it.

In the end, I wrote a little program called "SpewPWG" that simply buffers a PWG raster bitmap from a file created by the printer driver, pastes an IPP header onto the front, and sends it as a POST request to the printer. In other words, exactly what Dave's own program does, only using low level socket access rather than the AcornHTTP method. So I can set the protocol to HTTP/1.1 and it is accepted.
Of course, the problem with this is that my method won't work with printers that require a secure connection. Something that using the URL fetcher (and AcornHTTP) can do "for free".
Talking of free, do feel free to bang your head on your desk. It's pretty much standard behaviour when dealing with printers. Because the physical pain helps to take attention away from the mental anguish that you experience with what the hell do you mean PC LOAD LETTER?!?!?. And this isn't counting patchy WiFi support, NFC that doesn't, stupidity like randomly forgetting settings such as the current paper size, and chipped DRM'd cartridges. All in all, dealing with printers is enough to make a person's blood boil. That Dave is trying to deal with them at a driver level? Give that man a heroism medal!

So we're still a long way from having a product that can be added to RISC OS, but we're getting closer and closer. If you're a bit of a nerd and don't mind doing some things yourself, it is usable now. Dave's IPP module has made that possible.

To that end, here is a rubbish quality scan of an example OvationPro document that I printed this lunchtime and sent to my inkjet. All from RISC OS.

Created and printed from RISC OS (and note that an A4 scan doesn't appear to scan a full A4 page!).

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

David Pilling, 3rd April 2022, 16:50

Pity that it has taken 30 years for sense to prevail.

J.G.Harston, 4th April 2022, 19:01

I wrote a BBC USB printer driver a few years ago, and struggled to get it working, until I discovered something odd in the documentation that certain bytes had to be sent as hex text, some as decimal text, some as raw. Something like "SCD";STR$(port%);CHR$13;"DRD";CHR$(length%);CHR$13;raw bytes.

Add a comment (v0.11) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 79629 backwards.
		Your comment