I did say that I would produce a colour separation routine to be added to the printing system this month but due to requests about changes and updates to the printing system, I have decided to hold the colour separation over to next time.

Changes...

2) Pre-Scanning - JPEG SWIs require quite a large amount of memory during execution. This is fine during screen updates since any out of memory errors, together with memory allocations, will occur quickly, but printing is a slow process and so if a JPEG image needs to be printed at the bottom of a page, or the JPEG SWI is one of the last commands in the printing loop, the error could be quite a while into the printing process. There is nothing more frustrating or expensive in time and paper/ink than to get to the bottom of a page only to find that an image won't print due to the lack of memory.

To get round this problem, a pre-scanning of the print rectangles was introduced from !Printers 1.22 onwards when used with RISC OS 3.6+. Pre-scanning print rectangles allows the computer to find any memory overheads required before any printing starts. So any commands inside the print rectangle aren't acted upon in a pre-scan unless they require extra memory. This extra memory is then allocated during the pre-scan. For most programmers, this doesn't affect their program.

To follow the next part, I suggest looking at my article in the May edition of Archive (13.8 p39).

Detecting pre-scanning

SWI"PDriver_Info" - If bit 13 in the features word (returned in register 3) is set, this
printer software will pre-scan if required. It is best to allow pre-scanning to occur (if the
printer allows it).

To activate the pre-scan, bit 24 of register 0 in SWI"PDriver_DrawPage" must be set. This will return the bit set if a pre-scan is about to start.

Note: If your printer software doesn't allow a pre-scan, don't set this bit unless you require 16777216+ copies of the document to be printed!! I will let you decide why.

SWI"PDriver_GetRectangle" will set bit 24 of its register 0 if the current rectangle is to be
pre-scanned.

So, for pre-scanning, do the following:

• Check if the printer allows pre-scanning using PDriver_Info,
• If so, set bit 24 in r0 in "PDriver_DrawPage",
• If not, clear bit 24

Any commands inside the printing loop should not need any modification. If you feel you wish to speed up a pre-scan (perhaps on non-StrongARM machines), you can see if bit 24 is set to allow a bypass of commands that you know won't require any extra memory. This sounds a good idea but I doubt if any change will be noticed, and the PRM states that pre-scanning might be used for other purposes than checking memory requirements, so be warned.

3) Aborting print jobs - Quite a few of us have started printing a page only to find a mistake on the first few lines and therefore have had to abort the printing. This can sometimes cause problems for the following print job. This is caused because the printer may be interrupted part way through an escape code sequence. If a new print job is then started, the printer takes the first few codes of the new job as being the remainder of the escape sequence of the previous job resulting in, at best, printing rubbish or, at worst, crashing the system. In my article in May, I suggested a method to help out. This works most of the time. From RISC OS 3.5, printer dumpers should be able to cope better although it means the abort won't take effect quite as quickly since the current escape sequence has to be completed before an abort takes place. For those who are technically minded, this is coded into PDumperReason_AbortJob (reason code 6). Bit 24 of register 3 is set and R4 now points to the PDriverDP and dumper configuration data thus allowing the printer dumper module to continue to the end of the current escape sequence, then send a form feed or reset printer codes.

4) RISC OS 4 Printing System - Major changes have been made in the printing system which should be transparent to the user. From this article's point of view, the printer definition file's structure has been altered. The new !PrintEdit application will load the older definition files but when they are saved, they have the new structure. This means they won't work under the RISC OS 3.7 version! I won't go into the details as yet but be warned; always keep a backup copy of any definition files you have used with RISC OS 3.7 before altering them under RISC OS 4.

You can download the latest version of RISC OS 4 printing software from http://developer.riscos. com/public/Releases/Printers/.
The latest version is 1.64 and it seems very stable even under RISC OS 3.7.

You can download all the printer definition files too. Some of these are already in the new format, but many are still in the old format.

New printers

Well that's it for this month.