Printing system upgrade

which will fail if something else opens a different file at the wrong moment, and gets the same file handle.

How would this happen, given that I’m talking hooking into filesystem vectors (it’s the only way that sort of thing can work) so you can literally pick up the file handle on exit and detect when the file is closed…

…it’s only stuff running purely in application space that used to suffer from this, particularly if they held files open, precisely because there is no mechanism to broadcast that a file handle has been closed, so if something else opened it and the handle was recycled, two different programs would have access to the same file thinking they were two entirely different things
It was…something of a problem back in the RISC OS 3.1 days.

Again, the old way made sense with the hardware of the day (a dot matrix didn’t really have resolutions as such,

That is not history as I remember it. Back in the dot matrix days, it was very common to print in “draft” resolution for speed reasons unless you really needed the highest possible quality.

The problem with the RISC OS way of printing came with the many many more options for printout with later printers – duplex or not, which tray to select, colour adjustment, colour or b/w…combinatorics is not the friend of the RISC OS approach.

On the other hand, there is not really a difference between adjusting the printer’s settings via !Printers instead of the print dialog – in Windows world, you often have “profiles” that you set up on the printer driver side which you can then easily choose from the print dialog side. Which is not too far from the RISC OS approach.

Back in the dot matrix days, it was very common to print in “draft” resolution for speed reasons

The problem is, dot matrix doesn’t have variable resolutions. It fakes it by advancing the paper a fraction, then overprinting. And again, and again, depending on what sort of quality you were aiming for.

End result. Much time, much noise, burn through the ink ribbon, and quite possibly she’d the paper…or at least leave it nastily wrinkled.

;)

I have a laser printer that talks PostScript, which I talk to over LPR (using RemotePrinterSupport). It have “printers” for colour, mono and duplex (which is colour) along with the PDF output, which means I have 4 printer icons on the icon bar. With a modern monitor it’s not too bad, but it’s really only two printers, one of which can do mono / colour and single sided / duplex.

I wonder if each “physical” “printer” (and I put both in quotes because the PDF writer is neither) could have its own icon with the options for it on a menu. It could end up with a lot of variants of icons though.

which means I have 4 printer icons on the icon bar.

I have a colour duplex laser and a mono duplex laser. This means I have 7 icons – mono single, mono flip long, mono flip short, same for colour, and one for print to PS file.

I wonder if each “physical” “printer” (and I put both in quotes because the PDF writer is neither) could have its own icon with the options for it on a menu. It could end up with a lot of variants of icons though.

Another idea would be to have one icon for each physical printer, and let the user choose the active “profile”, i.e. a named combination of all the printer’s options, with associated small icons as additional printer icon decorations to let the user see at first glance which options/which profile is active.

Because ultimately, we just use the “multiple icons approach” because it is hard to click through all the stuff to set the desired options for the next print run. If we make it easy to select options, the need for multiple icons for the same physical printer goes away.

+1 for Steffen’s suggested control method.

+1 for Steffen’s suggested control method.

OK, who’s volunteering to add the relevant support to the Printer Manager?

I thought there would be a long silence following that.

I’ve been chipping away at another part of the problem; another link in the chain, if you like. I’ve been able to interrogate an IPP device (in my test case, my Linux box, which is sharing my old Epson printer via IPP) and directly create a Printer Definition File from the returned data. It’s still a knife-and-fork process in that I need to convert the app to a Wimp app and offer save via drag and drop. But as a feasibilty study, it’s successful.

I thought there would be a long silence following that.

;) Nearly ten hours. Through a Friday night and into Saturday morning, too!

directly create a Printer Definition File from the returned data

Whoo, nice. ;)

Does it reject devices that are too old and don’t support PWG?

Does it reject devices that are too old and don’t support PWG?

I found it very interesting that, although my printer predates IPP, when it is shared out it supports PWG-Raster and URF – neither of which it does natively. Not only that, but I sent it a 300dpi PWG-Raster file, and it was printed out at the correct size – even though the printer itself does not support 300dpi; its nearest is 360dpi! So CUPS is doing a major translation job on the raster data before sending it to the printer.

Another curious thing is that CUPS/Linux shows it supporting 361×360, 1440×720, 1441×720 and 1442×720. Those really are the figures that come back in the IPP data stream; it’s not a mistake in my decoder.

Here’s the way it’s heading at the moment. I’m working on two apps.

The first will use multicast DNS to interrogate for all the IPP-supporting printers on the network, and then offer to create a Printer Definition File for each of them. I’ve done the feasibility work in two apps, one that does the mDNS, and the other that takes a printer’s URI (as returned by mDNS) and creates a PrDefn file from the details returned by the printer. The PrDefn has a comment that saves the printer’s URI.

The second app will transport IPP PWG-Raster Printout files to an IPP printer. It will also read a PrDefn dragged to it and extract the printer’s URI. Again, I’ve done the feasibility work. I’m starting with a Toolbox-based app written in C.

It’s not quite as joined up as I would like. Operation will still require users to save to file and subsequently drag the file to the transport app, but it’s better than not being able to use a modern printer at all.

Comments, as usual, welcome!

I wish RISC OS generated an event for file close, then it would be easy to start processing a completed printout automatically. It might be possible at the moment, but I can’t see it as easy or as foolproof. I also wish the Printer Manager could save printouts to a randomly-generated filename each time when it’s asked to save to file, otherwise how do you print jobs one after the other without overwriting the file just created? (Maybe I’ve missed something here.)

When looking to see when ‘printout/ps’ had finished growing (i.e. had been closed by the postscript level 3 driver) and I could then convert it to a PDF via ps2pdf14, I examined it until it had no longer grown for 2 seconds. Yuk! But it worked.

Wouldn’t that fail between pages if the subsequent one took more than 2 seconds to render?

I notice that UpCall 3 as well as Vector FindV (&0D) allow you to monitor files being opened and closed. I’ve not tried it but could you have a module that responds to either of these and then changes a pollword for the application?

Since I posted my last-but-one message, it occurred to me that the Printer Manager is responsible for closing the Printout file that it opens, so a Wimp broadcast message when it does so would solve the problem nicely. So I looked at the Printer Manager code, and decided that it wasn’t such a clever idea after all.

(The Printer manager’s code shows another reason why major applications shouldn’t be attempted in BASIC; they become very difficult to maintain. I say that as a supporter, in general, of BASIC.)

I’ve been able to print a PWG-Raster format Printout file by dragging it to the transport app I’m working on. The Printout file was produced from a Drawfile via my PDumperIPP module.

Just another little stage along the way, but it’s nice to be able to report the occasional success when it happens.

Only plain (http/ipp) so far; I still have to add secure (https/ipps), but the code is structured such that the upgrade will be all in the lowest-level functions.

I’ve got secure going now too.

There’s an interesting difference between Socket_Read and AcornSSL_Read. The former returns 0 only on EOF, whereas AcornSSL_Read returns 0 when there are no data currently waiting. In this case Socket_Read would return -1 and errno would be EWOULDBLOCK.

It means I can’t distinguish when all data have been sent, so I have to wait for a timeout to expire. Is this down to the difference in behaviour of secure and non-secure stream connections, does anyone know?

I’ve got good news, I think.

I’ve managed to put together a chain of apps and module to make a reasonably user-friendly way to do printing via IPP on RISC OS. This consists of:

- a printer dumper module to generate PWG-Raster format print data;

- an app to search for IPP printers on the LAN, and offer to create a Printer Definition file for each of them, using entirely information gained from the printer via IPP;

- a transport app that sends PWG-Raster format print data to the printer, by dragging files to it: the Printer Defition File in order to know the destination, and the PWG-Raster file itself of course.

I’ve just run through the entire chain for the first time a few minutes ago and got a successful printout.

(Covid-19 has been helpful in that it has confined me to the computer room for a week now, so I’ve spent far more time on it than I normally would in a week!)

I’m sure it’s all just working on a wing and a prayer at the moment, but I’m now looking for volunteers to try it all out and help me find the most serious bugs and deficiencies.

I’ve got good news, I think.

Sounds very nice, Dave. Thanks for your efforts. Now I’ll have to rummage around in the hubersn dungeon to find some still-working not-too-old inkjet printers…

Is there somewhere something like a “virtual printer” that is capable of receiving PDF, PS, PCL and PWG and just show it on screen?

Not as advanced as that. I have a crude test app that will render a PWG-Raster file as a sprite, which of course can be a constraint as to how many pixels can be handled, as the sprite has to be displayed from RAM.

I’m now looking for volunteers to try it all out and help me find the most serious bugs and deficiencies.

I am happy to help with my Pi4 and networked printer; email sent.