PDRREF:Design Considerations for Hardcopy Drivers

For information on hardcopy drivers written to the graphics engine dispatch table, see the following chapters:

• Graphics Engine Hardcopy Drivers
• Presentation Manager Function Categories
• Exported Driver Function Reference
• Mandatory and Simulated Graphics Engine Function Reference

Design Considerations

The following design considerations only apply to hardcopy drivers:

   Banding
   Document processing
   Dynamic Job Properties
   Extended attributes
   Hardcopy device names
   Hardcopy driver migration
   Hardcopy driver output to file
   Help
   Job error dialog
   Output threads

Banding

Banding is another technique that is available to presentation drivers for raster technology hardcopy devices. Banding is the process of dividing a whole page into two or more bands (or strips) of raster data, which is recorded in memory as a bit map, and is then sent to the physical device or spooler. It is used to reach a balance between memory requirements and performance. This technique uses the graphics engine's journaling functions to save and replay a journal file of the calls to the Grexxx functions for a whole page.

The hardcopy driver handles the output page as a number of bands and creates a bit map large enough for one band at a time (see illustration below).

           ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
           ³       Band 1       ³
           ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
           ³       Band 2       ³
           ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
           ³         "          ³
           ³         "          ³
           ³         "          ³
           ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
           ³       Band N       ³
           ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

The device context origin of the bit map is manipulated so that it relates to each band in turn. The hardcopy driver replays the journal file as many times as necessary to write into each band. Note that Band 1 cannot be written into while the calls to the Grexxx functions are being journaled. This is because the Command flag, COM_DRAW, is turned OFF between calls to GreStartJournalFile and GreStopJournalFile unless the JNL_DRAW_OPTIMIZATION flag is passed in on the call to function GreCreateJournalFile(). The hardcopy driver is told not to perform any output while the Grexxx calls are being journaled unless the JNL_DRAW_OPTIMIZATION bit flag is set.

The size (width and height) of each band is determined by each hardcopy driver, dependent upon the type of physical device to which the output is to be sent and the amount of memory the hardcopy driver can use to build its bit map. As an example, a color laser printer might need the full 24 bits per pel, in which case, several bands might be needed to make a page. A simple dot-matrix printer that uses one bit per pel could treat the whole page as a single band.

The data for each band is sent as a single band to the physical device for an OD_DIRECT device context, or to the spooler for an OD_QUEUED device context with a data type of PM_Q_RAW. Note that the number of bytes of data that are sent might not be the same as the number of bytes required to create the bit map for a given band. This can be due to compression algorithms, which might be implemented in a given hardcopy driver and supported by a given physical device.

The technique of banding is performed by recording all of the graphics for a whole page in a journal file. When the journal file is complete (that is, the hardcopy driver has received a DEVESC_NEXTBAND escape, a DEVESC_NEWFRAME escape, or a DEVESC_ENDDOC escape), the hardcopy driver plays the journal file, reprocesses the calls recorded to produce each band in turn, and clips the graphics recorded in the journal file to each band output. After all bands are output, the journal file is deleted. This banding technique uses the graphics engine journaling functions to save and replay a journal file of the Grexxx calls. These graphics engine journaling functions are documented in Journal Functions (Hardcopy Drivers Only).

Each page of output is handled as a separate entity. The GreEscape routine for DEVESC_STARTDOC opens a journal file for the first page and registers it in the device context instance data. When GreEscape DEVESC_NEWFRAME or DEVESC_ENDDOC is received, the hardcopy driver writes the bands and closes the journal. If the escape code was DEVESC_NEWFRAME, the GreEscape routine opens and registers the journal file for the next page.

The following figure gives an overview of how the presentation driver performs.

[[Image:]]

Overview of Presentation Driver Performance

Document Processing

The following figure diagrams the state transitions for the GreEscape function calls used during document processing. The GreEscape function names are abbreviated for ease of reading. For example, GreEscape (DEVESC_STARTDOC) is shown as STARTDOC. See Spool File Creation for details on each of the output actions.

[[Image:]]

State Transitions for Document Processing by Hardcopy Drivers

Dynamic Job Properties

Unsupported DJP Items

====Using DEVESC_STARTDOC_WPROP and DEVESC_NEWFRAME_WPROP