Steve Mumford provides an overview of the printing process

In this month's tutorial I'll start to explain the intricacies behind using the RISC OS printer drivers to produce hard copy. As I've said before, parts of the process share similarities with the redrawing loops in WIMP applications, but as is to be expected we have to do some extra work to get the ink flowing.

In order to minimise the development necessary to support a given range of printers, RISC OS provides us with what amounts to an interface to a 'virtual printer' - in this way, programmers can take advantage of a prewritten core program, avoiding the duplication of what can turn out to be a large amount of code.

Printing is performed using a reduced collection of screen-drawing commands, and these are in turn intercepted and mapped onto appropriate printer commands by the centralised printer manager. This means the programmer can avoid having to know about the specifics of the printer in question; the same routine can produce output for mono dot-matrix, colour inkjet or Postscript-compatible laser printers.

General principles

The next important step is to determine what the printer's capabilities are, along with any useful information about the driver. The SWI PDriver_Info provides you with the printer's name, resolution and features. Once you've adjusted your application to take these details into account, it can proceed onto the next stage and open the symbolic filename printer: for output. Passing the returned file handle to the PDriver_SelectJob SWI either starts a new print job if the handle is unrecognised, or continues with an old one - the current print job is suspended if necessary.

If you've examined the contents of a Postscript file, you might have seen that there's a comprehensive list of all the fonts used within that document fairly near the start of the file. Certain printer drivers require you to give them such a list before printing starts in earnest, and the PDriver_DeclareFont SWI allows the programmer to broadcast a list of distinct fonts to the printer driver.

Drawing the page

The printer driver fields tbese calls before they're allowed to draw on the screen and redirects their output to the printer. Once one rectangle has been plotted, PDriver_GetRectangle is then called repeatedly until the printer driver is satisfied and all the rectangles have been drawn. Due to the mechanisms employed by different printers, the shapes of the rectangles requested will vary, as will their order - dot matrix and inkjet printers tend to ask for thin narrow strips that run across the page, whereas postscript printers with sizeable chunks of memory can build up the page in one go.

Eventually, the printer driver will complete its first page of output and will allow you to continue. If any other pages remain to be printed, PDriver_GiveRectangle can be called again and the above process repeated. Finally, the job can be terminated using PDriver_EndJob and the 'printer:' file can be closed.

Unlike window redrawing in the WIMP, which works smoothly in the multitasking environment, RISC OS printing tends to work best when singletasking; there are various problems with queue management which are exacerbated by attempting to multitask. However, it's simple enough to arrange a form of background printing in which a print file is written to disc in a short non-interactive phase, before being spooled a few bytes at a time to the actual printer during normal operation of the WIMP.

That's a rough outline of the steps we have to follow when printing. Next month I'll build a skeleton application and spread some ink on the page. See you then.