Printing confusion

This is an anecdote, not a call for help.

I have just been producing a booklet using Ovation Pro on RISC OS. The cover has a colour photo and is printed on cream card. The rest is monochrome on plain paper. I have two duplex lasers – one mono the other colour – both connected via NetPrint, and using Richard Darby’s duplex drivers, and PS3.

I mail-merged the recipients’ names onto the cover page, so this forced the printing system to produce a file with 40 copies of both sides. Once this had stopped printing (as far as RISC OS was concerned) it was seen to spool to the printer, as noted on the network switch leds, and the printer had started to output paper, I switched the selected printer to mono and started printing the rest, selecting collated. Again this resulted in a file with 40 copies of the document. The colour printing is quite slow as it has to render the photograph each time.

Shortly afterwards the colour printer stopped, and the page produced had “invalid command” printed across it. The command displayed was part of the data that should have gone to the mono printer.

So it seems that with this combination of software, the printing system cannot cleanly handle spooling files to two printers simultaneously.

the printing system cannot cleanly handle spooling files to two printers simultaneously.

Given it’s age, that wouldn’t surprise me.

The colour printing is quite slow as it has to render the photograph each time.

How is the photograph done? If it’s a JPEG, it ought to be more or less sent straight to the printer.
It’s a shame you need to put the name on the cover page, else it could be a render once print forty times command…

At least you’re using PS3. The awfulness of what the standard driver does with a sprite defies belief. ;)

Perhaps best to treat each print job as a unique task and do them one after the other, and just have spooling be to get the machine to respond quicker.

I was wondering if it isn’t the printer seeing the second job, which probably starts with some sort reset or initialise, and obeying that as soon as it comes in. I assume RISC OS has a queue per printer instance on the icon bar, not a master queue for the destination printer address.

a queue per printer instance on the icon bar

You do realise, I hope, that all of those printer instances are handled by one BASIC program?

not a master queue for the destination printer address.

This.

I’ve only had a very brief (like two minute) look at the code, but…

There appears to be only one reference to spool_file$, however I think we may have run into some sort of bug here, because it appears as if…

• Print job is created, spooled to disc using a random temp name, and this is assigned to either PrinterType$5 or PrinterType$10 (I didn’t dig into the differences – types 5+ are documented as paths held in the corresponding system variables).
• The print happens.
• Then the random named temp file ought to be added to the output queue to be sent to the printer in the background.

So in theory one should then be able to repeat the process, get a different temp name, and write the new data to file.

So, either !Printers does something stupid like using spool_file$ for both the spool file being created and the spool file to be sent to the printer in the background… or there’s some other sort of clash.
Sadly, I suspect it might be the above stupidity, given:

The command displayed was part of the data that should have gone to the mono printer.

Which if this is the case, it implies that you can’t print something new while a print is being spooled. At least, not until the code is fixed.

I wish to reiterate, however, that I may be well off the mark here. I just dropped the code into Zap, searched for “spool” and looked at the matches. I cannot be an expert after two minutes (if I could, I’d go be an expert at something that pays well!). So, E&OE etc.

I think we probably need to have !Printers be rewritten to deal with 21st century problems.

But it’s ~350K, or nearly eleven thousand lines of code and, well, good luck to whoever is brave enough to want to figure out what it actually does. I’m sure as hell not volunteering!

So, instead, we’ll limp along with what already exists. It’s… a bit of a trope, isn’t it? ;)

I mail-merged the recipients’ names onto the cover page, […snip…] The colour printing is quite slow as it has to render the photograph each time.

What if you separate the mail-merge frame from the front cover, thus having two pages. Then you can print the cover 40 times, put the pile back on the tray, and do the mail-merging over it. That would certainly speed up the process.

I’ve no idea about the spool problem, though.

I think we probably need to have !Printers be rewritten to deal with 21st century problems.

What do you want to bet that Nemo already did something like that before Y2K ??

About 7-8 years ago I did convert 80% of !Printers+ to be a toolbox app. In that process I split the main runimage file into more manageable lumps.
I never got round to implementing the queue fully, but the rest seemed to work OK. I made it have a single icon on the icon bar showing the current printer only, and when clicked it opened a window with all the rest of the installed printers showing which you could then click to be the current printer.
Obviously no changes were made to the basic operation of !Printers.

put the pile back on the tray, and do the mail-merging over it.

Passing paper twice through a laser? <shudder>

What do you want to bet that Nemo already did

Wouldn’t surprise me, but was it ever released or just a personal goodie?

I made it have a single icon on the icon bar showing the current printer only

That seems like a good idea. I have numerous printers, but only two I use with any sort of regularity. The others just take up space on the icon bar.

Did you ever release your modified Printers app?

Passing paper twice through a laser?

Exactly. Some years ago with the previous non-duplex setup I did pass it through 3 times – once for the front, once for the back, and once for the names. There was a slight tendancy to pick up some of the earlier print and redeposit it elsewhere on the paper. Hence the single pass.

I was quite impressed that it worked at all. Last time I did it, with an older printer, the printer barfed after 10 copies as the spool file was too big for it.

It was slow, but not as slow as manually feeding the three passes, which also incurred the risk of messing up the paper orientation, and ruining the first two passes by putting the names on the inside for example.

Did you ever release your modified Printers app?

Not generally, a couple of people did try it for me. If anyone wants to try it just drop me an email webmaster@tankstage.co.uk .
I will include the modified source as well…
At the time I did send what I had done to ROOL, but because it was based on !Printers+ which was released under a different licence, they couldn’t use it.

I’ve been wondering recently what happens when a second print job occurs right after the first one, when the destination is to file. The file name is fixed (it defaults to “Printout”), so… does the second job get appended to the first one? Does it overwrite the first one?

About 7-8 years ago I did convert 80% of !Printers+ to be a toolbox app.

Please forgive me for being a bit slow on the update, but… that may be very good news. Do you mean you’ve translated it to a different language too?

Who owns the copyright of Printers+?

Do you mean you’ve translated it to a different language too?

No, I just split the massive basic file into smaller sections..
The source for !Printers+ is here and it’s released under Mozilla Public License 1.1 (MPL 1.1), and the “members” of the project are David Marston, John Tytgat and “Tempus Fugit”.