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