Method and System for Interfacing With a Computer Output Device

This invention relates generally to a computer method and system for interfacing with devices and, more specifically, to a method and system for implementing device drivers.

Computer systems output data to a variety of output devices, such as, printers, plotters, and video displays. Each device typically has a manufacturer defined device-specific protocol for communicating with the device. A computer system, under the control of an operating system, uses the protocol to communicate with a device. Thus, an operating system must know the protocol for each device to which it communicates. It would be impractical for an operating system developer to provide an interface to every available output device. Moreover, it would be impracticable to provide an interface to output devices that have not yet been developed. To overcome these difficulties, operating systems interface with devices indirectly through device drivers. The operating system developer defines the functionality of the operating system/device driver interface. Each manufacturer of a device then provides a device driver, which implements the operating system/device driver interface that is consistent with the device protocol. The operating system loads the device driver and invokes its functions to communicate with the device.

A primary goal of operating systems is to provide an application program environment which is output device independent. This independence means that an application program can output its data to various types of devices without modification of the program. For example, an operating system can redirect output of application program data to a display, printer, or file without the application program being aware of the redirection.

FIG. 1 is a block diagram illustrating a prior device driver configuration. Computer system 100 comprises application program 101, graphics device interface 102, and device drivers 103. Each device driver interfaces with a device 105 that is attached to computer system 100. Application program 101 outputs data using functions provided by the graphics device interface (GDI) 102, which is typically part of an operating system. The GDI effects the output of data by invoking functions implemented by the device drivers 103 in accordance with the operating system/device driver interface. The graphics device interface and device drivers insulate the application program from the different characteristics of the devices. The GDI provides a variety of functions for accessing the devices in a device-independent manner.

The developer of a graphics device interface provides a definition of its functionality to the developers of application programs. An example of such a graphics device interface is described in Programming Windows 3.1 by Charles Petzold, published by Microsoft Press. The developer of the graphics device interface also specifies the behavior of each function that a device driver (the operating system/device driver interface) must implement. For example, one graphics device interface specifies six categories of functions that must be implemented by a device driver: (1) initialization, (2) information, (3) output, (4) attribute, (5) mode, and (6) escape. In the following, reference is specifically made to outputting data to a printer. One skilled in the art would appreciate that such references also apply to other output devices. Each of the functions that must be implemented by a device driver is described.

An application program outputs data to a particular device by first requesting the graphics device interface to create a device context. The device context identifies the particular device and contains the current state of the device. For example, the device context may contain the current font and paintbrush information. The graphics device interface provides the application program with a handle to a created device context. Whenever the application program outputs data to the particular device, the application program passes the handle to the device context. The graphics device interface functions use the passed handle to access the device context.

When developing a device driver, the developer codes, tests, and debugs each device driver function. This process requires a thorough understanding to the windowing environment, the graphics device interface, the device hardware, and the device communications protocol. This development process is complex, time consuming, and costly.

It is an object of the present invention to provide a method and system for configuring device drivers.

It is another object of the present invention to provide a method and system for storing data describing device-specific attributes.

These and other objects, which will become apparent as the invention is more fully described below, are provided by a method and system for configuring device driver. In a preferred embodiment, a device driver comprises a minidriver associated with each output device and a universal driver. Each minidriver implements a plurality of minidriver functions for controlling the outputting of data to the output device by invoking functions of the universal driver. During execution of a program, the program selects an output device and invokes the minidriver functions of the minidriver associated with the selected output device. An initialization function of each minidriver invokes an initialization function of the universal driver passing an indication of and attributes of the selected output device. Other minidriver functions invoke an analogous function of the universal driver passing an indication of the selected output device. The initialization function of the universal driver processes the passed attributes and stores the indication and the processed attributes. Each analogous function accesses the stored attributes and performs the behavior of the analogous function to effect the controlling of the output device.

FIG. 1 is a block diagram illustrating a prior device driver configuration.

FIG. 2 is a block diagram illustrating a preferred device driver configuration of the present invention.

FIGS. 3A, 3B, and 3C are block diagrams illustrating the layout of device data in a preferred embodiment.

FIG. 4A is a flow diagram illustrating a typical device driver function implemented by a minidriver.

FIG. 4B is a flow diagram illustrating an alternate embodiment of a device driver function implemented by a minidriver.

FIG. 5 is a flow diagram of a typical initialization device driver function implemented by the minidriver.

FIG. 6 is a block diagram illustrating the device data structure.

FIG. 7 is a flow diagram of the Enable function of the universal driver.

The present invention provides a method and system for implementing device drivers. FIG. 2 is a block diagram illustrating a preferred device driver configuration of the present invention. Computer system 100 includes a central processing unit, computer memory, and input and output devices. The computer system executes application program 101, graphics device interface 102, minidrivers 203, and universal driver 204. The minidrivers and universal driver combine to preferably provide the same functionality and the prior art device drivers 103. Each device 105 has a corresponding minidriver 203. Each minidriver implements each of the device driver functions and contains data characterizing the corresponding device. In a preferred embodiment, each device driver function of the minidriver implementation (except for an initialization function) forwards its invocation to an analogous device driver function implemented by the universal driver. The universal driver also implements each device driver function. The universal driver functions control the interfacing with the destination device in accordance with the device characterization data, passed parameters, and device state.

The application program 101 initiates the output of data by invoking a GDI function of the graphics device interface 102 and specifying a destination device. The GDI function invokes the device driver functions of the minidriver 203 corresponding to the destination device. In a preferred embodiment, an initialization device driver function of each minidriver passes device characterization data to the universal driver. The universal driver stores this device characterization data (preferably within a device context) to be used by the other device driver functions of the universal driver. The other device driver functions of the minidriver 203 forward their invocation to the universal driver by invoking an analogous function of the universal driver.

MINIDRIVER

FIG. 4A is a flow diagram illustrating a typical device driver function implemented by a minidriver. The function forwards the invocation to the analogous universal driver (unidriver) function. The device driver function preferably passes the same parameters it receives to the device driver function of the universal driver. FIG. 4B is a flow diagram illustrating an alternate embodiment of a device driver function implemented by a minidriver. In this alternate embodiment, the device driver function, in addition to forwarding the invocation, performs a device-specific process before and after forwarding the invocation.

FIG. 5 is a flow diagram of a typical initialization device driver function implemented by the minidriver. This initialization function reads the device characterization data, stores the device characterization data in a format expected by the universal driver, initializes the device context data for the graphics device interface, initializes device state information, and invokes the analogous universal driver function.

In the following, reference is made to printer characterization data as a specific example of device characterization data. One skilled in the art would appreciate that the concepts described are applicable to other types of devices.

PRINTER CHARACTERIZATION DATA OVERVIEW

Printer characterization data includes device data and font data. The device data describes the attributes of a printer, except for the font data. The device data is organized into data structures of related attributes so that similar printer models can share data structures. A printer model can be described as a collection of attributes. The device data contains the printer control commands (e.g., escape sequences). The printer characterization data is described below in detail in the section entitled "Printer Characterization Data Details."

The font data describes the attributes of a font. A font is defined as a pitch, point, symbol set, and typeface combination. Each font data structure describes a single font. The device data contains references to the font data structures corresponding to the fonts supported by the printer.

A device data file contains a description of one or more printers. Each printer is described by a collection of various attribute data structures. The attributes encompass aspects of selecting a paper size and source, rendering text and raster data onto a page, ejecting pages, and selecting an output bin.

The device data file contains a header data structure that describes the size, count, and offsets to each of the other structures in the file. The device data file contains a MODELDATA structure for each printer model described. Each MODELDATA structure describes the capabilities and physical attributes of a printer model. Each MODELDATA structure references other attribute structures in the device data file. All printer commands, escape codes, and other variable length data are stored in a HEAP section of the device data file. Each printer control command is described in a Command Descriptor structure, and the location of each Command Descriptor is referenced from an attribute structure as an offset from the beginning of the HEAP section. The following is a brief description of the types of attribute structures used to characterize various attributes of a printer.

FIGS. 3A, 3B, and 3C are block diagrams illustrating the layout of device data file in a preferred embodiment. The device data file 300 comprises header data 310, attribute structures 320, and heap 330. The header data 310 contains an identification field 311, number of entries field 312, horizontal and vertical master units field 313, heap offset field 314, file size field 315, and header array 316. The identification field 311 contains an indication that the file is a device data file. The number of entries field 312 indicates the number of entries in the header array 316. The horizontal and vertical master units field 313 are described below. The heap offset field 314 contains the offset from the start of the device data file to the heap 330. The file size field 315 contains the size of the device data file 300. The header array 316 contains an entry for each type of attribute structure. Each header array entry contains a length field 316A, a count field 316B, and an offset field 316C. The length field 316A contains the length in bytes of the corresponding type of attribute structure. The count field 316B contains the number of different attribute structures for the corresponding type of attribute. The offset field 316C contains the offset within the device data file 300 of the array of corresponding attribute structures. The attribute arrays 321, 322, and 323 are stored in the attribute structures 320. Each attribute array contains an entry for each different description of an attribute type. Each printer model defined by the device data file has a corresponding entry in the MODELDATA attribute array. The MODELDATA structure 321A contains model specific data including an array of multiple attributes and an array of single attributes that describe the printer model. Each entry in the multiple attribute array is an offset within the heap 330 of a list of indexes for the associated multiple attribute data structures. Each entry in the single attribute array is an index into the corresponding attribute array.

UNIVERSAL DRIVER

The universal driver provides an implementation for each of the device driver functions. The universal driver functions control the interfacing with the destination device in accordance with the printer characterization data, passed parameters, and device state. In a preferred embodiment the Enable function of the universal driver receives a reference to the printer characterization data of a minidriver. The Enable function initializes a device data structure which contains data derived from the printer characterization data stored in a format for efficient access and contains the current state of the printer. The device data structure is stored as part of the device context. Each of the other functions of the universal driver accesses the device data structure when outputting data to the printer.

FIG. 7 is a flow diagram of the Enable function of the universal driver. This function is invoked by each minidriver when an application wishes to create a new printing surface or context. This function initializes the device data structure. In step 701, the function initializes the device mode data based on information provided by the invoking minidriver. If the invoking minidriver does not provide certain information, then the function retrieves default information specific to the printer and initializes the device mode data accordingly. In step 702, the function initializes a helper function dispatch table. The helper function dispatch table contains an array of pointers to functions for drawing into banding bitmaps. A banding bitmap represents a portion of the printing surface. If a bit in the bitmap is set, then the corresponding dot on the printer is printed. Different sets of helper functions may be selected based on the number of colors in the printer. The Enable function initializes the helper function table with the appropriate helper functions. The universal driver uses the function pointers stored in the helper function table to draw to the banding bitmap. In step 703, the function initializes resolution information. For example, the resolution data includes the number of pels per inch. In step 704, the function initializes the paper format information of the device data structure. The information is initialized based on the paper size, model data, resolution, paper source, and device mode data in the printer characterization data. In step 705, the function initializes the call-back table. The universal driver invokes a call-back function of the minidriver to perform minidriver specific processing. In step 706, the function determines the amount of memory available in the printer based on the model data. This information is used to avoid out-of-memory errors when downloading fonts and graphic bitmaps to printers. In step 707, the function determines the spot diameter (a measurement of how closely the printed dots overlap each other) based on the information in the resolution data. The spot diameter is used to adjust the intensity of the output based on the spot size of the ink. In step 708, the function builds a table of all the printer fonts available based on the information in the model data and the printer font metric resource provided by the minidriver. This data is used by the function RealizeObject to convert a logical font request to a physical font. This conversion is called font mapping. The use of a table font obviates a need to access the disk or minidriver to perform font mapping. The function also initializes commands needed to select and deselect each font. In step 709, the function retrieves the width and height of the principal font and stores it in the device data structure. In step 710, the function determines whether the printer supports a rectangle fill capability and initializes the device data structure accordingly. In step 711, the function establishes a priority queue for printers that must be accessed serially, such as dot matrix printers. This queue is used to sort text requests. In step 712, the function initializes a command table. The command table is an array of offsets to command descriptors. These command descriptors specify the commands that are to be sent to the printer to enable a certain feature. For example, a certain command descriptor would specify the codes which cause the printer to enable underlining, and another command descriptor would cause the printer to disable underlining. In step 713, the function allocates memory for font download information. The function then returns.

Each of the other device driver functions that are implemented by the universal driver performs the behavior of the function using the data supplied by the invoking minidriver and stored in the device data structure.

DEVICE DATA STRUCTURE OVERVIEW

FIG. 6 is a block diagram illustrating the device data structure. The device data structure is described below in detail in the section entitled "Device Data Structure Detail." The device data structure contains information necessary to control the output of information to a designated printer. The device data structure includes the following information. Type of device data 601 indicates the type of printer (e.g., laser). General flags 602 contain various flags relating to paper source, rectangle fill, and text capabilities. The master unit data 603 contains the least common multiplier of all resolutions and printer command units. The copy data 604 contains information relating to number of copies of a document requested and number of copies allowed. Font data 606 includes the count of fonts available, default font, and a reference to a font map. The handle of device context data 606 contains a reference to the device context associated with the device data structure. The handle of the minidriver data 607 contains a reference to the generic printer characterization data for this data structure. The paper format data 608 contains information relating to the format of the paper such as physical paper size, printable area, margins, and current paper bin. The band format data 609 contains information relating to the banding process. The banding information includes the height and the width of the band. The bitmap data 610 contains a buffer used by the universal driver to generate a shadow bitmap based on the amount of memory available in the system and the resolution data. The shadow bitmap is downloaded to the printer to effect output. The printer state data 611 contains the current state of the printer, such as, current cursor position, last font selected, and last color selected. The clipping/bounding rectangle data 612 defines the clipping and bounding rectangles. The resolution data 613 defines the resolution of the printer. The call-back functions table 614 contains pointers to each of the call-back functions defined by the minidriver. The index to model data 615 is an index into the model data array of the printer characterization data. The command array 616 contains offsets to the command descriptors within the heap of the printer characterization data. Each entry in the command array specifies the commands needed to enable or disable a particular capability of the printer (e.g., underline, bold, etc.). The spooling data and buffers 617 contain information that allows the universal driver to spool data from various minidrivers for transmission to a single printer. The banding bitmap data 618 contains information describing the current state of banding. The download controls information 619 relates to the download capabilities and state of the printer. This data includes total amount of physical memory available on the printer and number of fonts downloaded. The miscellaneous data 620 includes other data needed to control the outputting of data to the printer.

PRINTER CHARACTERIZATION DATA DETAILS

The generic primer characterization (abbreviated as GPC) is intended to provide an application independent way of describing the total functionality and capabilities of one or more printers. It is done in a such a way that a printer driver will be able to interpret the GPC data, and be able to correctly render text and/or graphics onto a page. The scope of the GPC is intended to cover, but not limited to, raster printing devices such as dot matrix, ink jet, and laser printers. It is expandable to cover vector/plotter type commands. The intended goal of this characterization is to contain enough information so that primer drivers for Microsoft Windows can obtain all of the information they need from it.

The GPC is organized into 3 primary components, device data, font data, and character translation table data. The device data contains a number of different structures that describe all attributes of one or more printers, with the exception of font data. The device data attempts to group related attributes into logically cohesive structures so that similar printer models (such as Epson 9 pin printers or IBM 24 pin printers) can be easily supported from the same table. Each printer model can be described as a collection of attributes, and can explicitly specify which attributes it shares with other primers and which are unique to it. All of the printer control/escape commands are also stored in the device data. The font data is organized in such a way so that each `font` (defined as a single pitch/point/symbol set/typeface combination) is described as a separate data resource. The list of fonts that are available for a particular printer, or for a particular font cartridge, are referenced from the device data. The character translation data, currently only used by the Windows Universal Driver Library, provides a means to remap the printers native character set into the Windows ANSI character set. These components are used as resources in the Windows environment, and are grouped together and referenced from a .RC file. The .RC file also contains descriptive strings identifying the name(s) of the printers and other descriptive information.

Definitions are provided below for some the terms contained in this specification.

DEVICE DATA FILE FORMAT

1. Overview

The device data file provides a way of describing one or more printers as a collection of various attributes. These attributes encompass aspects of how a printer selects a paper size and source, renders text and/or raster data onto a page, ejects the page and selects an output bin. Each of these attributes is described in various data structures in the device data resource file. The data is organized in such a way so that a printing engine need only examine those structures that describe the desired printer model and no others.

The device data file always starts with a header section that describes the size, count, and offsets to each of the other structures in the file. One of the key structures referenced from the header is MODELDATA, which describes the capabilities and physical attributes of one or more printer models. Each MODELDATA structure references which other structures in the device data table that it supports. Multiple printer models may be supported by the same device data table. All printer command/escape codes and other variable length data are stored in the HEAP section. Each printer escape/control command is expressed in a Command Descriptor structure, and the location of each Command Descriptor is referenced from an individual structure as an offset from the beginning of the HEAP section. The following is a brief description of the structures used to characterize various attributes of a printer.

2. Header

The file header (defined as DATAHDR below) provides a way of tracking the size, count, and offset to each of the other structures in a file. The format is as follows:

3. MODELDATA structure

The MODELDATA structure describes the attributes of a single printer model. Multiple MODELDATA structures can be combined in a single device data table assuming they share some common data. A single MODELDATA structure contains all of the references to the graphics resolutions, paper sizes, fonts, etc. that are appropriate for that model so that printers sharing some, but not all, of the same characteristics may be combined in a single table. Multiple printer models may be referenced by a single MODELDATA structure assuming they share 100% of their characteristics including available fonts, carriage widths, paper bins, graphics resolutions etc. The stringtable in the .RC file is used to store text strings describing the names of the printer models supported. The Windows Universal Driver library requires that MODELDATA structures are associated with a descriptive string containing the name of the printer model both explicitly in the sIDS field, and implicitly where the stringtable entry with an ID of 1 describes the 1st MODELDATA structure, an ID of 2 describes the 2nd etc.

The following 4 flags, fCurves, fLines, fPolygonals, and fClip are part of the standard Windows GDIINFO structure and are used to describe various types of vector graphics capabilities. For individual printer drivers that wish to support these capabilities, the driver must contain code to handle the DDI call without attempting to call UNIDRV.DLL, and have the appropriate bit set to indicate this ability. For example, if CC.sub.-- CIRCLES in fCurves is set, the mini-driver must handle the DDI Output() call when style=OS.sub.-- CIRLE. If a mini-driver does not contain code beyond what is required do call the Windows Universal Driver library, these fields should be left blank.

The following flag fRaster is used to describe various raster capabilities. This field should be left blank and will be provided by UNIDRV.DLL to GDI.

4. RESOLUTION structure

A RESOLUTION structure is used to describe a single graphics resolution. It contains all of the information needed to encode and transmit bitmap raster graphics data.

5. PAPERSIZE structure

The PAPERSIZE structure describes data about a single paper size. It describes the physical and printable dimensions of the page and other information required to instruct the printer to correctly handle this paper size.

6. PAPERQUALITY structure

The PAPERQUALITY structure describes a single paper type. It is used to characterize attributes of types of paper (such as grades of paper, transparencies, etc.) or special concerns introduced by using a particular paper quality.

7. PAPERSOURCE structure

The PAPERSOURCE structure describes a single paper source, feed method, or bin. It is used to characterize limits or special concerns introduced by using a particular paper source.

8. PAPERDEST structure

The PAPERDEST structure associates a string ID with an offset to a printer command (OCD) to describe paper output bins/destinations.

9. TEXTQUALITY structure

The TEXTQUALITY structure describes an attribute of hardware fonts such as NLQ, Draft, etc.

10. COMPRESSMODE structure

The COMPRESSMODE structure describes methods in which data can be sent to the printer in condensed form, and the printer commands needed to control them.

11. FONTCART structure

The FONTCART structure contains data describing font cartridges. Each FONTCART structure describes a single font cartridge, which in turn references which font resources are contained in that cartridge. This allows different font cartridges to share font data if appropriate.

12. PAGECONTROL structure

The PAGECONTROL structure contains several OCDs used for printer commands used to select attributes of a single page or print job. In addition, there is information describing the order in which commands should be sent to the printer at the beginning of a document and beginning of a page.

13. CURSORMOVE structure

The CURSORMOVE structure contains information on how to move the cursor/current position from one point to another on the page.

14. FONTSIMULATION structure

The FONTSIMULATION structure describes various printer commands to enable and disable various character attributes such as bold, italic, underline, etc.

15. DEVCOLOR structure

The DEVCOLOR structure describes the way in which a device handles color for both graphics and text. The DEVCOLOR structure can support devices that process color data either one plane at a time or one pixel at a time. Note that much of this is preliminary, and may be changed as more devices using color come to market.

16. RECTFILL structure

The RECTFILL structure describes methods and commands to fill a rectangular area.

17. DOWNLOADINFO structure

The DOWNLOADINF0 structure contains all information needed to download fonts. It contains several bitfields that describe the order in which printer commands must be sent, limitations on how the printer can handle download fonts, and what control codes are available. It also contains references to all of the necessary control codes used in the downloading process.

18. HEAP section

The HEAP section contains all of the printer control/escape codes, lists of indices, and other variable sized data that is referenced from other structures in the table file. The location of the HEAP section is referenced from DATAHDR.1oHeap. Each printer control/escape code is stored in a Command Desciptor (CD) in the format described in the following section. Multiple structures may refer to the same command descriptor if appropriate.

a) CD (Command Descriptor) structure

The Command Descriptor structure is used to describe each printer command referenced from other structures in the table. It can be expressed in 2 formats, a simple command descriptor consists of a CD structure containing the length and content of a printer control/escape code. An extended command descriptor has the same format as a simple, but is followed by one or more EXTCD structure(s) to contain information on how to calculate values for parameters referenced in the command string. The EXTCD structure contains information on what units each parameter should be calculated in, and maximum and minimum allowable values. The format that the parameter is sent to the printer in is determined by the command marker in the command string (rgchCmd). If a command has multiple parameters that have identical EXTCD structures, a single EXTCD structure can be used to apply all parameters. While the file format may allow it, the Windows Generic library requires that either EXTCD.sUnit or EXTCD.sUnitMult may be used individually, but both may not be used in the same EXTCD structure.

b) Parameter formats

The format that should be used to express a parameter to a printer is determined by the type of command marker found in the CD.rgchCmd[ ] string. These markers are stored in `C` style formatted strings. The format characters are preceded by `%`. The predefined formats are as follows:

d: Parameter as ASCII decimal number.

s: Parameter as signed ASCII decimal number.

c: Parameter as byte.

l: Parameter as word, LSB first

m: Parameter as word, MSB first.

h: Hexadecimal ASCII number.

o: Octal ASCII number.

q: Qume hexidecimal ASCII number. (common on Toshiba/Qume devices) [others to have support added as appropriate]

Note: To have a `%` (ASCII 37) sent to the printer, use a `%%` in the format string.

19. Calculating printable regions

Determining the exact printable region on a given page may be influenced by many factors. Physical attributes of the printer itself, the paper size, and the paper source/feed method may all impact the size and behavior of the printable region. The following algorithm should be used when attempting to determine the size of the printable region.

The printable region should be calculated by taking the X and Y page dimensions from PAPERSIZE.sSize.x and PAPERSIZE.sSize.y, and subtracting the top, bottom, left, and right values from PAPERSIZE.rect from the appropriate sides. If PAPERSIZE.rect.left is less than MODELDATA. sLeftMargin, MODELDATA. sLeftMargin should be used in place of PAPERSIZE.rect.left. If the remaining printable area (PAPERSIZE.ptSize.x--the currently calculated left and right margins) is larger than MODELDATA.ptMax.x (maximum printable area), the difference between these two values needs to be split and used as unprintable left and right margins (Note that this should only occur when the end user has requested a user defined paper size). If PAPERSIZE.fGeneral has the PS.sub.-- CENTER bit set, the difference should be divided evenly, otherwise it is assumed to entirely describe the right unprintable region.

For user defined PAPERSIZEs, the User Interface should allow any paper size ranging between MODELDATA.sMin.x and MODELDATA.sMin.y for the smallest allowable paper size, and MODELDATA.sMaxPhysWidth and MODELDATA.sMax.y for the largest allowable page size. The printable region should be calculated by the same algorithm described above.

II. FONT FILE FORMATS

All of the font metric information is represented in the .PFM file format documented in the Windows SDK, with a DRIVERINFO structure defined for use with the Windows Universal Printer driver library. The basic structures from .PFM files are listed here, descriptive information can be found in the Windows SDK, which is hereby incorporated by reference. The DRIVERINFO and DOWNLOADDATA structures are described at the end of this section. The following information is taken from pfm.h.

1. Standard Font Structures

The following are standard Windows font metric and information structures. Detailed descriptions of these may be found in the Windows SDK.

2. DRIVERINFO structure

The following structure is used by all PFM files that are used by drivers supported by the Windows Universal Printer driver library.

III. CHARACTER TRANSLATION TABLE FILE FORMATS

1. Background

A character translation table is used by the Windows Universal Printer driver library to remap characters from the printers native character/symbol set to the Windows ANSI set. The Windows Universal Printer driver library will provide support for some of the common code pages/symbol sets, so that this data will not need to be propagated redundantly in a large number of individual printer drivers. It is intended that printer drivers supporting devices with less common code pages/symbol sets will contain their own character translation table resources. Any given driver can mix and match either of these types of character translation tables as needed. Character translation tables provided by the Universal driver are referenced from the mini driver by negative numbers corresponding the resource ID values (from the Universal Driver), and character translation tables provided by the mini driver are referenced by positive numbers corresponding to the resource ID values (from the mini driver).

2. Predefined Translation Tables

As previously stated, the Windows Universal Printer driver library will provide support for some of the common code pages/symbol sets, and allow drivers to support less common ones. The list of character translation tables currently supported by the Windows Universal Printer driver library is as follows:

3. TRANSTAB structure

There are 3 formats of character translation tables available for use. The first is a single byte-to-byte translation used for simple remappings. The second is a single byte-to-two bytes translation, where the second character is used to overstrike the first. The DI.sub.-- BKSP.sub.-- OK flag determines how the cursor should be repositioned to overstrike the second character on the first. The third allows a single byte-to-variable length string that may contain commands to change symbol sets, or whatever else is necessary, to create the desired character. Any printer commands sent from here cannot change the permanent state of the printer.

IV. STRUCTURE LISTINGS

The following structures are referenced from other structures described above.

V. CALLBACK FUNCTIONS

Two callback functions are defined which deal with the RESOLUTION structure.

1. RESOLUTION.fDump

By setting the RES.sub.-- DM.sub.-- CALLBACK bit flag in RESOLUTION.fDump, the minidriver will have the ability to assume responsibilities for implementing the Dump function. This function controls rendering raster data from an internal GDI format to a hardware specific format.

2. RESOLUTION.fBlockOut

By setting the RES.sub.-- BO.sub.-- CALLBACK bit flag in RESOLUTION.fBlockOut, the minidriver will have the ability to assume responsibilities for implementing the BlockOut function. This function controls how raster data will be sent to the output device.

The RES.sub.-- BO.sub.-- CB.sub.-- FILTER.sub.-- GRX bit flag in RESOLUTION.fBlockOut allows the minidriver to alter the format of raster graphic data before sending to the output device. This is typically useful if a specific device addresses pins on the printhead in an unusual way (such as older Okidata dot matrix printers for example), or other unusual ways the device requires raster graphic data (such as the "24 raster bits in 4 bytes" format common amongst Toshiba dot matrix printers).

To implement RES.sub.-- BO.sub.-- CB.sub.-- FILTER.sub.-- GRX in a minidriver, the following steps are necessary:

1) Set the RES.sub.-- BO.sub.-- CB.sub.-- FILTER.sub.-- GRX bit flag in RESOLUTION.fBlockOut for all RESOLUTION structures implementing this ability.

2) Export "CBFilterGraphics" as ordinal 300 in the EXPORTS section of the definition (.DEF) file for your minidriver.

3) Import "WriteSpoolBuf" as ordinal 300 in the IMPORTS section of the definition (.DEF) file for your minidriver.

4) In the <drvname>.c file for your minidriver, you will need to add the function to perform the changes upon the raster data needed by the device. This function will need to be defined as follows:

short FAR PASCAL CBFilterGraphics(LPBYTE lpdv, LPSTR lpBuf, WORD len)

lpdv Far pointer to private data used by the Universal driver, Your function should not change this data, but will need it when calling WriteSpoolBuf to return the raster data you have altered to the Universal driver.

lpBuf Far pointer to buffer holding raster graphic data. Amount of data in buffer described by len value.

len WORD describing amount of raster data (in bytes) at lpBuf.

Return Value: The total count of bytes of raster data after your function has processed the raster data. This may be the same as the `len` value passed in, but not necessarily so.

After CBFilterGraphics has finished with changes the raster graphic data, it should call the function described below to provide the data to the Universal driver. Please note that you will have to prototype this function in your <drvname>.c file to satisfy the compiler.

short FAR PASCAL WriteSpoolBuf(LPBYTE lpdv, LPSTR lpNewBuf, WORD newlen);

lpdv Far pointer to private data used by the Universal driver, this should be identical to what was passed in.

lpNewBuf Far pointer to buffer holding changed raster graphic data. Amount of data in buffer described by newlen value.

newlen WORD describing amount of raster data (in bytes) at lpNewBuf.

VI. SCALABLE DEVICE FONTS

Scalable font width are specified in the EXTENTTABLE of a PFM file, details as described in the Windows 3.1 DDK Printers and Fonts Manual, which is hereby incorporated by reference. Note that for internal scalable font PFM files (i.e., those compiled with the driver), all values in PFMHEADER must be expressed in device units as defined by the values dfHorizRes and dfVertRes, and dfHeight must be non-zero. For external scalable PFM files (i.e., those installed via the font installer), the format used by the HPPCL5A driver is preferably supported for compatibility.

DEVICE DATA STRUCTURE DETAILS

Table 1 is a C language listing of definitions of the device data structure and supporting structures. Table 2 is a C language listing of definition of entries into a command description table. ##SPC1##

Although the present invention has been described in terms of a preferred embodiment, it is not intended that the invention be limited to this embodiment. Modifications within the spirit of the invention will be apparent to those skilled in the art. The scope of the present invention is defined by the claims that follow.