Printer Drivers in RISC OS ========================== One of the principal aims of RISC OS is to enable small applications to work together harmoniously to achieve an aim, rather than having to build large monolithic programs (one of the original aims of Unix, in fact). This approach is reflected in the structure of printer drivers used in RISC OS. The first part describes what users have to know. The second part describes the reasoning behind the structure of printer drivers in RISC OS, at a level deeper than that required by the average user. What the User Thinks -------------------- RISC OS comes with two printer driver applications, !PSPrinter for PostScript printers and !DMPrinter for a range of dot matrix printers. If I posess a PostScript printer and I wish to print, I should do the following: Double-click on !PSPrinter. An icon will appear. Menu on this and check that the settings are right for where the printer is connected, e.g. net/parallel/serial etc. This setting will be retained in CMOS RAM, so it need only be done once. If I wish to print Text files, drag them onto the printer icon. They will get printed. If I wish to print from ArcDraw, click Print on the Print dialogue box after running !PSPrinter. The diagram will be printed. Or, drag the icon from the Save dialogue box onto the printer icon. If I wish to print from ArcPaint, it's exactly the same. If I with to print from any other editor program, it's exactly the same. If I have a dot matrix printer, run !DMPrinter. Click on the printer icon to produce a dialogue box of the correct type of printer. Click on the printer-type field to cycle through the various dot matrix printers supported, until it reflects mine. If I can't find mine, seek help. Drivers for other printers will appear, from Acorn and from others, in an analogous form, for other printers. New printer drivers will work with all existing applications, subject to the limitations of any particular printing device. How and Why ----------- I use the term "editor" to mean any sort of interactive program that prepares, changes and processes data files. This includes word processors, DTP packages, spreadsheets, draw programs, etc. I use the term "Foo" to refer to any editor program, which operates on "Foo data files": so, substitute ArcDraw, ArcPaint, or whatever as you read. I use the term "Poo" to refer to any printer capable of generating graphics, e.g. FX80, Apple LaserWriter, etc. In the general case, editors save data in files of their own format, with an appropriate file type. Only Foo understands Foo data files. Also, different printers are entirely different from each other, and a pain to drive. If each editor is to understand each printer, and there are X editors and Y printers in the world, then: (a) There is X*Y work to do (b) If a new printer type comes along, all applications need updating. Because of this, RISC OS separates printer drivers from editors so that they are separate programs. This means: (a) There is X+Y work to do (b) If a new printer type comes along, once a printer driver has been written for it, it will work with all applications. This is clearly a better situation, and is one of the main reasons why applications working together is important. How do we achieve this? The main step is to define an interface that all editors should use when talking to printers, a sort of "virtual printer interface". All editors then output to this virtual interface, knowing little of the characteristics of the physical printer itself. The "virtual printer interface" chosen in RISC OS is to say that the printer supports the same set of graphics primitives as the screen. This is because a WYSIWYG editor (where what you see on the screen is what you get on paper) will already contain code to render the data file using these primitives, and so printing is unlikely to require very much extra code. Each printer driver is implemented as a RISC OS relocatable module, which provides extra SWIs (system calls) concerned with starting, stopping and controlling a print job. The interface allows the printer driver to request specific rectangles of the picture being rendered in any order, to give it maximum freedom in manipulating buffer space etc. The interface to printer drivers means that an editor is not able to supply an acceptable user interface for setting printer-specific options such as quality/draft mode. For this reason, a separate application must exist for each possible printer driver, to allow any printer-specific options to be set. The printing of plain Text is such a basic facility that it is considered unacceptable to require the loading of ArcEdit. Furthermore, printers tend to provide a much simpler method for the printing of simple text than the facilities provided for arbitrary graphics. For this reason, every printer interface program provides simple facilities for the printing of plain text files. Resulting Implementation Guidelines ----------------------------------- Thus the following structure emerges. A printer interface program !PooPrinter is composed of the following elements: !Boot, !Run, !Sprites - Obey and Sprites files as normal. !RunImage - a program (usually written in Basic) which does the following: provide an icon on the icon bar provide menu entries for setting net/serial/parallel/file printer output provide printing of Text files to this specific printer provide a dialogue box specific to this printer type for setting any options Much of this program is the same for all printer drivers. PDriverPoo - a printer driver module which is *rmloaded by !Run. (plus any data files required by the above.) Conclusions ----------- This note has explained the background behind the structure of printer drivers in RISC OS. The scheme is simple for the user to understand, and yet provides many advantages for the author of both editor and printer driver. For more detail, consult the specification of the interface between printer driver and application.