JP4310172B2 - Information processing apparatus, method, system, control program - Google Patents

Description

  The present invention relates to an information processing apparatus, method, control program, and the like that can be equipped with a device driver.

  There has been an operating system that manages a memory area that can be read and written by an application and a device driver as an open area, and manages a memory area that can be read and written by a device driver but cannot be directly read and written by an application as an extended area.

For example, setting information of a printer driver that is an example of a device driver in a Windows (registered trademark) system that is an example of an operating system is stored in a DEVMODE structure. Here, the DEVMODE structure is composed of two (a public area which is an example of a public area and a private area which is an example of a specific area). (See Patent Document 1. Windows (registered trademark) is a trademark of Microsoft Corporation. Hereinafter, when simply referred to as Windows (registered trademark), it represents a trade name of Microsoft Corporation.)
Here, general items of print settings such as paper size, print quality, orientation, etc. are held in the public area, and the structure is made public in the Windows (registered trademark) system. It is possible to refer to the current settings directly and update directly from the application at the same time.

  On the other hand, unlike the public area, the PRIVATE area holds information specific to the printer driver specification. At the same time, in the Windows (registered trademark) system, the printer driver is defined as having different internal structures. ing. The application is structured such that the internal structure of the PRIVATE area cannot be known.

  On the other hand, in recent years, there has been an increasing demand for directly handling device driver-specific information in applications.

However, as described above, in the conventional system, when the application updates or reads the contents of the PRIVATE area, that is, when the setting specific to the printer driver is updated or read, the printer driver is prompted to open the driver setting screen and the printer driver is The only way to start is to issue a command to return the DEVMODE of the set value input in response to the input to the printer driver directly to the user's device driver.
JP2003-162388

  In the above example, the extended area for storing the setting information unique to the device driver is defined, but on the other hand, there is a problem that it is difficult for the application and the device driver to exchange information via the specific area. there were.

  Further, when the application updates the setting specific to the printer driver, that is, the setting stored in the PRIVATE area, the only way to display the setting screen of the printer driver is. However, this causes the user to perform complicated operations. Therefore, there is a problem that the setting items unique to the printer driver are ideally displayed on the application setting screen as a menu.

  Furthermore, the setting information specific to the device driver needs to be exchanged via the specific area from the extension module having the function of extending the core driver, but this has not been realized.

  The present invention has been made to solve at least one of the problems described above. One aspect of the present invention is to increase the affinity between an application and a device driver.

  Yet another aspect of the present invention is that it enables an application and a device driver to exchange information via a unique area for storing information unique to the device driver.

  In an embodiment, in an information processing apparatus equipped with a device driver having an extension module and a core module, the device driver can read and write from the extension module with a memory area that can be read and written by an application and a device driver as a public area. A device driver capable of cooperating with an operating system that manages a memory area that is directly readable and writable from an application as an extended area, and the device driver obtains management information of the extended area using an interface of the operating system Using the management information acquired by the acquisition unit, a recognition unit for recognizing setting information unique to the device driver stored in the extension area, and a device driver recognized by the recognition unit Configuration information Yes, the information processing apparatus characterized by comprising: a notification control means for controlling the process of notifying the application, the method and the system control program is disclosed.

  According to one aspect of the present invention, the affinity between an application and a device driver can be increased.

  According to still another aspect of the present invention, an application and a device driver can exchange information via a specific area for storing information specific to the device driver.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In the embodiment, a unique printer driver instruction (hereinafter referred to as extended DDI) is newly defined separately from a printer driver instruction (Device Driver Interface, hereinafter referred to as DDI for short) defined in the Windows (registered trademark) system. In addition, by directly using the extended DDI prepared in the printer driver, the application can prepare a setting item specific to the printer driver as a menu on the application setting screen without displaying the printer driver setting screen. Use. On the other hand, there are the following two forms of provision of printer drivers developed by printer driver development vendors.

  One is a form in which a printer driver development vendor develops and provides all printer driver modules (hereinafter referred to as a monolithic printer driver). The other is that the printer driver development vendor provides only the UI plug-in module and the rendering plug-in module, and the other modules use modules provided in the Windows (registered trademark) system (hereinafter referred to as universal printer driver). Called). In particular, in the form of the universal printer driver, in the DDI defined in the Windows (registered trademark) system, the address of the PRIVATE area of the UI plug-in module which is an example of the unique area is provided by the Windows (registered trademark) system. When a unique extended DDI that is not defined in the Windows (registered trademark) system, which is a means of the embodiment, is used, a method for knowing the PRIVATE area of the UI plug-in module is not provided, so the UI plug-in module sets the PRIVATE area. It cannot be updated.

  However, in this embodiment, while solving the above-described problem, the application can be directly applied to any of the two printer driver forms without newly defining an extended DDI and displaying the printer driver setting screen by the application. Provided is a method capable of updating setting items unique to a printer driver.

  The configuration of the host computer is shown below. FIG. 1 is a configuration diagram showing an outline of a host computer. The host computer 1-1 includes a central processing unit 1-6, a hard disk 1-2, an interface 1-3, a storage medium device 1-4, a volatile storage area 1-5, a display device 1-7, and an input device 1-8. Consists of. The hard disk 1-2 is an area for storing an operating system, various application programs for creating or editing documents and images. A printer driver is installed in the hard disk 1-2. The interface 1-3 is an interface for transmitting a print command output from the host computer 1-1 to the printing apparatus. Specifically, a parallel interface, a USB interface, infrared communication, a network interface, or the like. The storage medium reading device 1-4 is a device that reads contents stored in a storage medium such as a CD-ROM or a floppy (registered trademark) disk. Specifically, it is a CD-ROM drive, a floppy (registered trademark) disk drive, or the like. The volatile storage area 1-5 is an area where information can be temporarily stored. Various operating programs stored in the hard disk 1-2 and various application programs for creating or editing documents and images are processed by central processing. It is used as an area for temporarily holding information when executed by the apparatus 1-6. Also for the printer driver, the volatile storage area 1-5 is used as an area for temporarily storing information when executed by the central processing unit 1-6. The central processing unit 1-6 controls the entire host computer 1-1 according to a software program. The display device 1-7 represents a CRT or a liquid crystal display, that is, a display, and can display a screen of application software or a current state of a printer driver setting screen. An input device 1-8 represents a mouse, a keyboard, and the like, and is used for various inputs on an installation program screen displayed on the display device 1-7, a printer driver setting screen, and the like.

  The configuration of the printer driver is shown below. FIG. 2 is a block diagram showing a printer driver as a component of the printing apparatus after the printer driver is installed on the host computer 2-1. The host computer 2-1 and the printing apparatus 2-5 are connected by an interface 2-10. Specifically, a Centronics interface, USB interface, infrared communication, network interface, or the like. A print command 2-2 is an example of an application programming interface of the operating system as a GDI command 2-2 as an application programming interface of the operating system from an application 2-6 that can mainly create or edit a document or an image. When issued, the GDI 2-7 issues a device driver interface (hereinafter DDI) command published by the printer driver 2-8 via the spooler 2-4. Upon receiving the DDI command, the printer driver 2-8 converts the DDI command into a print command command and passes it to the bidirectional communication control unit 2-9 via the pusher 2-4. The bidirectional communication control unit 2-9 uses the interface 2-10 to transmit a printing command that can be identified by the printing apparatus to the printing apparatus 2-11. The bidirectional communication control unit 2-11 of the printing apparatus 2-5 that has received the print command passes the print command to the print control unit 2-12, and the print control unit 2-12 executes print processing on the designated paper.

  A configuration example of the monolithic printer driver is as follows. FIG. 3 is a configuration diagram showing an embodiment of a “monolithic printer driver” in which a printer driver development vendor develops and provides all printer driver modules. This monolithic printer driver is stored in the hard disk of FIG. 1, and is read and executed by the central processing unit. FIG. 4 is a block diagram showing a DEVMODE structure in the monolithic driver. In FIG. 4, first, the DEVMODE structure refers to information specific to printer driver specifications, such as the type of ink cartridge, from general items such as print settings used by the printer driver, such as paper size, number of copies, and print quality. This is a structure that holds all print setting values including all of the above. The DEVMODE structure is held in the volatile storage area 1-5 of FIG. 1 in the application software 3-4. As a configuration, the public area 4-1 and the PRIVATE area 4-6 are composed of the volatile storage area 1-5. 5 are arranged continuously.

  Here, the public area 4-1 mainly holds the size 4-3 of the public area, the paper size 4-3, the number of copies 4-4, the print quality 4-5, etc. which are general items in the print settings. Has been. The internal configuration of the public area 4-1 is defined as a unified configuration regardless of the type of printer driver, and since it is also disclosed to the application software, the application software directly accesses each item. It is possible.

  On the other hand, the PRIVATE area 4-6 is defined as an area for holding unique information for each printer driver. At the same time, since the configuration of the PRIVATE area 4-6 is allowed to have a unique configuration for each printer driver, the application software cannot know the configuration and therefore cannot directly access each item. . That is, only the printer driver that knows the internal configuration can access each item in the PRIVATE area. In the present embodiment, for example, an ink cartridge type 4-7, which is an example of setting information unique to the printer driver, is held in a PRIVATE area 4-6, which is an example of an expansion area.

  Here, in order for the printer driver to access the PRIVATE area 4-6, it is necessary to know the start address 4-9 of the PRIVATE area, but the start address 4-9 of the PRIVATE area is the public area specified by the application. By referring to the size 4-2 of the public area from the start address 4-8 and adding the size 4-9 of the public area to the address of the start address 4-8 of the public area, the start address 4-10 of the PRIVATE area Can be obtained.

  Returning to the description of FIG. In FIG. 3, the monolithic printer driver 3-9 mainly includes a monolithic driver UI 3-6 and a monolithic driver rendering 3-7. Specifically, the monolithic driver UI 3-6 and the monolithic driver rendering 3-7 are configured in the form of a dynamic link library (DLL), and the two DLLs are all developed and provided by the printer driver vendor. Generally, the procedure for executing printing by the application 3-4 is divided into two steps: a procedure for performing print settings and a procedure for starting printing. First, a procedure for performing print settings will be described. The application 3-4 needs to acquire all setting values such as paper size, orientation, and print quality, which are print setting items, as a DEVMODE structure and store them in the volatile storage area 1-5.

  Therefore, the application 3-4 knows the internal configuration of the paper size 4-3, the number of copies 4-4, the print quality 4-5, etc. existing on the public area 4-1 in FIG. It is possible to change the value on the DEVMODE structure on the source code.

  On the other hand, the application 3-4 does not know the configuration of the PRIVATE area 4-1 in the type 4-7 of the ink cartridge existing on the PRIVATE area 4-1 in FIG. I can't do it. Therefore, in order for the application 3-4 to change the value in the PRIVATE area 4-1, in the DDI command group 3-5 disclosed by the monolithic driver UI 3-6, generally, “setting” is set for the printer driver. A method of displaying a setting screen on the monolithic driver UI itself and acquiring the setting result as a DEVMODE structure by performing an instruction “display a screen, update setting by the user, and return the result as a DEVMODE structure” I take the.

  Next, a procedure for the application 3-4 to start printing will be described. The DEVMODE structure acquired in the volatile storage area 1-5 by the above-described print setting procedure is passed as a parameter of a print start command published by the GDI 3-2. At the same time, a drawing command to be printed is also passed. The GDI 3-2 passes the DEVMODE structure acquired from the application 3-4 to the monolithic driver rendering 3-7 together with the passed drawing command. Then, the monolithic driver rendering 3-7 converts the contents of the passed drawing command into a print command that can be understood by the print control unit 2-12 of the printing apparatus 2-5 according to the print setting of the DEVMODE structure passed separately. Then, the print command is transmitted to the print spooler 3-3.

  An extended DDI embodiment of a monolithic printer driver is as follows. The above description describes the printing of a defined general application. Therefore, in the procedure in which the application 3-4 performs print settings, a print setting screen that can be displayed by the application 3-4 itself is, for example, 9-1 in FIG.

  9A is an example of the print setting screen of the application. Since the application can access only the public area 4-1 in the DEVMODE structure, the paper size 4-3 and the number of copies 4 existing in the public area 4-1 are shown. -4 and print quality 4-5 can be displayed as a paper size 9-2, number of copies 9-3, and print quality 9-4 as menus, respectively. Therefore, the type 4-7 of the ink cartridge held in the PRIVATE area 4-6 cannot be displayed. In order for the user to change the ink cartridge type 4-7, the printer driver setting screen must be newly displayed using the DDI group 3-5.

  In the above example, an example of an ink cartridge has been described. However, ON / OFF of a cartridge and a cartridge detection button, settings relating to color adjustment, ON / OFF of a print preview, and ON of a print advisor which is a driver help display application that starts up at the time of printing , OFF, output paper size, type of printing, borderless protrusion, whether to use automatic duplex unit, whether to use reverse order printing, whether to perform stamp printing, and background printing Setting, setting whether to perform image processing for illustration touch, setting whether to apply a single color effect, setting whether to apply VIVID photo mode which is a mode for vividly printing a photo, image data correction Settings related to digital camera noise, etc. are the same as cartridge types 4-7. To be managed in the extension area as a printer driver specific information. These setting information can be read out and displayed on the user interface on the application side, and direct setting and display from the application can be performed.

  However, this causes the user to perform complicated operations. Therefore, ideally, the setting items unique to the printer driver on the application setting screen, such as the example shown in 9-10 of FIG. In this case, the ink cartridge type 9-11 is added, but it is desirable and ideal that the setting items unique to the printer driver are also displayed as a menu on the print setting screen 9-10 of the application.

  Therefore, in the present embodiment, as shown in FIG. 9, means for updating information in the PRIVATE area, which is an installation item unique to the printer driver, on the application setting screen 9-10 is a DDI defined as a general driver instruction. A method called an original printer driver instruction (hereinafter referred to as extended DDI) is provided separately from the instruction.

  In FIG. 3, the monolithic driver UI 3-6 supports the extended DDI 3-9 separately from the standard DDI instruction group 3-5 defined by DDK. Specifically, an extended DDI 3-9 is prepared as a function that the monolithic driver UI 3-6 configured as a dynamic link library exports to the outside. Here, the application 3-4 displays the menu of the ink cartridge type 9-11, which is a setting unique to the printer driver, as indicated by 9-10 in FIG. Take direct access configuration.

  A flow in which the application uses the extended DDI will be described below. FIG. 11 is a flowchart of a sequence in which the application shown in FIG. 3 processes an extended DDI command for initializing the print setting screen of the application shown in 9-11 of FIG. The contents of these flowcharts are recorded as an application on a storage medium such as the hard disk in FIG. 1, read from the hard disk, temporarily stored in the volatile storage area 1-5 in FIG. Executed at -6. Starting from step 11-1, if it is determined in step 11-2 that the printer driver supports the extended DDI command, that is, it is possible to change the setting of the ink cartridge by the extended DDI command In step 11-3, the ink cartridge type menu is made visible. Thereafter, the process proceeds to Step 11-4. On the other hand, if it is determined in step 11-2 that the setting of the ink cartridge cannot be changed by the extended DDI command, the process proceeds to step 11-4. In this case, the ink cartridge type menu is not visible. In step 11-4, the application displays a paper size menu which is a public area of the DEVMODE structure, and proceeds to step 11-5. In step 11-5, a public area copy menu is displayed, and the flow advances to step 11-6. In step 11-6, the print quality menu of the public area is displayed, and the process proceeds to step 11-7 and ends.

  In step 11-4, step 11-5, and step 11-6 in this flow, since the application knows the structure of the public area of the DEVMODE structure, the extended DDI instruction is not used.

  Steps 11-10 to 11-15 are a flowchart of a detailed sequence for using the extended DDI command to display the ink cartridge type menu in step 11-3. Starting from step 11-10, in step 11-11, the application lists the types of ink cartridges that can be selected by the printer driver in the extended DDI, and proceeds to step 11-12. In step 11-12, the list in the combo box which is a menu is updated with the contents of the enumerated ink cartridge, and the process proceeds to step 11-13. In step 11-13, in order to determine which item of the combo box is to be selected next, the current value of the ink cartridge is acquired by the extended DDI, and the process proceeds to step 11-14. In step 11-14, the item in the combo box that matches the current value acquired in step 11-13 is displayed, and the process ends in 11-15. By this flow procedure, the application can initialize the item menu using the extended DDI.

  FIG. 12 is a flowchart showing a sequence when the application shown in FIG. 3 changes the ink cartridge type in the ink cartridge type 9-11 menu and starts printing on the print setting screen of the application shown in FIG. . Starting from step 12-10, if the user changes the combo box of the ink cartridge in step 12-11, in step 12-12, the application sets the ID indicating the ink cartridge type changed by the user to the extended DDI. Specify with. In step 12-13, a DEVMODE structure in which the PRIVATE area is updated to the new ink cartridge type specified in step 12-12 is acquired as output information of the extended DDI. Next, in step 12-14, the application starts print processing using the acquired DEVMODE structure as a parameter of the print start command. As a result, the application can use the extended DDI to update the type of the ink cartridge held in the PRIVATE area where the application itself does not know the structure using the menu of the application itself. It is possible to start printing by updating the type of the ink cartridge without displaying the setting screen.

  The extended DDI input and output information is described below. FIG. 10 is a diagram showing the format of input information from the application side of the extended DDI instruction and output information to the application side when the application uses the extended DDI shown in FIGS. 11 and 12, respectively.

  Reference numerals 10-1 to 10-5 denote an input from the application side and an application when the application enumerates values of specific items, that is, when the types of ink cartridges currently selectable at step 11-11 in FIG. Output information to Specifically, the application inputs the item ID 10-1 and the current DEVMODE structure 10-2 to the extended DDI, and the enumeration number 10-3 as a result of enumeration returned by the extended DDI and the value ID of the enumerated ink cartridge Are acquired from 10-4 to 10-5. As a result, it is possible to enumerate values in the extended DDI.

  10-10 to 10-12 are input from the application side when the application acquires the current value of a specific item, that is, when the current ink cartridge type is acquired in step 11-13 in FIG. Output information to the application. Specifically, the application inputs the item ID 10-10 and the current DEVMODE structure 10-11 to the extended DDI, and acquires the value ID 10-12 as the current value returned by the extended DDI. As a result, the current value can be acquired by the extended DDI.

  10-20 to 10-23 are input from the application side when the application updates to a new value for a specific item, that is, when the value is updated to a new ink cartridge type in step 11-14 in FIG. And output information to the application. Specifically, the application inputs the item ID 10-20, the change destination value ID 10-21, and the current DEVMODE structure 10-22 to the extended DDI, and the DEVMODE structure in which the PRIVATE area returned by the extended DDI is updated. Get 10-23. As a result, the value of a specific item can be updated in the extended DDI, and the updated DEVMODE can be acquired.

  The extended DDI processing flow on the monolithic printer driver side is shown below. FIG. 13 is a flowchart showing processing in the extended DDI when the monolithic driver UI 3-6 shown in FIG. 3 receives a change in the ink cartridge value from the application 3-4 in response to the extended DDI command. That is, this is a processing flow inside the extended DDI instruction on the printer driver side when the application issues an extended DDI instruction that changes the value of the ink cartridge in step 11-14 in FIG. In this case, as described above, the input information 10-20 to 10-22 in FIG. 10 is input from the application to the extended DDI. The configuration of the DEVMODE structure of the input information 10-22 at this time can be confirmed in FIG.

  Starting from step 13-1, in step 13-2, the size of the public area is referred to from the start address of the public area of the DEVMODE structure designated by the application, and the process proceeds to step 13-3. In Step 13-3, the size of the public area acquired in Step 13-2 is added to the start address of the public area to calculate the start address of the PRIVATE area. As a result, the head address of the PRIVATE area of the DEVMODE structure passed as input information can be acquired in the extended DDI. Next, the process proceeds to step 13-4, and an area in which the value of the ink cartridge held in the PRIVATE area is held is referred to. Next, in step 13-5, the value of the ink cartridge in the PRIVATE area is updated with the ID of the new ink cartridge passed as input information from the application. In step 13-6, the entire DEVMODE structure updated with the new ink cartridge ID is returned to the application as output information of the extended DDI. According to this flow, when the application wants to change the ID of a specific item to a new ID by the extended DDI, the printer driver correctly updates the information held in the PRIVATE area and returns all the updated DEVMODE structures to the application. It becomes possible.

  A description will be given centering on differences from the above-described embodiment. A configuration example of the universal printer driver is shown below. FIG. 5 is a configuration diagram showing a form of “universal printer driver” in which a printer driver development vendor develops and provides some printer driver modules. In FIG. 5, the universal printer driver 5-1 stored in the hard disk of FIG. 1 and read and executed by the central processing unit is a unidriver UI5-6, a UI plug-in 5-7, a unidriver rendering 5-8, And a rendering plug-in 5-9. Here, the modules that can be developed by the printer vendor are only the UI plug-in 5-7 and the rendering plug-in 5-9 shown in the figure. Specifically, the UI plug-in 5-7 and the rendering plug-in 5-9 are dynamic link libraries. (DLL) form. Other unidriver UIs 5-6 and unidriver rendering 5-8 need to be used without modifying modules prepared in the Windows (registered trademark) OS.

  FIG. 7 is a block diagram showing a DEVMODE structure in the universal printer driver. In FIG. 7, it can be seen that the DEVMODE structure of the universal printer driver is different from the DEVMODE structure of the monolithic printer driver shown in FIG. Specifically, the public area 7-1 is the same as the public area 4-1 of the monolithic printer driver, but the PRIVATE area is composed of the PRIVATE area 7-6 of the unidriver UI and the PRIVATE area 7-7 of the UI plug-in. This is particularly different. Information specific to the printer driver, such as the ink cartridge type 7-8, is held in the PRIVATE area 7-7 of the UI plug-in. These areas 7-1, 7-6, and 7-7 are preferably areas in which the hard disk or the volatile area 1-5 that can be referred to by the central processing unit of FIG.

  Also, in the Windows (registered trademark) DDK, the contents of the PRIVATE area of the unidriver UI indicated by 7-7 in FIG. 7 are not disclosed. In other words, the UI plug-in cannot know the internal configuration of the private area 7-7 of the unidriver UI, and can understand only the internal configuration of the PRIVATE area 7-7 of the UI plug-in.

  Returning to the explanation of FIG. First, a procedure for the application 5-4 to perform print setting will be described. The application 5-4 needs to acquire all setting values such as paper size, orientation, and print quality, which are print setting items, as a DEVMODE structure and store them in the volatile storage area 1-5.

  Therefore, the application 5-4 knows the internal configuration of the paper size 7-3, the number of copies 7-4, the print quality 7-5, etc. existing on the public area 7-1 in FIG. It is possible to change the value on the DEVMODE structure on the source code.

  On the other hand, the application 5-7 does not know the configuration of the PRIVATE area 7-7 of the UI plug-in in the type 7-8 of the ink cartridge existing on the PRIVATEE area 7-7 of the UI plug-in in FIG. 5-4 cannot change the value directly. Therefore, in order for the application 5-4 to change the value in the PRIVATE area 7-7 of the UI plug-in, in general, the printer driver in the DDI command group 5-5 disclosed by the unidriver UI 5-6 is used. On the other hand, an instruction “display setting screen, let user update setting, and return result as DEVMODE structure” is issued. Then, the unidriver UI 5-6 calls the same instruction as the DDI instruction published by the UI plug-in 5-7.

  At this time, the head address 7-10 of the plug-in PRIVATE area is passed as a parameter from the unidriver UI 5-6 to the UI plug-in simultaneously with the head address 7-9 of the public area.

  The called UI plug-in 5-7 displays a setting screen unique to the UI plug-in, displays an ink cartridge type menu on the setting screen, and displays the setting result on the PRIVATE area 7-7 of the UI plug-in. The entire DEVMODE described in the ink cartridge type 7-8 is returned to the unidriver UI 5-6.

  Next, the unidriver UI 5-6 that has returned the entire DEVMODE returns the DEVMODE to the application 5-4. As a result, the application 5-4 takes a method of acquiring a DEVMODE structure in which setting items unique to the printer are updated.

  Next, a procedure for the application 5-4 to start printing will be described. The DEVMODE structure acquired in the volatile storage area 1-5 by the above-described print setting procedure is passed as a parameter of a print start command published by the GDI5-2. At the same time, a drawing command to be printed is also passed. The GDI 5-2 passes the DEVMODE structure acquired from the application 5-4 to the unidriver rendering 5-8 together with the passed drawing command. The unidriver rendering 5-8 having passed the DEVMODE structure together with the drawing command passes the information to the rendering plug-in 5-9. Then, the rendering plug-in 5-9 converts the contents of the passed drawing command into a print command that can be understood by the print control unit 2-12 of the printing apparatus 2-5 according to the print setting of the DEVMODE structure passed separately. The print command is transmitted to the print spooler 5-3 via the unidriver rendering 5-8.

  An example in the extended DDI of the universal printer driver is shown below. FIG. 6 is a configuration diagram showing the configuration of the extended DDI in the universal printer driver form. In FIG. 6, only the UI plug-in 6-7 and the rendering plug-in 6-9 can be developed by the printer development vendor. Therefore, the standard DDI instruction group defined by DDK in the UI plug-in 6-7 is as follows. Separately, extended DDI6-10 is supported. Specifically, an extended DDI 6-10 is prepared as a function that the UI plug-in 6-7 configured as a dynamic link library exports to the outside. Here, as shown in 9-10 of FIG. 9, the application 6-4 displays a menu of the ink cartridge type 9-11 which is a setting unique to the printer driver. Take direct access configuration. The display screen in FIG. 9 is displayed on the display device 1-7 in FIG.

  The problems of the extended DDI of the universal printer driver are shown below. There is a problem when the extended DDI is supported by the universal printer driver in the configuration of FIG. As shown in FIG. 6, the application 6-4 directly calls the instruction of the extended DDI 6-10, and in this case, from the DEVMODE structure of the universal printer driver shown in FIG. Is specified, but the start address 7-10 of the plug-in PRIVATE area is not specified. This is because the application 6-4 and the UI plug-in 6-7 directly exchange information without going through the unidriver UI 6-6, which only knows the size of the private area 7-6 of the unidriver UI in FIG. Is to do.

  Therefore, the UI plug-in 6-7 that receives the extended DDI command directly from the application cannot know the start address of the PRIVATE area of the UI plug-in that holds information specific to the printer driver such as an ink cartridge in the DEVMODE structure. Therefore, the position of the ink cartridge type 7-8 cannot be confirmed, and the extended DDI process cannot be performed.

  In order to solve the above-described problem, in this embodiment, as shown in FIG. 8, in the DEVMODE structure of the universal printer driver, the size 8-7 of the unidriver PRIVATE area is set at the head of the PRIVATE area of the unidriver UI. Deploy and publish the structure to UI plug-in 6-9.

  The specific configuration of the size 8-7 of the unidriver PRIVATE region is as follows. For example, as described in 8-20, a UNIPRIVATEHEADER structure is newly provided, and a UNIPRIVATEHEADER structure including a UNIPRIVATEHEADER structure therein A dwSize field indicating the entire size is provided. The UNIPRIVATEHEADER structure may be necessarily placed at the head of the PRIVATE area of the unidriver UI, and at the same time, the structure of the UNIPRIVATEHEADER structure may be disclosed to the UI plug-in 6-9 as DDK.

  As a result, also in the embodiment of the extended DDI shown in FIG. 6, the UI plug-in 6-7 can correctly refer to the position of the ink cartridge 8-9 existing on the PRIVATE area 8-8 of the UI plug-in. Use means.

  The extended DDI processing flow on the universal printer driver side in this embodiment is shown below. FIG. 14 is a flowchart showing the internal processing of the extended DDI when the UI plug-in 6-7 shown in FIG. 6 receives a change in the ink cartridge value from the application 6-4 in response to the extended DDI command. That is, this is a processing flow inside the extended DDI instruction on the printer driver side when the application issues an extended DDI instruction that changes the value of the ink cartridge in step 11-14 in FIG. In this case, as described above, the input information 10-20 to 10-22 in FIG. 10 is input from the application to the extended DDI. The configuration of the DEVMODE structure of the input information 10-22 at this time can be confirmed in FIG.

  The flow of FIG. 14 will be described in light of the configuration of the DEVMODE structure of FIG. Starting from step 14-1, in step 14-2, the size of the public area is referred to from the start address of the public area of the DEVMODE structure designated by the application, and the process proceeds to step 14-3. In step 14-3, the size of the public area acquired in step 14-2 is added to the start address of the public area to calculate the start address of the unidriver PRIVATE area. As a result, first, the leading address 8-12 of the PRIVATE area of the unidriver UI can be acquired. Next, in step 14-4, the size 8-7 of the unidriver PRIVATE area held at the head of the PRIGATE area of the unidriver UI is referred to, and the process proceeds to step 14-5. In step 14-5, the size 8-13 of the unidriver PRIVATE area acquired in step 14-4 is added to the start address 8-12 of the unidriver PRIVATE area to obtain the start address 8-14 of the UI plug-in PRIVATE area. it can. As a result, the start address of the PRIVATE area of the UI plug-in can be acquired inside the extended DDI, and the PRIVATE area of the UI plug-in can be referred to. Next, the process proceeds to step 14-6, and an area in which the ink cartridge type 8-9 held in the PRIVATE area 8-8 of the UI plug-in is held is referred to. Next, in step 14-7, the ink cartridge type 8-9 in the PRIVATE area of the UI plug-in is updated with the ID of the new ink cartridge passed as input information from the application. In step 14-8, the entire DEVMODE structure updated with the new ink cartridge ID is returned to the application as output information of the extended DDI.

  According to this flow, even if the application wants to change the ID of a specific item to a new ID even by the configuration of the extended DDI of the universal printer driver, the information stored in the PRIVATE area is correctly updated, and all the updated DEVMODE structures are updated. It can be returned to the application.

  In the host computer 1-1 having a rendering plug-in or UI plug-in module which is an example of an extension module and a printer driver which is an example of a device driver having a unidriver rendering or unidriver UI module which is an example of a core module, The printer driver uses a memory area that can be read and written by the application and the device driver as a public area (public area), and a memory area that can be read and written by the extension module but cannot be directly read and written by the application. This is a printer driver capable of cooperating with an operating system (GDI) managed as an area.

  The UI plug-in module acquires management information of the private area of the UI plug-in using GDI, which is an interface of the operating system.

  The UI plug-in module stored in the hard disk of FIG. 1 and read out by the central processing unit uses the size of the public area and the size of the private area of the unidriver UI as an example of the acquired management information. The information information indicating the cartridge type, which is an example of the setting information unique to the device driver, stored in the private area 8-8 of IN (a part of the hard disk or the nonvolatile area in FIG. 1) is recognized. Then, the UI plug-in calls an API of the operating system to notify the application of information indicating the ink cartridge.

  Further, GDI, which is an example of an interface of the operating system, indicates that it is an extended interface for exchanging setting information unique to the device driver between the device driver and the application.

  Further, the UI plug-in calculates the start address of the private area of the UI plug-in, which is an example of the extension area, using the size of the public area and the size of the private area of the unidriver. Then, referring to the structure managed by the UI plug-in, the offset of the head address is recognized, and information indicating the ink cartridge type, which is an example of setting information unique to the device driver, is read. Further, the UI plug-in calls an API of the operating system so as to notify the application of the setting information so as to be displayed on a display screen controlled by the function of the application.

  In addition, the application notifies the device driver of information indicating the type of cartridge using the operating system interface, and the device driver uses the management information acquired by the acquisition unit to store the private information of the UI plug-in module. The API of the OS is called to write information indicating the type of the ink cartridge, which is an example of setting information unique to the device driver notified from the application to the area.

  Furthermore, the UI plug-in module may include the size of the unidriver private area.

  In summary, the printing system is composed of application software, a printer driver, and a printing apparatus, and the standard DDI defined in advance in the Windows (registered trademark) system among the printer drivers that are components of the printing apparatus. Apart from this, it is a printer driver with a feature that implements the extended DDI that is defined uniquely, and it is possible to operate the setting items specific to the printer driver that the printer driver has in the PRIVATE area by the procedure defined as extended DDI. It is preferable that the printer driver has a feature that can be returned to the application.

  In addition, the printer driver is a setting item unique to the printer driver that is stored in the PRIVATE area by the procedure defined as extended DDI, and has a feature that a list of currently selectable setting values can be returned to the application. Is preferable.

  Further, the printer driver is a setting item unique to the printer driver that is stored in the PRIVATE area by the procedure defined as the extended DDI, and has a feature that can return the current setting value of the setting item to the application. It is preferable to be a driver.

  Further, by the procedure defined as the extended DDI, the printer driver has a setting item unique to the printer driver that is stored in the PRIVATE area. The current value of the setting item is updated to a new value designated by the application, and the updated DEVMODE structure It is preferable that the printer driver has a feature capable of returning the body to the application.

  Further, the printer driver is capable of realizing the extended DDI technique with the configuration of the monolithic printer driver, and the extended DDI technique represents the size of the PRIVATE area of the unidriver UI in the PRIVATE area of the unidriver UI. By providing the field, it is preferable that the printer driver can be realized by the configuration of the universal printer driver.

  In addition, in the application software, by using the extended DDI installed in the printer driver according to a predetermined procedure, the application software has a setting item unique to the printer driver on the screen of the application software. In addition, by updating the setting items specific to the printer driver on the application software screen, it is possible to perform printing by updating the setting items specific to the printer driver without having to display the setting screen of the printer driver. It is preferable that the printing system has

(Other embodiments)
The processing shown in FIGS. 11 to 14 in the present embodiment is performed by a program installed from the outside by a program such as each printer driver stored in the hard disk of FIG. Is executed by the central processing unit 1-6 (CPU). In this case, the present invention is applied even when an information group including a program is supplied to a host computer from a storage medium such as a CD-ROM, a flash memory, or an FD, or from an external storage medium via a network. Is.

  As described above, the system or apparatus can be obtained by supplying the storage medium storing the program code of the software that implements the functions of the above-described embodiments to the system or apparatus, or downloading the storage medium from an external server (not shown). It goes without saying that the object of the present invention can also be achieved by the computer (or CPU or MPU) reading and executing the program code stored in the storage medium.

  In this case, the program code itself read from the storage medium realizes the novel function of the present invention, and the storage medium storing the program code constitutes the present invention. As a storage medium for supplying the program code, for example, a floppy disk, hard disk, optical disk, magneto-optical disk, DVD, CD-ROM, magnetic tape, nonvolatile memory card, ROM, EEPROM, or the like can be used.

  Further, by executing the program code read by the computer, not only the functions of the above-described embodiments are realized, but also an OS (operating system) or the like running on the computer based on the instruction of the program code. It goes without saying that a case where the function of the above-described embodiment is realized by performing part or all of the actual processing and the processing is included. Further, after the program code read from the storage medium is written to a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer, the function expansion is performed based on the instruction of the program code. It goes without saying that the case where the CPU or the like provided in the board or the function expansion unit performs part or all of the actual processing and the functions of the above-described embodiments are realized by the processing.

It is the schematic showing a host computer. FIG. 2 is a configuration diagram illustrating a printer driver as a component of a printing apparatus. It is a module block diagram of a monolithic printer driver. It is a block diagram showing the DEVMODE structure at the time of standard DDI and extended DDI of a monolithic printer driver. 2 is a module configuration diagram of a universal printer driver. FIG. It is a block diagram of extended DDI of a universal printer driver. It is a block diagram showing the DEVMODE structure at the time of standard DDI of a universal printer driver. It is a block diagram showing the DEVMODE structure at the time of extended DDI of a universal printer driver. It is a figure showing the example of a print setting screen of the application using standard DDI and extended DDI. It is a figure showing the input information and output information of an extended DDI command. It is an initialization process flowchart of the print screen of the application using extended DDI. 10 is a flowchart of processing in which an application using an extended DDI changes an item using the extended DDI and starts printing. It is a flowchart showing the process inside the extended DDI of the monolithic printer driver. It is a flowchart showing the process inside extended DDI of a universal printer driver.

Claims (9)

In an information processing apparatus equipped with a device driver having an expansion module and a core module,
The device driver has a memory area that can be read and written by the application and the device driver as a public area, a memory area that can be read and written from the core module but cannot be read and written by the application as a first extension area, and A device driver capable of cooperating with an operating system that manages a memory area that is readable and writable but not readable and writable by an application as a second extension area,
Based on the information indicating the memory size of the public area and the information indicating the memory size of the first extension area, the interface of the operating system is invoked and the start address of the second extension area is set. Deriving means for deriving management information including information to be shown ;
Recognizing means for recognizing device driver-specific setting information stored in the extension area, using management information including information indicating a head address derived by the deriving means ;
Controls the process for notifying the application from the device driver so that the setting information unique to the device driver recognized by the recognition means can be used in the display of a setting screen that can be set based on the setting information unique to the device driver. Notification control means for
An information processing apparatus comprising: The information processing apparatus according to claim 1, wherein the interface of the operating system is an extended interface for exchanging setting information unique to the device driver between the device driver and an application.   The public area, the first extension area, and the second extension area are arranged on a predetermined memory map in this order, and the derivation unit is configured to determine a memory size of the public area and a memory size of the first extension area. The information processing apparatus according to claim 1, wherein information indicating a head address of the second extension area is derived by summation. From an application, the notifies the device driver-specific configuration information to the device driver with an operating system interface, the device driver by using the management information which the deriving means is derived, relative to the second extension region 4. The information processing apparatus according to claim 1, further comprising a writing control unit that controls a process of writing setting information unique to the device driver notified from the application. 5. In an information processing apparatus equipped with a device driver having an extension module and a core module,
The device driver has a memory area that can be read and written by the application and the device driver as a public area, a memory area that is readable and writable from the core module but cannot be read and written by the application as a first extension area, and from the extension module. A device driver capable of cooperating with an operating system that manages a memory area that can be read and written but cannot be read and written from an application as a second extension area,
Based on the information indicating the memory size of the public area and the information indicating the memory size of the first extension area, the interface of the operating system is invoked and the start address of the second extension area is set. A derivation step for deriving management information including information to be shown;
Recognizing device driver-specific setting information stored in the extension area using information indicating a head address derived by the derivation step; and
Controls processing for notifying the application from the device driver so that the setting information unique to the device driver recognized in the recognition step can be used in the display of a setting screen that can be set based on the setting information unique to the device driver A notification control process,
An information processing method characterized by comprising: 6. The information processing method according to claim 5, wherein the interface of the operating system is an extended interface for exchanging setting information unique to the device driver between the device driver and an application.   The public area, the first extension area, and the second extension area are arranged on a predetermined memory map in this order, and the derivation step includes the memory size of the public area and the memory size of the first extension area. The information processing method according to claim 5 or 6, wherein information indicating a head address of the second extension area is derived by summation. An application notifies the device driver of setting information specific to the device driver using the operating system interface, and the device driver uses the management information derived in the deriving step to notify the second extension area. The information processing method according to claim 5, further comprising a write control step of controlling a process of writing setting information unique to the device driver notified from the application. A control program for causing a CPU of a computer to execute the method according to claim 5.

Images