Printing

The ippdiscover.zip file has been updated. The ippdiscover executable is now aif format so longer needs the somanager module.
Also included is ippdiscover_rod. This no longer crashes if you have the ROD network stack installed. Press escape to exit once it’s found the printer.

I’ve updated the IPP printing stuff on my web site https://davehigton.me.uk to new versions of GetIPP, dumper modules and IPPTrnspt. If you update, please update all of them together.

The new versions support duplexed printing, on an Epson XP-8700 at least, and possibly more printers – I’d like to know whether or not it all works for you.

I’ve looked more at FindIPP. I can see why it would not work for many people.

Or, to put it another way: how did that /ever/ work? (A thought that, I suspect, might be familiar to some other programmers.)

I’m on the case.

You’re not a real programmer until you discover a bug that means that a program should absolutely not have worked, and/or should have exploded messily… yet when you tested it on your machine it worked just fine.

I look forward to trying out the fixed version.

A schrödinbug.

A cat story….

You’re not a real programmer until you discover a bug that means that a program should absolutely not have worked,

Hmmm. Today I decommissioned a set of old Cisco Expressway units as all¹ the traffic in/out of the DMZ they sit in was to/from the new kit…

…except the new units not in DMZ talking, locally, to the old ones not in DMZ and those talking to the old DMZ ones, that talked, locally, to the new ones in DMZ.

Why did they not do that new —> new?
Because the supplier asked for TCP 2776/2777 not UDP 2776/2777 and therefore the UDP version wasn’t in the FW port list. But it all worked – until I disabled the Allow rules for the old kit, preparatory to turning them off and junking them. Fortunately also worked when UDP 2776/2777 was added to the port list.

Made the change at 10:00, which is why someone sat on the video feature failure report until this evening, when I was on the bus to part way home…

¹ OK, not all, just 99.999%

Only tangentially related, but Gavin Crawford of this parish asked if apps like Ovation Pro could exercise more control over the Printer Manager, so I’ve extended the print protocol a little. Here’s a demo:

No prizes for font quality were sought

This API enables apps to:

• Discover printers of specific classes (eg PDF)
• Store the printer selection with a document so it can be reselected
• Inherit the named page size of the printer
• Switch between printers
• Change paper size
• Other things probably

Not remotely useful unless you’re an advanced app developer, but it’s quite interesting.

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?

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.

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.

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.

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.

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”.

which insists upon sending a self signed certificate “for your security”.

Ah, certificates (sigh)
It’s one thing to show mild concern when it’s an item on a private network¹, and something else when it’s an internet facing system where the user seems to think our systems giving an error about an upstream certificate error is the problem.

¹ Like, perhaps, your router, or, as you mention, your printer. The latter type of object tends to have a certificate import facility, mostly(ish)

PJL is widely supported on multi-PDL printers, and can tell you what (the printer thinks) is in the trays.