Windows Print Spooler (-Q and -P)

In Windows, there are two ways that your application can print something. It can either send data directly to an output device (by opening the appropriate port), or it can use the Windows print spooler. Most applications use the spooler because it allows the user to queue-up a series of documents and then print them out in the background, while performing other tasks. In this regard, the Windows print spooler works much like spoolers common to other operating systems (for example, the lp program on UNIX machines).

In other ways, however, the Windows print spooler is very different from classical spoolers. These differences derive from the graphical nature of Windows and Windows applications and can affect what you can accomplish from COBOL. This topic discusses how the Windows print spooler works and how it affects your programs. It includes information on using the -Q and -P configuration options to assign printers to the print spooler and details for using these options with the WIN$PRINTER library routine.

Programs that use traditional spoolers usually work like this:

The program sends text, data, and printer-control sequences to the spooler.
The spooler saves the data on disk. As resources become available, the spooler sends the information on to the port driver that manages the system's printer.
The port driver delivers the data stream to the printer, which produces the document.

In this scenario, the program provides all of the printer-control coding. The spooler and port driver simply coordinate transfer of the data to the printer.

The print spooling method under Windows is different. The sequence of operations typically works like this:

The program calls the Windows graphical Application Programming Interface (API) to describe a logical image of each page in the document. This Windows graphical API is called the Graphical Device Interface (GDI).
The GDI subsystem constructs a low-level description of each page, which is passed to the print driver. The print driver and GDI work together to construct the data stream needed to produce the proper output on the printer. This data stream is temporarily stored on disk.
As resources become available, the spooler sends the disk data to the port driver for the printer. From this point on, the process is the same as for a traditional spooler.

The operation of the spooler itself is very similar under both scenarios. What is different is that, under Windows, the GDI and print driver are responsible for producing the printer-control sequences, while in the traditional model, the program produces the control sequences.

This approach to the printing process allows Windows applications to produce graphical output without knowing how to drive specific types of printers. This greatly simplifies the printing task for sophisticated programs such as word processors and drawing programs.

However, for simple reports, this is much more complicated than the traditional approach. Instead of simply sending text data and carriage control codes, the application must go through an involved process of getting a device context, selecting and measuring an appropriate font, formatting lines of text and drawing them to the device context, and maintaining the necessary line and position information.

Fortunately, ACUCOBOL-GT simplifies this work. The runtime system contains print drivers that know how to simulate traditional style printing using the Windows spooler. To take advantage of these drivers, simply assign the print file to -Q printername or to -P SPOOLER. You can change fonts in the middle of a report when using the Windows spooler. Simply select the new font via the W$FONT library routine while the print file is open. You can change fonts at any time, even mid-line. Make sure that WFDEVICE_WIN_PRINTER is set to TRUE before you call W$FONT. When advancing lines, the runtime uses the height of the selected font to determine the height of the line, and the font must be associated with the selected printer.

Note: The process used by Windows to print (via the GDI) interferes with programs that attempt to control the printer directly. Programs that embed control codes in their print data (to perform various functions such as changing the printer's pitch, shifting to compressed print mode, or drawing a form on a laser printer) will not work under Windows because the GDI does not understand the control codes. Instead, it tries to treat the codes as regular text data to be drawn.

The process used by Windows has the advantage that an application does not need to know how to drive an individual printer, but has the disadvantage that an application cannot choose to drive the printer directly.

If you have an application that needs to control the printer directly, you have three choices:

Examine the WIN$PRINTER routine described below. It allows you to perform some basic control operations directly from COBOL.
Send the report directly to the printer by assigning the print file to the printer's device. This allows you to directly control the printer, but you lose the advantages of using the Windows print spooler.
Use the GDI to describe the print image you want. This generally involves calling an external function written in C or some other language that has direct GDI support. This choice provides the greatest flexibility, but can be a large amount of work.