Printing

It was also a pity Dave Lambley’s IPP Printer Driver has got lost and stuck at 26bit so is the intention to feed this back in to the ROOL sources.

IIRC, Dave Lambley’s driver module “only” covers the transport of the data, not the form of the data itself (that’s what Dave Higton is currently tackling and what is really interesting – it allows “generic” “driverless printing” based on simple bitmap formats, the only problem is that it is not universally supported by nowadays printers).

IPP transport itself is “just” HTTP, so should be trivial with the help of the various modules now standard on RISC OS 5.

I did some experimentation and prototyping (in Java) a while ago and blogged about the details:
http://itblog.huber-net.de/2019/08/stuempern-mit-niveau/

Basically, you want printer auto detection over the network (via Bonjour protocol), controlling your printer (IPP Everywhere cares for that), and sending the printer data (that’s the IPP PWG format DaveH is currently tackling). The last one is the most important of course, typing the printer’s IPP URL into a textfield would only be a minor inconvenience compared to “cannot print”.

I’m just feeling a bit pleased because I’ve managed to create a full colour sprite from an sRGB-8 PWG-Raster file. The original (that was printed to file) was a JPEG, and the results match nicely.

Only a bit pleased because another of the test documents seems to get my code into an infinite loop. More work to be done.

But it is progress.

Aha – got it. There’s another PWGRaster header and body immediately following the expected one. I didn’t expect that. So it’s not my code at fault – it’s only test code, it doesn’t have to handle all the odd stuff that can occur in the real world.

It’s possible to create pwg files on RISC OS using mutool available via PackMan by installing MuTools.

e.g.

mutool convert -o test.pwg -O resolution=600 test.pdf

The next version of ghostscript 9.27 for RISC OS will be able to create them too. Available from PackMan soon.

Also soon to be available a port of ipptool from CUPS that can be used to print to an ipp enabled printer.

e.g.

ipptool -v -tf /test.pwg -d filetype=application/octet-stream -l http://<ip address>:631/ipp print-job.test

Good stuff, Chris – there’s more than one way to skin a cat…

What we need is something that integrates into the normal RISC OS printing system.

I can report that I just managed, a few minutes ago, to render a UniRaster file to a sprite, so I understand that format too – as much as the reverse-engineered specification allows, anyway. The header of UniRaster files is much smaller than that of IPP files, but, since so much is negotiated between host and printer via HTML, I can’t see why one would need much header information in the file or stream.

A test for people with Airprint printers. From here: https://github.com/AlanQuatermain/unirast/ can you try sending 1-page.urf as raw data to your printer?
Does it print one page of something, or does it spew out pages of garbage, with the first page starting ‘UNIRAST’? (I would print it ready to press the ‘off’ button on your printer, to avoid wasting lots of paper)

On my Brother HL-L8260CDW, if I pipe this into port 9100 on it (ie using JetDirect/Appsocket) I get the pages of garbage. Which surprises me since it claims to support image/urf.

I’ve also done a port of ipptransform. Part of ippsample (https://github.com/istopwg/ippsample/tree/master/tools).

It can convert jpeg and pdf to urf or pwg and print to ipp(s), http(s) or socket. (The pdf conversion isn’t currently usable as it’s so slow. It’s also unusable on a fast PC). Tested on a Brother HL-L5100DN. (which supports IPP and AirPrint).

e.g.
ipptransform -i image/jpeg -m image/urf -r 300 -d ipp://<ip address>:631/ipp/print test/jpg

There’s a port of ipptransform available here.

At the moment only JPEG files print successfully.

Included in the zip file is a simple ‘Frontend’ module front end to the ipptransform command line utility.

All that’s needed to print to an IPP enabled printer is the IP address. The printer just needs to support either urf (UNIRAST) or pwg-raster format. No printer driver is needed on RISC OS.

The ipptool application will be added to the zip file in the near future. This can be used to query the printer for it’s capabilities and send a print request based on the capabilities of the printer. e.g Enable compression or send PDF files directly.

Theo: I think you need to send URF as the body of an HTTP POST to port 631, with the appropriate Content-Type.

The ipptool application will be added to the zip file in the near future. This can be used to query the printer for it’s capabilities and send a print request based on the capabilities of the printer. e.g Enable compression or send PDF files directly.

The !ipptool ‘Frontend’ application has now been added to the ipptools zip file here.
I’ve not got a printer that supports direct PDF printing so haven’t tested this with !ipptool. mutool available via PackMan by installing mutools can be used to create a PWG file from a PDF. The PWG file can then be directly printed using ipptool if the printer supports it.

On my Brother HL-L8260CDW, if I pipe this into port 9100 on it (ie using JetDirect/Appsocket) I get the pages of garbage. Which surprises me since it claims to support image/urf.

While testing my old 2011 vintage OKI colour laser, I found out that it accepted PCL and PS “directly” via any means from directly piping to the socket as well as “proper” IPP, but PDF was only accepted via correct IPP i.e. HTTP and correctly set MIME type, or it would print garbage.

Hi Chris,

Thanks for IPPTools and IPPTransform.

Quick test on my Hp M254DW laser printers and it prints a JPEG and PDF via IPPTools.

To a HP Deskject 3637 it prints a JPEG.

The JPEG printed by the 3637 fills the full A4 page but on the laserjet it is reduced and it’s scale is retained.

Excellent work.

HP M254DW
ipp-features-supported (keyword) = airprint-1.6
document-format-supported (1setOf mimeMediaType) = image/urf,application/PCLm,application/octet-stream,application/pdf,application/postscript,application/vnd.hp-PCL,application/vnd.hp-PCLXL,image/jpeg
printer-device-id (textWithoutLanguage) = MFG:HP;CMD:PJL,PML,PCLXL,PWG_RASTER,URP,PCL,PDF,POSTSCRIPT;MDL:HP ColorLaserJet M253-M254
HP Deskjet 3637
ipp-features-supported (1setOf keyword) = airprint-1.4,ipp-everywhere
document-format-version-supported (1setOf textWithoutLanguage) = PCL3GUI,PJL,Automatic,JPEG,PCLM,AppleRaster,PWGRaster
printer-device-id (textWithoutLanguage) = MFG:HP;MDL:DeskJet 3630 series;CMD:PCL3GUI,PJL,Automatic,JPEG,PCLM,AppleRaster,PWGRaster,DW-PCL,802.11

While testing my old 2011 vintage OKI colour laser, I found out that it accepted PCL and PS “directly” via any means from directly piping to the socket as well as “proper” IPP, but PDF was only accepted via correct IPP i.e. HTTP and correctly set MIME type, or it would print garbage.

I discovered my Brother has a ‘Service’ page in the settings. It seems there’s a pattern match on the incoming file – if certain strings are detected at the beginning or end of the input, then a particular format is selected. This is things like @PJL, POSTSCRIPT\0A, \1B%-12345X and various other strings of control characters. You can enable each filter for TCPIP (Appsocket), IPP or both. Unfortunately there’s no UNIRAST listed, and it appears to be a fixed list. The filters are ‘No filter’, ‘Text Substitution’, ‘AppleTalk’, ‘Text to Postscript’ and ‘Postscript tagged binary’. I suspect AppleTalk is not URF, but something older.

Out of the box it comes with these filters configured:

Service 1	BRN<hex>	P1
Service 2	BINARY_P1	P1
Service 3	TEXT_P1		P1
Service 4	POSTSCRIPT_P1	P1
Service 5	PCL_P1		P1
Service 6	BRN<hex>_AT	P1

Hi Chris,

I have now also tested the HP254DW with IPPtransform and get mixed results.

If I try sending the resultant image/pwg-raster file direct to the printer , using port 631, then it does not print.

It will print a image/urf version as long as I set the DPI to 600.

As a reminder it’s attributes say:

printer-device-id (textWithoutLanguage) = MFG:HP;CMD:PJL,PML,PCLXL,PWG_RASTER,URP,PCL,PDF,POSTSCRIPT;MDL:HP ColorLaserJet M253-M254;CLS:PRINTER;DES:HP Color LaserJet

So to recap I can print to the Hp254DW using IPPTools either a jepg or PDF and also via IPPTransform for /urf.

The HP 3637 Deskjet does however printout via IPPTransform, using a JPEG as the input and both image/urf and image/pwg-raster output, and as previously tested also via IPPTools for jpeg as well.

As a reminder the HP254DW is Airprint 1.6 and the 3637 Aprint 1.4 and ipp-everywhere.

Hope this helps.

In my (admittedly limited) experience, there are two sorts of WiFi printing.

The first is AirPrint, which is usually URF as well as some sort of custom format used by that specific printer (for better results with their mobile driver).

The second is an IPP compatible printer, which will support the newer protocol as well as, for necessity, AirPrint.
The later printers are also more likely to support packaged PDFs, JPEGs, etc.

It’s great to see things moving on this front. I had a play with something a couple of years ago, and some crap C code was able to create and decode a 24 bit URF, but my printer flatly refused to accept it.

At any rate, supporting this will mean access to a lot of printers without the driver grief of the old days. ;)

I’d appreciate a bit of help – I’m struggling a bit…

And to anyone reading this, please don’t get confused like I do between printer drivers and printer dumpers.

I’ve seen some references to printer drivers having numbers. I’m trying to write a dumper. It appears that dumpers must register with drivers so that they are fed information that they can understand and process. I can find some references to printer dumper numbers (which presumably must have been allocated, and I’ve requested an allocation for mine). What I can’t find is any list of numbers for printer drivers, e.g. PDriverDP, which is (I think!) the driver that mine should register with. Nor can I find any by searching through the RISC OS sources or the DDE libraries.

If printer driver numbers exist, please point me at them; if they don’t, please correct my misunderstanding!

The StrngHelp OS SWIs manual has a list of PDriver numbers under the “PDriver” section, but it doesn’t list “PDriverDP” so maybe thats not what you’re looking for?

Thanks, Andrew – that’s interesting. Putting 2 and 2 together and making, possibly, more than 4…

7 is listed as “PDumper interface”. I can imagine either that it’s PDumperDM, or that it’s PDriverDP.

Numbers 0 to 20 are assigned. All the inkjet printer definition files (and a few more) supplied with Martin Wuerthner’s Gutenprint refer to module: dumpers: number: 21, so I can well believe that PDumperGP (for GemPrint) is dumper number 21. Maybe drivers and dumpers are assigned in the same range? I can see that David Pilling’s PDumperSP has #define PDumper 7 but with absolutely no explanation.

I can go to bed happy tonight – I’ve just created an apparently correct PwgRaster file by printing a Drawfile. My test application subsequently renders the PwgRaster file into a sprite that resembles the original Drawfile.

This is still experimental code – nowhere near production completeness or quality – but it does indicate that I’m going in the right direction.

Bravo, now bedtime!

I can go to bed happy tonight

Hope you had a good sleep :-)

Another bit of good news as along with Chris Gransden’s port of IPPTools it looks like we may have a access to a lot more printers again.

Well done and thanks for all your efforts.

Rick: I tried your FindIPP app, but on my RasPi it searches addresses from 255.255.255.0 to 255.255.255.255 – which of course is NOT my LAN! How do I persuade it to use the correct range? Where does it get the address from?

Edit: I see it looks at Inet$EtherIPAddr which only works if that’s a dotted-quad value. Mine’s “RasPi3B” because the IP address is “from hostname”.

I’ve changed the sysvar to “192.168.16.69” and now I have a sensible result from FindIPP.

An IPP or Airprint printer is going to be connected via the LAN in some way. The RISC OS printing system needs to know the IP address of any such printer.

I’m just looking at extending the Printer Manager to add “LAN” as a connection type, in addition to the existing options of Parallel, Serial, Econet, NFS, USB, Direct drive and File.

Can anyone see a better way?

Can anyone see a better way?

not necessarily better but RemotePrinterFS uses file connection and puts the ip address in the file field.

Interesting idea, thank you, John. RemotePrinterFS opens up a unidirectional file handle for spooling. I guess the question is whether an alternative (let’s call it IPPFS) can open up a socket handle (plain or secure) that the Printer Manager sees, and is used for the bidirectional HTTP communication. PDumperIPP can open up its own temporary spool file if necessary, and the Printer Manager would never be aware of it. Not sure at this point whether a file handle would be necessary at all.

There’s one possible fly in the ointment, which is that PM uses file handles that are 0 if closed/invalid, whereas socket handles are -1 if closed/invalid. Dunno if it’s sensitive to this.