Facsimile and static presentation processing – Static presentation processing – Communication
Reexamination Certificate
1998-09-21
2004-11-30
Garcia, Gabriel (Department: 2624)
Facsimile and static presentation processing
Static presentation processing
Communication
C358S001130
Reexamination Certificate
active
06825941
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to output device characterization methods and device drivers, and more particularly to a method for characterizing and customizing output printer devices and a driver architecture for use therewith.
BACKGROUND OF THE INVENTION
The phenomenal growth of the computer industry in both the commercial and consumer market segments has spawned an increasing number of companies who provide both software and peripheral hardware products to the market. It becomes the job of the operating system designer to coordinate and ensure compatibility of data flow within, between, and without of the computers on which this software and peripheral hardware is installed. To ensure that the literally thousands of application programs are able to output their data to peripheral printing devices, the operating system designers have developed a graphics device interface (GDI). The GDI affects the output data from the application programs by invoking functions which allow access to printing devices in a device-independent manner. This GDI provides a uniform interface between the literally thousands of application programs and the output peripheral devices to which these programs wish to send data to be printed.
While the GDI provides a uniform interface from the application programs, it is unable to produce actual printer control commands which are capable of driving each of the hundreds of different models of printer devices available on the market. In the past each individual printer
10
1
,
10
2
, . . .
10
n
required its own individual printer driver
12
1
,
12
2
, . . .
12
n
as illustrated in FIG.
15
. These individual printer drivers
12
1
,
12
2
, . . .
12
n
, implemented various control functions for their respective printers based upon the standardized output from the graphics device interface
14
. These standard functions included initialization, information, output, attribute, mode, and escape. While each of these individual monolithic printer drivers provided the necessary interface to allow proper driving of each individual printer model, they were typically were several megabytes in size. The need for such extensive printer dirvers impacted not only the individual printer manufacturer, but also the individual computer system
16
into which it was to be installed. Specifically, a computer system
16
would require a significant amount of memory dedicated to the storage of individual printer drivers if more then one printer were to be supported by the system
16
. This obviously limited the space remaining within the computer system
16
for storage of application programs
18
. In addition, because of the complexity of printer drivers, different printer drivers tend to have various quirks (or bugs) that cause great headache for application developers. Consistent, high-quaility printing is a luxury for users. For the same reason, many printer devices do not have drivers for everyOS platoform. For example, many popular consumer printers dondo nott have Windows NT drivers.
For the purpose of easing the development of Windows printer drivers and improving the driver quality across the board, engineers at Microsoft developed a new universal printer driver to be included within the Windows operating system. This new universal printer driver included a standard set of device driver functions based on device characterization which is needed to drive the individual printers. As illustrated in
FIG. 16
, the computer system
19
implementing the universal driver still utilizes the graphics device interface (GDI)
14
as a means of coordinating the output from the various application programs. The GDI
14
function invokes the device driver functions of a minidriver
17
1
,
17
2
, . . .
17
n
which correspond to and contain the characterization of individual printer devices
10
1
,
10
2
, . . .
10
n
.
The difference in this system from that illustrated in
FIG. 15
is that the operating system includes the unidriver
15
which includes a standard set of device driver functions required to drive a printing device. In this way, the individual printer manufactures need not provide this coding. In order to actually drive any particular printer device, the unidriver
15
must receive individual printer characterization information from a selected minidriver
17
1
. The universal driver
15
then stores this device characterization data, preferably within a device context, to be used by the device driver functions of the universal driver
15
. Other device driver functions of the minidriver
17
1
forward their invocation to the universal driver
15
by invoking an analogous function of the universal driver
15
. In this way, the printer hardware manufacturer needs only supply a relatively small minidriver which contains characterization data for their particular device and which will be used by the unidriver
15
to actually drive the printer. This unidriver/minidriver system is described in U.S. Pat. No. 5,604,843 to Shaw et al. for METHOD AND SYSTEM FOR INTERFACING WITH A COMPUTER OUTPUT DEVICE, the disclosure and teachings of which are incorporated herein by reference.
While this system provides significant advantages over the prior operating system requirement of large monolithic printer drivers, the inability of this universal driver
15
to support continued advances from printer manufacturers, and the difficulty of coding and debugging the required minidriver format has become apparent. Specifically, the architecture of this prior universal printer driver could be likened to a database into which individual printer characterization data from the minidriver must be directly mapped. As such, new features supplied by the printer manufacturers could not be supported by the universal driver because there was nowhere within the universal driver for this new function to be mapped. A new feature could only be implemented if its support were included in a new release of a new version of the universal driver. However, new version releases often lagged quite significantly behind the introduction of new printers having advanced features. As a result of this inability to map new features into the existing universal driver, many original equipment manufacturers (OEMs) reverted to writing their own monolithic printer drivers to allow full support functionality of their new printing devices.
Additionally, the structure of the universal driver required that the minidrivers be of a specific binary format. Since development and coding of these binary minidrivers was difficult at best, Microsoft introduced a graphical user interface (GUI) tool called unitool to aid the software engineer in writing these minidrivers. This unitool driven generic printer characterization (GPC) was intended to provide an application independent way of describing the total functionality and capabilities of one or more printers supplied by a printer OEM. Once this GPC file had been written using the unitool GUI, it was then compiled and linked into a resource DLL. This compiled and linked resource DLL was then installed for use by the universal driver. Unfortunately, if a bug were discovered in the GPC file, the entire process would need to be repeated. This process included accessing the unitool GUI, modifying the binary GPC characterization file, recompiling and relinking this GPC file into the resource DLL, and then reinstalling this compiled and linked resource DLL for use by the unidriver. This significantly impacted the time required for debugging and development of the individual minidrivers.
Because of its rigid architecture, the universal driver provided very limited support for any customization, and that which was provided was only in the areas of command callback, raster dump, filter graphics, and font related callbacks. Additionally, the universal printer driver architecture was neither modular nor extensible further limiting its ability to allow for customized support of new features. This resulted in a master-slave relationship between the universal driver and the min
Nguyen Amanda
Pandey Ganesh
Scholten Alvin
Shimizu Eigo
Wong Peter
Garcia Gabriel
Leydig , Voit & Mayer, Ltd.
Microsoft Corporation
Tran Douglas
LandOfFree
Modular and extensible printer device driver and text based... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Modular and extensible printer device driver and text based..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Modular and extensible printer device driver and text based... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3281602