Printing

@Dave

I’ll need your email address.

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

PDF sent to you via email to the address you have included in IPPTrnspt.

Oh bugger.

Your printer, it seems, supports URF but not IPP.

The reverse engineering of URF that I’ve found does not show how to do duplexing.

Sorry.

Unless anyone else (nemo? nemo knows everything?) knows how to get duplexing to happen in URF, that’s a stopper.

Hi Dave,

I have extracted further information from the printer in the via IPPTools and Rick Murray’s FindIPP which I’ve sent to you to double check things.

Both tools state:

ipp-versions-supported (1setOf keyword) = 1.0,1.1,2.0
ipp-features-supported (keyword) = airprint-2.1

Hope the full details confirm things one way or the other.

Oops, I knew what I meant, but that wasn’t really what I said!

Your printer supports URF but not IPP PWG-Raster. That’s the bitstream carrying the information on the pixels to be printed.

Sorry.

It does mention PWG-Raster but not specifically IPP PWG-Raster in the output files but as usual it seems that a standard isn’t always a complete standard as they say and HP seem very good at that.

I have another printer that mentions it uses the PDumperIPP module but that isn’t duplex.

The printer-more-info string ends in info_config_AirPrint.html, and the document-format-supported string includes image/urf but nothing about PWG-Raster; this makes it look like a printer supporting AirPrint and Apple’s own proprietary format, but probably too early for the fully developed IPP to have caught on.

Anyway: if someone reading this has a printer that supports IPP PWG-Raster and duplexing, I hope to have something for you to test shortly, so please speak up!

Thanks for looking at this Dave and sorry I can’t help test this for you.

Still good to get to being able to test the basics.

A new PDumperIPP module is available from me – not from my web site, please either ask here or email me – along with three tiny BASIC apps to set to single-sided, duplex long edge, or duplex short edge.

As I’m sure you’ve worked out, feed/duplex selection is not part of the raster format but the metadata of the protocol that provides it – which would be IPP/CUPS/AirPrint.

If you mean the page header, that’s where I expect to find it for IPP PWG Raster format (PWG 5102.4-2012 section 4.3), and that’s where my module puts it – but I haven’t been able to test it because, cheapskate that I am, I haven’t bought a printer with the appropriate capabilities.

Uniraster format has a much smaller page header, but ate the commands for duplex, feeds, etc. passed in there, or is there a separate command path to the printer?

That was unnecessarily cryptic, sorry.

I meant to say that it’s not as simple as setting “Duplex please” – depending on printer capability you will probably have to transform the bitmap yourself. Microsoft used to insist that both [Cross]FeedTransforms be set to 1, for example. If MS required that, it’s likely due to feedback from OEMs.

I’m a PS/PDF/XPS/PCL/TIFF veteran so I’ve little experience of these consumer-level bitmap formats. Can you not just generate a job on PC for the device in question and inspect the result?

If you mean the page header

Surely this sort of thing would be metadata in the packet containing the print job? Stuff like duplex or what paper feed to use would apply to the job as a whole wouldn’t they, rather than per page?
Does it mention anything about this in the IPP transport docs?

Can you not just generate a job on PC for the device in question and inspect the result?

Probably not. I don’t say this to be facetious, it’s because printers generally support much more than they offer via AirPrint/IPPE. For example, my HP3630 advertises that it can only do 300dpi. It is capable of 1200 (or so it claims). The HP4222e does advertise 300/600/1200 and by all appearances it is a less capable printer mechanism (can’t do borderless, leaves a nearly inch margin at the bottom…).
Therefore, if you use a driver on a PC to print to the printer, you will not get whatever AirPrint/IPPE want, you’ll get some proprietary gubbins (like PCLm3 or whatever) that gets the best from the printer. I tried this when originally trying to work out URF with my Laser. The driver was only willing to create Samsung Q…PD? I forget the acronym. Anyway, not what I wanted.

Perhaps the best way, though some degree of work, is to hack together a simple server that pretends to be an AirPrint/IPPE device and grabs a copy of whatever gets sent to it. But, hey, I can expect the official drivers to do a bunch of weird things like, for example, doing Mopria instead, or some HP-specific thing (example – the PWG raster isn’t compressed, some basic “compression” may greatly speed up how long it takes to get data from a mobile device to the printer).

You’re right that dissuading drivers from “knowing better” can be tricky. It can be easier with shared printers, because the PC can’t probe the device itself… though it can still install megabytes of trickery.

I meant to say that it’s not as simple as setting “Duplex please” – depending on printer capability you will probably have to transform the bitmap yourself.

I’m a PS/PDF/XPS/PCL/TIFF veteran so I’ve little experience of these consumer-level bitmap formats.

Does it mention anything about this in the IPP transport docs?

I refer the honourable gentlemen to Printer Working Group PWG 5102.4-2012 section 4.3, but Uniraster is a closed book to most people.

PWG-Raster looks to be OK because the page header is big – it’s 1796 octets – and it’s rich in information, including such basic things as duplex and feed settings. Although it could be purely informational, with the commands elsewhere, it seems a perverse thing to do; so my working assumption is that the printer is supposed to obey what’s in the page headers.

Can you not just generate a job on PC for the device in question and inspect the result?

I could if I had access to one of the devices in question. Again, I think there’s a difficulty with Uniraster because CUPS doesn’t have access to the documentation, or refuses to do anything because it’s private, or something, I forget which – and I don’t use Windows.

Access to a relevant machine does bring up an interesting possibility. In the early days of developing this stuff, my son gave me access to his Epson printer, some miles from where I was doing this. He put a firewall rule in his router to redirect port 631 to the printer, but it was specifically for my IP address, i.e. no-one else could access it from the outside world. If anyone else reading this has an interesting printer and could do the same, that would be helpful. I have to say that my router can’t restrict firewall rules to a particular external address, it’s dumbed down much too much, and you may have the same problem.

I just tried printing a 2-page document from an Ubuntu notebook to the (mythical) HP printer shared out by my Linux box. All the data are encrypted by TLS 1.3. That rather spoils any hope of decoding what was sent.

All the data are encrypted by TLS 1.3.

CUPS probably has a configuration option to turn that off. Might be worth Googling?

He put a firewall rule in his router to redirect port 631 to the printer, but it was specifically for my IP address

Hmm. My Livebox can do that. I just checked and it supports an external IP option on NAT/IPv4 and IPv6. That being said, I don’t have anything fancy, just two generic HP inkjets.

CUPS probably has a configuration option to turn that off. Might be worth Googling?

What do you think I’ve just been doing…

I can’t see any way to turn secure off. I think secure has just been an assumption for some years now.

https://www.cups.org/doc/encryption.html

DefaultEncryption Never ?

Or does it go ahead and do it anyway?

When I examined the /etc/cups/cupsd.conf file, the editor didn’t find the string “encryption” anywhere.

So I’ve put one of each in, in the correct places I hope, and I’ll try again.

An unintended experiment shows that DefaultEncryption Never and Encryption Never (or was it No?) do not prevent an ipps: request from being encrypted.

https://ciphersuite.info/cs/TLS_RSA_WITH_NULL_SHA256/

Don’t think any browser supports it though

From ciphersuite:

This key exchange algorithm does not support Perfect Forward Secrecy (PFS) which is recommended, so attackers cannot decrypt the complete communication stream.

Is that comma in the wrong place? Seems to me that it should be before the word “which”.

@Rick: I share your view.

I have recently replaced my ancient printer with an Epson XP-8700, in the hope that it supported enough IPP stuff to allow printing from RISC OS. I can report that with some help from Dave H, who suggested using GetIPP with https://:631/ips/print, after some trials I found a value of dns-name which produced a PrintDfn file. When it was loaded into IPPTrnspt and Printers, I have printed a page from Fireworkz.

Well done to Dave!

I look forward to futher developments, but this is a major step forwards for RISC OS.

Thank you, Martin. It’s always nice when someone notices one’s hard work, isn’t it?

Does the duplexing work? (You have mail.)