Sun, 12 Jan 2025 22:33:13 -0000

interrogated for what it actually has in its feed trays

HP inkjets can. They support three paper sizes (small, medium, large) and this is detected by way of two or three optosensors in the paper tray.
The user must configure the actual sizes, and from that point it will report to the client what size of paper is present. I used to be able to tell when I’m out of paper as the mobile print service tells me I have 150×100 glossy because there’s nothing in the way of the medium/large sensors. The newer printer has a sensor for small so it can properly tell the difference between small and empty without trying to feed first.
I don’t know if the IPP status dump says this or if there’s some specific additional protocol. I probably ought to capture the IPP block with different paper sizes and see if anything changes.

The upside to this method is that setting up printing to a photo is as simple as taking out the A4 and dropping in photo sizes paper.
The downside, however, is that printing a full page A4 glossy means logging into the printer and changing the default, then printing, then reverting the default back to what it was. This is for mobile use, the PC driver can always override the defaults, but then the PC driver is some proprietary mojo that can do far higher resolution (allegedly, it’s the same number of print heads, they just do more passes).

Maybe if the user specifies it to the printer via its front panel

Front panel?!? 😂 You log into the thing these days, and argue with the configuration interface, which insists upon sending a self signed certificate “for your security”.

Sun, 12 Jan 2025 22:13:13 -0000

Interrogating a printer for supported paper sizes usually results in a very long list, the last member of which is (usually?) pick your own. However, I don’t think the cheap sort of printers we buy for SOHO purposes can be interrogated for what it actually has in its feed trays

More enterprise stuff tends to require SNMP queries to see what is defined in user config in the printer (or SNMP written to the printer) – a bit of a dialogue between the print “server” driver and the hardware. Terminal PITA, as they usually use a wonderfully insecure SNMP setup.
That may flow down the family tree for the manufacturer’s models.

Sun, 12 Jan 2025 20:57:06 -0000

Interrogating a printer for supported paper sizes usually results in a very long list, the last member of which is (usually?) pick your own. However, I don’t think the cheap sort of printers we buy for SOHO purposes can be interrogated for what it actually has in its feed trays. Maybe if the user specifies it to the printer via its front panel; I don’t know, I haven’t investigated because I’ve had more important things to try to get working.

Sun, 12 Jan 2025 20:52:35 -0000

Interesting. Very interesting.

I started IPPTrnspt just to transport data to printers that support IPP, but of course printers can be interrogated for their attributes such as support for duplexing and feed trays, and the same attributes can be specified for print jobs. It’s all very much the same sort of communication and all goes through the same path. So I can see the possibility that IPPTrnspt, or an improved successor, can take the place of !Printers. What’s missing is the ability to specify resolution and colour/monochrome to RISC OS’s rasterising system.

Sun, 12 Jan 2025 19:03:58 -0000

That’s the intention, once we’ve finalised the capabilities. Printers, papers and even multiple Printer Managers are supported. But Feeds and Bins were added very late to !Printers and have never been standardised, so are private data unique to the back-ends. That’s less attractive from an API POV because third-party backends would not implement any new interface, which makes that less useful.

I know people round here would just say “Change the source we have and everyone else be damned” but I’m painfully aware it’s easier to update !Printers than the printer classes within.

Paper, for example, should probably be specific to class and instance, but !Printers has always kept paper and printers quite separate and you can select any paper on any device (subject to backend complaining). But feeds & bins absolutely must be specific to the class and instance.

Sun, 12 Jan 2025 18:58:34 -0000

The most impressive inkjet I ever saw at IPEX had a solid white ink in addition to colours, so could print texture. I saw it print an oil painting complete with brush strokes, cloisonné with enamel fill, and woodgrain. It could print at some distance onto shaped objects, as large as a door.

I don’t think it made it to production, sadly.

Sun, 12 Jan 2025 17:36:44 -0000

I’ve extended the print protocol a little.

Can you make an API available, please?

Is this something you would like to go into the general releases of RO5?

Sun, 12 Jan 2025 17:35:13 -0000

The Canon BJC7000/7100 used to have an “Optimiser” though it was built into the black ink tank, if I remember rightly. As I understood it, this was laid down on the paper ahead of any ink to make its own coated paper.