JP2014041599A - Program, information processing apparatus, and system - Google Patents

Abstract

A program capable of providing an interactive service using data generated by a driver is provided.
A step of receiving a setting condition in an information processing apparatus; and a step of starting a notification program for displaying a notification screen using print data before the image processing program starts an operation (S2.2.2); , A step of acquiring document data from an application, converting the print data into print data based on the setting condition received by the setting reception program, and holding print data in a predetermined program A step (S7.2.1) of storing in the program, and a step of displaying the notification screen using the print data by acquiring the print data from the print data holding program and the image processing program 23 (S2.2.2.4) And a notification program 252 for executing the program.
[Selection] Figure 1

Description

  The present invention relates to a program for acquiring document data to be output and sending it to a printing apparatus.

In some cases, a user operates an application running on a PC (Personal Computer) to instruct printing of document data (document) or instruct FAX transmission. For this reason, a PC (Graphical User Interface) screen for accepting print settings and FAX transmission settings is displayed on the PC, and a printer driver or PC-FAX driver that converts document data into drawing data (hereinafter, without distinguishing both). Is simply installed).

  A driver that operates on Windows (registered trademark; hereinafter omitted) is usually divided into two parts, a “UI driver” and a “drawing driver”. The UI driver has a role of displaying a print setting screen (GUI) as described above, displaying print settings to the user, and accepting changes and settings. On the other hand, the drawing driver mainly receives print settings designated by the UI driver from Windows and generates drawing data for transmission to the printer.

By the way, a driver called from a PC application performs processing in cooperation with Windows. As a print architecture in Windows, there are two spool formats and an install format using a server.
(1) Two spool formats RAW spool and EMF spool (2) Installation format spool called Point & Print In printing using the RAW spool, an instance of a driver is generated “on the application process” for which the user has issued a print instruction. In printing using the EMF spool, the driver instance is generated even on the process of the application for which the user has issued a print instruction, but after that, it is generated again on the “OS spool process”. The spool process in the latter half of the EMF spool is a spool process for actually creating data to be transmitted to the printer by the driver instance (in contrast, a process in which the application and the OS communicate to generate intermediate data is called an application. Process).

  Point & Print installation is used in a state where a printer, a computer that is a server on which a driver is already installed, and a computer that is a client other than the printer are connected via a network. The client installs the driver on the client using the driver on the server. The driver installed in the client in this way can create drawing data on the server side without performing the client side (referred to as “server side rendering”. In contrast, what is performed on the client side is “client side rendering”. Rendering "). It is possible to reduce the printing processing load on the client side.

  In the Point & Print environment built by Point & Print installation, a module called Language Monitor operates on both the client side and the server side. This module is one of the necessary modules in the Windows printing architecture. If the printer manufacturer does not develop it, the module that comes with Windows will work, but the printer manufacturer can also develop it with its own functions and operate it.

  In the printing environment as described above (environment in which multiple spool formats and installation formats are available), when the user instructs printing from the application, the driver itself and the application that accompanies it use the data generated by the driver. Techniques for providing interactive services are known (see, for example, Patent Documents 1 and 2). By using the interactive service, the user can be notified of print preview display and billing information.

  Japanese Patent Application Laid-Open No. 2004-228561 discloses a technique for notifying a user of a fee or changing subsequent output processing by starting a charging application based on information notified from a driver. In Patent Document 2, the UI driver uses the job ID via the print setting storage module even after the user issues a print instruction using the unique job ID assigned to the print instruction from the application. A technique for transferring print settings to a drawing driver is disclosed.

However, the conventional printer drivers such as Patent Documents 1 and 2 have the following two problems.
A. When displaying an interactive screen as a GUI, an “interactive service detection” screen may be displayed. Since the UI driver and the drawing driver cannot directly exchange data, it becomes difficult for the UI driver to perform an interactive service using the data created by the drawing driver.

  A. Will be described. First, it is not recommended as a Windows print architecture that the drawing driver display an interactive screen. For this reason, when the drawing driver displays an interactive screen, Windows may display a “interactive service detection” screen as a warning and ask the user whether or not activation is possible.

FIG. 16 shows an example of the “interactive service detection” screen. In FIG. 16, “The program may need information or access permission to complete the task” is displayed. When this screen is displayed, the user must choose between displaying a message and notifying after a few minutes. Unless selected, the interactive screen is not displayed, and the driver cannot provide the “interactive service” to the user (cannot display a print preview notification or charge), so the job cannot be completed.

  In addition, even if one is selected, the user must determine whether or not to allow an operation having a large influence on the system, and it is difficult for the user who is not familiar with the operation of the PC. It is. Further, since it is necessary to perform an extra operation other than the operation for printing, the user's operation procedure increases, which is inconvenient.

  The “interactive service detection” screen may also be displayed when the UI driver displays the interactive screen. For example, when the authority of the user logged in to the PC is low, there is no problem when the UI driver displays the interactive screen on the process of the application started with the user authority. However, when the UI driver displays an interactive screen on the Windows spool process, an “interactive service detection” screen may be displayed.

  B. Will be described. Although the UI driver and the drawing driver are called from the OS and perform processing, they cannot communicate with each other by directly communicating with each other. This is because the driver has an I / F to be called from Windows, but cannot have any other I / F. Note that the print settings designated by the UI driver are passed to the drawing driver via the OS as a data structure called DEVMODE.

  In the technology for notifying the user of print preview and billing information, which is an example of the above interactive service, after the drawing data generation processing by the drawing driver is completed, the driver uses the drawing data generated by the drawing driver. Need to be notified. It is not possible to display an interactive screen for the drawing driver to notify as described in A above. For this reason, the drawing data generated by the drawing driver needs to be transferred to the UI driver. However, as shown in B, the UI driver and the drawing driver cannot communicate with each other by directly communicating with each other.

  In order to avoid these problems, a method of using a temporary file for holding drawing data or a dedicated module can be considered. A method in which the drawing data generated by the drawing driver is transferred to the UI driver via a temporary file or the like (avoids the problem B), and the UI driver starts a module that performs notification such as print preview (avoids the problem A). Can be considered.

However, this method also has the following problems.
(1) When printing with EMF spool, a warning screen by Windows is displayed. (2) When "Server Side Rendering" is performed in the Point & Print environment, the user cannot be notified by the interactive service.

  (1) will be described. In the case of EMF spooling, drawing data generation processing by the drawing driver is performed in an instance of the drawing driver generated on the Windows spool process. After generation of drawing data by the drawing driver is completed, it is possible for the UI driver to acquire data generated by the drawing driver using a dedicated module (referred to as a “print data holding module”). However, since the UI driver is also generated on the Windows spool process, a warning screen (“interactive service detection” screen) by Windows is displayed when the interactive screen is displayed.

  (2) will be described. When performing “server-side rendering” in the Point & Print environment, if the “print data retention module” exists on the server side, the rendering data generated by the rendering driver instantiated on the server side is used as the server-side UI driver. Will pass. That is, an interactive screen for notification is displayed on the server side. Since the printing operation is executed from the client side, the interactive screen displayed on the server side is not notified to the user watching the client side screen and cannot be operated.

  If the “print data holding module” exists on the client side, the drawing data generated by the drawing driver instantiated on the server side cannot be passed to the UI driver on the client side. I can't do it.

  In view of the above problems, an object of the present invention is to provide a program capable of providing an interactive service using data generated by a driver regardless of a spool format or an installation format.

  The present invention is a program for causing an information processing device that operates based on a predetermined program to execute processing, displaying a setting condition for output of image data, and receiving the setting condition; and Before starting, a step of starting a notification program for displaying a notification screen using print data; a setting reception program for causing the information processing apparatus to execute; and obtaining document data from an application, An image processing program for causing the information processing apparatus to execute a step of converting into print data based on the accepted setting condition, and a step of holding the print data in a print data holding program included in the predetermined program; Obtaining the print data from the print data holding program; Provides a program with a notification program to be executed by the information processing apparatus the step of displaying the notification screen using the print data.

  Regardless of the spool format or the installation format, it is possible to provide a program capable of providing an interactive service using data generated by the driver.

FIG. 3 is an example of a diagram illustrating an outline of processing by a printer driver. 1 is an example of a schematic configuration diagram of a printing system. It is an example of the hardware block diagram of PC. It is an example of a functional block diagram of a PC. It is an example of the figure explaining the flow of the printing architecture in a RAW spool. FIG. 6 is an example of a sequence diagram of the printing architecture of FIG. 5. It is an example of the figure explaining the flow of the printing architecture in an EMF spool. It is an example of the sequence diagram of the printing architecture of FIG. FIG. 3 is an example of a sequence diagram of a RAW spool printing architecture. It is an example of the sequence diagram of the printing architecture of an EMF spool. It is an example of the flowchart figure which shows the process sequence of a notification display part. It is an example of a functional block diagram of a client and a server. It is an example of a functional block diagram of a PC. FIG. 10 is an example of a sequence diagram of a RAW spool Windows OS printing architecture (Example 3); It is a figure which shows an example of a preview display screen. It is a figure which shows an example of the screen of "interactive service detection". It is an example of the figure explaining operation | movement of LanguageMonitor. It is an example of the figure explaining the format of a DrvDocumentEvent () function and a SendRecvBidiDataFromPort () function. It is an example of a figure explaining the format of ExtEscape () function. It is an example of the figure explaining the positioning of LanguageMonitor in Point & Print environment.

Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings.
FIG. 1 is an example of a diagram showing an outline of processing by the printer driver of this embodiment.
The printer driver has a UI driver, a drawing driver, and a notification module.
An OS (Operating System) calls a UI driver and a drawing driver according to a printing architecture (RAW spool, EMF spool) and executes processing necessary for printing.
Language Monitor functions as information storage means in this embodiment.
(I) First, the UI driver according to the present embodiment activates the notification module immediately after the print instruction from the application.
(Ii) The drawing driver stores drawing data created from print settings and document data in the data holding unit of the Language Monitor.
(Iii) The notification module communicates with the Language Monitor and acquires drawing data from the Language Monitor.
(Iv) The notification module provides an interactive service using the acquired drawing data.

  As described above, since the notification module is activated immediately after the printing instruction from the application, the notification module is activated by the application process. For this reason, the notification module operates in the application process even after the drawing driver instance is generated. Therefore, it is possible to prevent the warning screen from being displayed when the interactive service is displayed.

  This description is an example in which the printer driver is locally installed. However, even in the Point & Print environment, the client can display interactive services by using the server side Language Monitor by the client side notification module.

  Therefore, the printer driver according to the present embodiment can provide an interactive service using data generated by the printer driver regardless of the spool format or the installation format.

[Configuration example]
FIG. 2 shows an example of a schematic configuration diagram of the printing system 500. A printer 200 and three PCs (Personal Computers) are connected to the network 501. In the present embodiment, PC-C is a PC that prints in a local environment, PC-B is a PC that prints with a printer driver installed with Point & Print, and PC-A is a PC that performs server-side rendering in a Point & Print environment. . That is, the printer driver installed on the PC-A is installed with Point & Print on the PC-B. When the user issues a print instruction on the PC-A, printing is performed in the local environment of the PC-A as in the case of the PC-C.

Below,
PC-A to server 110
PC-B as client 120
PC-C is simply referred to as PC100.

  On the PC 100 and the client 120, an application such as document creation software operates. The printer driver creates print data from the document data created by the application and transmits it to the printer 200. In the case of server side rendering, the server 110 creates print data and transmits it to the printer 200.

  The server 110, the PC 100, and the client 120 may be any information processing device, and include a tablet, a straight PC, a smartphone, a PDA (Personal Digital Assistant), a notebook PC, a desktop PC, and the like in addition to what is called a PC .

  As long as the printer 200 has an image forming function, the name of a copier, a copier, a fax machine, or the like is not limited. The printer 200 may have either an electrophotographic image forming function or an inkjet image forming function. Note that the PC 100 or the client 120 may be directly connected to the printer 200 with a USB cable or the like.

  In the present embodiment, a printer driver will be described as an example. However, the present embodiment can be similarly applied to a PC-FAX driver.

  FIG. 3 shows an example of a hardware configuration diagram of a PC (PC 100, server 110, or client 120). The PC includes a CPU 11, a ROM 12, a RAM 13, an external I / F 14, a communication device 15, an input device 16, a display control unit 17, and a storage device 18 that are mutually connected by a bus. The CPU 11 reads the OS 10, the application 31, and the printer driver 30 from the storage device 18, and executes them using the RAM 103 as a working memory.

  The application 31 only needs to make a print request to the printer 200. For example, there are various applications such as document creation software, browser software, and presentation material creation software. Any application can be used as long as it can print, create, edit, display, and manage document data to be printed. The document data does not include only characters, symbols, and numerical values, but includes various print objects such as images and photographs.

  The OS is preferably a Windows OS. The OS in the PC 100 or the client 120 includes Windows NT, Windows 98, Windows 2000, Windows Me, Windows XP, Windows Vista, Window 7, Window 8, and later versions of the OS. The OS does not necessarily have to be a Windows OS, but may be an OS that provides a function equivalent to Windows used by the printer driver of the present embodiment.

  The RAM 13 is a working memory (main storage memory) for temporarily storing necessary data, and the ROM 12 stores BIOS, initially set data, a start program, and the like.

  The external I / F 14 is an interface for mounting a cable such as a USB cable or a portable storage medium 20. The communication device 15 is a LAN card or an Ethernet (registered trademark) card, and transmits packet data (mainly print data in this embodiment) to the printer 200 in accordance with an instruction from the CPU 11. In addition, packet data is received from the outside and notified to the CPU 11.

  The input device 16 is a user interface that accepts various user operation instructions such as a keyboard and a mouse. A touch panel or a voice input device can be used as the input device. The display control unit 17 controls the drawing of the display 19 with a predetermined resolution, number of colors, and the like based on screen information instructed by the application 31. The display 19 is an FPD (Flat Panel Display) such as a liquid crystal or an organic EL.

  The storage device 18 is a nonvolatile memory such as a hard disk drive (HDD) or a flash memory, and stores an OS 10, a printer driver 30, and an application 31.

  The storage medium 20 is a non-volatile memory such as an SD card, USB memory, or CD-ROM, for example. The OS 10, the application 31, and the printer driver 30 are distributed in a state recorded in the storage medium 20 or downloaded from a server (not shown).

  In the server 110, the display 19 may or may not be connected. The Windows OS of the server 110 includes Windows 2000 Server, 2003 Server, 2008 Server, 2011 Server, 2012 Server, and later versions of the OS.

In this embodiment, a printing procedure in local printing will be described.
FIG. 4 is an example of a functional block diagram of the PC 100. The printer driver 30 mainly communicates with the OS 10 and Language Monitor, and the application 31 mainly communicates with the OS and printer driver.

  The printer driver 30 includes a UI driver 38, a drawing driver 39, and a notification module 25. The UI driver 38 includes a print setting display unit 21 and a notification module activation unit 22. The print setting display unit 21 of the UI driver 38 displays a print setting screen (sometimes called a print dialog) on the display 19 when the user inputs a document print operation to the application 31. The user can set “monochrome / color”, “double-sided”, “combining”, “bookbinding”, “magnification”, and the number of copies on the print setting screen. The print settings are stored in a data structure (data table) called a DEVMODE structure (hereinafter simply referred to as DEVMODE). DEVMODE is a data structure in which member variables for the UI driver 38 to set print conditions in common for various printer drivers 30 operating on the OS are defined.

  The notification module activation unit 22 activates the notification module 25. The notification module activation unit 22 activates the notification module 25 immediately after the print instruction from the application 31. Immediately after the print instruction is intended before the spool process is started in the EMF spool, and may not be immediately after the print instruction. However, since the UI driver 38 may not be able to detect the timing at which the spool process is started, it is preferable that the timing is early after the print instruction. The notification module activation unit 22 can communicate with the communication unit 321 of the Language Monitor.

  The drawing driver 39 includes a drawing data generation unit 23 and a driver communication unit 24. The drawing data generation unit 23 refers to DEVMODE and creates print data reflecting print settings from the document data to be printed created by the application 31. The print data includes drawing data (for example, PDL data) and control data (for example, a PJL print command).

  The driver communication unit 24 communicates with the language monitor 32. The driver communication unit 24 instructs the communication unit 321 of the Language Monitor 32 to hold the print data (or at least drawing data) created by the drawing data generation unit 23.

  The notification module 25 includes a notification display unit 252 and a module communication unit 253. The module communication unit 253 acquires drawing data held by the data holding unit 322 of the Language Monitor 32 by communicating with the communication unit 321. The notification display unit 252 displays an interactive screen such as a preview display or billing information display using drawing data (provides an interactive service).

  FIG. 15 shows an example of a preview display screen. The preview display screen includes a document name 501, a preview 502, a printing paper size 503, the number of copies 504, a color / monochrome selection field 505, a duplex / binding selection field 506, an aggregation selection field 507, a sorting selection field 508, A punch selection field 509, a staple selection field 510, an enlarge button 511, a print button 512, a cancel button 513, and the like are arranged. That is, the preview display screen can accept selection of print settings that can be set even after the drawing data is created.

  The user can not only confirm the print result by visually checking the preview 502 but also can press the enlarge button 511 to enlarge the preview 502. If the confirmation result is good, the user presses the print button 512, and if the user is not satisfied with the drawing data, the user presses the cancel button 513. When the print button 512 is pressed, the PC 100 or the client 120 executes printing, and when the cancel button 513 is pressed, the PC 100 or the client 120 stops printing (drawing data is discarded).

When displaying the accounting information, the notification display unit 252 calculates the printing fee based on the print setting and the number of copies, and displays the accounting information instead of the preview 502 or together with the preview 502. The calculation rule is determined as follows, for example.
・ The number of printed pages N is converted to 2 pages on both sides and 2 pages on one side for A3 and above. ・ The unit price is P yen for black and white and Q yen for color. Therefore, printing fee = N x P (or Q) x number of copies. .

  Returning to FIG. 4, the Language Monitor 32 is provided by the OS 10, but is created or improved by the printer manufacturer in this embodiment. In addition, the spooler 35, the print processor 41, the port monitor 33, and the port driver 42 are provided from the OS. Therefore, the spooler 35, the print processor 41, the port monitor 33, and the port driver 42 can be regarded as a part of the OS.

  The Language Monitor 32 acquires print data from the drawing driver 39. The spooler 35 is a module that spools (temporarily saves) print data. In this embodiment, the driver communication unit 24 and the communication unit 321 communicate with each other and are stored in the language monitor 32. The print processor 41 performs processing necessary for printing mainly in the EMF spool instead of the application.

  The Language Monitor 32 has a communication unit 321 and a data holding unit 322. The communication unit 321 communicates with the driver communication unit 24 to acquire drawing data and store it in the data holding unit 322. Further, it communicates with the module communication unit 253 and sends the drawing data of the data holding unit 322 to the notification module 25. The port monitor 33 performs processing based on the communication protocol and transmits print data to the port driver 42. The port driver 42 controls a connection interface (USB, NIC, etc.) between the printer 200 and the PC 100 and transmits print data to the printer 200.

[Conventional printing architecture]
For purposes of explanation, a conventional printing architecture will be described.
FIG. 5 is an example of a diagram for explaining the flow of the print architecture of the Windows OS in the RAW spool. The GDI (Graphics Device Interface) 34 is one of the modules of the OS 10 and can be regarded as the OS 10. GDI 34 is a general term for systematic APIs used for controlling display devices such as the printer 200 and the display 19.
(1) A user changes print settings on a print setting screen (GUI: Graphical User Interface) provided by the UI driver 38 (changes an already registered initial value).
(2) The user operates the application 31 to issue a print start instruction.
(3) The application 31 exchanges DEVMODE containing the print settings with the UI driver 38, and receives the user's print settings.
(4) The application 31 transmits a print command and DEVMODE to the GDI 34 as a GDI call.
(5) The GDI 34 converts the GDI call into a DDI call and transmits it to the drawing driver 39.
(6) The drawing driver 39 transmits the RAW data converted into a language understood by the printer 200 to the spooler 35.
(7) The spooler 35 transmits the RAW data received from the drawing driver 39 to the printer 200.

  FIG. 6 is an example of a sequence diagram of the print architecture of the Windows OS in FIG. Actually, communication (not shown) is performed between the GDI 34 and the UI driver 38, or between the GDI 34 and the drawing driver 39, but is omitted. A message from the GDI 34 to the UI driver 38 is notified by a UI DDI function, and a message to the drawing driver 39 is notified by a drawing DDI function.

  By S1 in FIG. 6, the UI driver 38 has received the print settings set by the user, and when the user inputs a print start instruction, the application 31 acquires the print settings stored in DEVMODE.

  S1: The application 31 first instructs the GDI 34 to start printing preparation. Specifically, the application 31 calls the GDI 34 with the print setting (DEVMODE) as an argument using the CreateDC () function.

  S1.1: The GDI 34 sends a print setting to the drawing driver 39 by calling DDI. The print settings passed by the application to the GDI 34 with the argument of CreateDC () are stored in the argument of DrvEnablePDEV () and notified to the drawing driver 39. Thereafter, the drawing driver 39 can refer to the print setting until the job is completed (until the device context is deleted).

  S2: When the GDI 34 notifies the application 31 that the print preparation is complete, the application 31 instructs the GDI 34 to start printing. Specifically, the application 31 calls the GDI 34 using DocINFO or the like as an argument with the StartDoc () function.

  S2.1: The GDI 34 instructs the UI driver 38 to start printing. Specifically, DrvDocumentEvent () DOCUMENTEVENT_STARTDOCPRE () is sent to the UI driver 38.

  S2.2: The GDI 34 instructs the drawing driver 39 to start printing. Specifically, the DrvStartDoc () function is sent to the drawing driver 39. The OS generates a JobID at a predetermined timing using the CreateDC () function. Since the GDI 34 sets JobID as an argument of the DrvStartDoc () function, the drawing driver 39 can refer to the JobID.

  S2.3: Similarly, the GDI 34 instructs the UI driver 38 to start printing. Specifically, DrvDocumentEvent () DOCUMENTEVENT_STARTDOCPOST () is sent to the UI driver 38. Since the GDI 34 sets JobID as an argument of this function, the UI driver 38 can refer to the JobID.

  S3: When the GDI 34 notifies the application 31 of the completion of printing start, the application 31 repeats the processing for each page. First, the application 31 instructs the GDI 34 to accept print data for a new page. Specifically, the application 31 sends StartPage () to the GDI 34.

  S3.1: The GDI 34 sends DrvStartPage () to the drawing driver 39.

  S4: Upon receiving a response from the drawing driver 39, the application 31 sends a drawing function (document data) to the GDI 34.

  S4.1: The GDI 34 sends a drawing function (document data) to the drawing driver 39. The drawing driver 39 converts the document data into print data according to the print settings.

  S5: When the GDI 34 notifies the application 31 of the completion of the drawing process for one page, the application 31 notifies the GDI 34 that the writing of one page has been completed. Specifically, the application 31 sends EndPage () to the GDI 34.

  S5.1: The GDI 34 notifies the drawing driver 39 that the writing of one page has been completed. Specifically, the GDI 34 sends DrvSendPage () to the drawing driver 39.

  S6: When the drawing process for all pages is completed, the application 31 notifies the GDI 34 of the end of the print job. Specifically, the application 31 sends EndDoc () to the GDI 34.

  S6.1: The GDI 34 sends the end of the print job to the drawing driver 39. Specifically, the GDI 34 sends EndDoc () to the drawing driver 39.

S6.2: The GDI 34 sends the end of the print job to the UI driver 38. Specifically, the GDI 34 sends DrvDocumentEvent () DOCUMENTEVENT_ENDDOCPOST () to the UI driver 38.
Thereafter, the device context is deleted, and the drawing driver 39 cannot refer to the print setting (the DDI call of DrvDisablePDEV () is notified to the drawing driver).

FIG. 7 is an example of a diagram for explaining the flow of the print architecture of the Windows OS in the EMF spool.
(1) The user changes the print setting on the print setting screen (GUI) provided by the UI driver 38 (changes the already registered initial value).
(2) The user operates the application 31 to issue a print start instruction.
(3) The application 31 exchanges DEVMODE containing the print settings with the UI driver 38, and receives the user's print settings.
(4) The application 31 notifies the GDI 34 of a print command as a GDI call.
(5) The GDI 34 passes the EMF data to the spooler 35 as spool data.
(6) When the EMF data is spooled, the spooler 35 informs the print processor 41 that it is despooled and passes the spool data.
(7) The print processor 41 edits the spool data for each page to realize the functions of aggregation, reverse order, and bookbinding, and notifies the edited content to the GDI 34 as a GDI call.
(8) The GDI 34 converts the GDI call into a DDI call and notifies the drawing driver 39 of it.
(9) The drawing driver 39 sends the RAW data converted into a language understood by the printer 200 to the spooler 35.
(10) The spooler 35 transmits the RAW data received from the drawing driver 39 to the printer 200.

  FIG. 8 is an example of a sequence diagram of the print architecture of the Windows OS in FIG. Actually, communication (not shown) is performed between the GDI 34 and the UI driver 38, or between the GDI 34 and the drawing driver 39, but is omitted. In the EMF spool, the application process and the spool process are separated.

  Note that the UI driver 38 has received print settings set by the user by S1 in FIG. 8, and when the user inputs a print start instruction, the application 31 acquires the print settings stored in DEVMODE.

  S1: The application 31 first instructs the GDI 34 to start printing preparation. Specifically, the application 31 calls the GDI 34 with the print setting as an argument using the CreateDC () function.

  S1.1: The GDI 34 sends a print setting to the drawing driver 39 by calling a DDI corresponding to the API. The print settings passed by the application to the GDI 34 with the argument of CreateDC () are stored in the argument of DrvEnablePDEV () and notified to the drawing driver 39. Thereafter, the drawing driver 39 can refer to the print setting until the job is completed (until the device context is deleted).

  S2: When the GDI 34 notifies the application 31 that the print preparation is complete, the application 31 instructs the GDI 34 to start printing. Specifically, the application 31 calls the GDI 34 using DocINFO or the like as an argument with the StartDoc () function.

  S2.1: The GDI 34 instructs the UI driver 38 to start printing. Specifically, DrvDocumentEvent () DOCUMENTEVENT_STARTDOC () is sent to the UI driver 38.

  S2.2: The GDI 34 sends a JobID to the UI driver 38. Specifically, DrvDocumentEvent () DOCUMENT_STARTDOCPOST () is sent to the UI driver 38. Since the GDI 34 sets JobID as an argument of this function, the UI driver 38 can refer to the JobID. At this point, the drawing driver 39 has not acquired a JobID.

  S3: When the GDI 34 notifies the application 31 of the completion of printing start, the application 31 repeats the processing for each page. First, the application 31 instructs the GDI 34 to accept print data for a new page. Specifically, the application 31 sends StartPage () to the GDI 34. The spool process is started by StartPage ().

  S4: The application 31 sends a drawing function (document data) to the GDI 34. The GDI 34 creates EMF data based on the print settings.

  S5: The application 31 notifies the GDI 34 that writing for one page has been completed. Specifically, the application 31 sends EndPage () to the GDI 34.

  S6: When the drawing process for all pages is completed, the application 31 notifies the GDI 34 of the end of the print job. Specifically, the application 31 sends EndDoc () to the GDI 34.

  As described above, when the process of the application 31 is finished, the application 31 seems to have finished printing even if printing is not completed. Thereafter, the printing process is performed again in the spool process, where EMF data is converted to RAW data.

  The OS 10 monitors the communication between the application 31 and the GDI 34, and at a predetermined timing (for example, after StartPage ()), causes the spooler 35 to start the spool process.

  S7: The spooler 35 instructs the print processor 41 to start printing preparation.

  S7.1: The print processor 41 instructs the GDI 34 to start printing preparation.

  S7.1.1: The GDI 34 sends print settings to the drawing driver 39. Specifically, the print setting that the application has passed to the GDI 34 with the argument of CreateDC () is stored in the argument of DrvEnablePDEV () and notified to the drawing driver 39. Thereafter, the drawing driver 39 can refer to the print setting until the job is completed (until the device context is deleted).

  S7.1.2: The GDI 34 instructs the drawing driver 39 to start printing. Specifically, the DrvStartDoc () function is sent to the drawing driver 39. The OS generates a JobID at a predetermined timing using the CreateDC () function. Since the GDI 34 sets JobID as an argument of the DrvStartDoc () function, the drawing driver 39 can refer to the JobID.

  S7.2: Thereafter, the print processor 41 repeats the processing for each page. First, the print processor 41 instructs the GDI 34 to accept print data for a new page. Specifically, the print processor 41 sends GdiStartPageEMF () to the GDI 34.

  S7.2.1: The GDI 34 sends DrvStartPage () to the drawing driver 39.

  S7.2.2: The GDI 34 sends a drawing function (document data) to the drawing driver 39. The drawing driver 39 converts the document data into print data according to the print settings.

  S7.2.3: The GDI 34 notifies the drawing driver 39 that the writing of one page has been completed. Specifically, the GDI 34 sends DrvSendPage () to the drawing driver 39. Thereafter, it is repeated in units of pages.

[Printing procedure of Windows OS of this embodiment]
In the print setting, whether or not the user uses the interactive service is set. In this embodiment, settings are made to use an interactive service. In the print settings, whether or not to display a print dialog for accepting the change of the print settings after the start of printing is set. With this print dialog, the PC 100 and the client PC 100 can request input of a user ID and password, or request input of a FAX destination (FAX number). In this embodiment, only a brief description of this print dialog will be given.

RAW Spool FIG. 9 is an example of a sequence diagram of the print architecture of the RAW spool Windows OS. Actually, communication (not shown) is performed between the GDI 34 and the UI driver 38, or between the GDI 34 and the drawing driver 39, but is omitted. A message from the GDI 34 to the UI driver 38 is notified by a UI DDI function, and a message to the drawing driver 39 is notified by a drawing DDI function.

  The UI driver 38 has received the print settings set by the user by S1 in FIG. 9, and when the user inputs a print start instruction, the application 31 acquires the print settings stored in DEVMODE.

  S1: The application 31 first instructs the GDI 34 to start printing preparation. Specifically, the application 31 calls the GDI 34 with the print setting as an argument using the CreateDC () function.

  S1.1: The GDI 34 sends a print setting to the drawing driver 39 by calling a DDI corresponding to the API. The print settings passed by the application to the GDI 34 with the argument of CreateDC () are stored in the argument of DrvEnablePDEV () and notified to the drawing driver 39. Thereafter, the drawing driver 39 can refer to the print setting until the job is completed (until the device context is deleted).

  S2: When the GDI 34 notifies the application 31 that the print preparation is complete, the application 31 instructs the GDI 34 to start printing. Specifically, the application 31 calls the GDI 34 using DocINFO or the like as an argument with the StartDoc () function.

  S2.1: The GDI 34 instructs the UI driver 38 to start printing. Specifically, DrvDocumentEvent () DOCUMENTEVENT_STARTDOCPRE () is sent to the UI driver 38.

  S2.2: The GDI 34 instructs the drawing driver 39 to start printing. Specifically, the DrvStartDoc () function is sent to the drawing driver 39. The OS 10 generates a JobID at a predetermined timing using the CreateDC () function. Since the GDI 34 sets JobID as an argument of the DrvStartDoc () function, the drawing driver 39 can refer to the JobID.

  S2.3: Similarly, the GDI 34 instructs the UI driver 38 to start printing. Specifically, DrvDocumentEvent () DOCUMENTEVENT_STARTDOCPOST () is sent to the UI driver 38. Since the GDI 34 sets the JobID in the IN argument of this function, the UI driver 38 can refer to the JobID.

  S2.3.1: The UI driver 38 activates the notification display unit 252 immediately after calling from the GDI 34. The processing procedure of the notification display unit 252 is shown in the flowchart of FIG. At this time, the UI driver 38 notifies the JobID passed in the IN argument of DrvDocumentEvent (DOCUMENTEVENT_STARTDOCPOST) together with the activation of the notification display unit 252. The notification display unit 252 identifies the drawing data of the Language Monitor 32 by JobID.

  In this way, the UI display 38 that operates when printing starts activates the notification display unit 252, so that the notification display unit 252 can be activated immediately after printing starts.

  However, at this time, the notification display unit 252 does not display the interactive screen yet. As will be described later, the notification display unit 252 confirms whether or not the module communication unit 253 periodically communicates with the communication unit 321 of the Language Monitor to generate the drawing data associated with the JobID.

  S2.3.2: Next, the UI driver 38 refers to the print setting to determine whether the print setting has a setting for accepting the change of the print setting after the print start instruction, but cannot directly communicate with the drawing driver 39. Therefore, ExtEscape () is sent to the GDI 34.

  S2.3.2.1: The GDI 34 notifies the drawing driver 39 of DrvEscape (). The drawing driver 39 sends the print settings held through the GDI 34 to the UI driver 38.

  In S2.4: ExtEscape () processing, the UI driver 38 has acquired the print settings. When a print dialog display instruction for changing the print setting is set after the print start instruction (during printing), the UI driver 38 displays a pop-up (dialog) for accepting the change of the print setting. Then, the change of the print setting by the user is accepted.

  The notification display unit 252 is a program that displays a preview or the like and accepts a user operation, but drawing data is not created at this stage. Therefore, the activated notification display unit 252 periodically inquires whether or not drawing data has been created in the Language Monitor 32 as in S2.3.1.1 (polling).

  S2.3.3: Next, the UI driver 38 sends SendRecvBidiDataFromPort () :: set with the JobID as a key and the print setting changed by the user to the Language Monitor 32 (“::” indicates that “DOCUMENTEVENT” is omitted) means). Thereby, the Language Monitor 32 can hold the JobID and the print setting in association with each other. At this time, the contents indicating whether the user closed the popup (dialog) by “OK” or “Cancel” is also transmitted.

  S3: When the GDI 34 notifies the application 31 of the completion of printing start, the application 31 repeats the processing for each page. First, the application 31 instructs the GDI 34 to accept print data for a new page. Specifically, the application 31 sends StartPage () to the GDI 34.

  S3.1: The GDI 34 sends DrvStartPage () to the drawing driver 39.

  S3.1.1: The drawing driver 39 requests print setting from the Language Monitor 32 with SendRecvBidiDataFromPort () :: get using the held JobID as a key only when the DDI call of the first DrvStartPage () is received. Here, the Language Monitor 32 holds information indicating whether the user closed with “OK” or “Cancel” in S2.3.3. If the user is closed with “OK”, the drawing driver 39 generates print data based on the print settings. If it is closed by “Cancel”, data is not transmitted to the printer 200 or the FAX apparatus.

  Then, the drawing driver 39 sets a part of print data (including drawing data) in the Language Monitor 32 using JobID as a key.

  S4: Upon receiving a response from the drawing driver 39, the application 31 sends a drawing function (document data) to the GDI 34.

  S4.1: The GDI 34 sends a drawing function (document data) to the drawing driver 39. The drawing driver 39 converts the document data into print data according to the print settings.

  S4.2: The drawing driver 39 sets print data (including drawing data) in the Language Monitor 32 as needed using JobID as a key.

  S5: When the GDI 34 notifies the application 31 of the completion of the drawing process for one page, the application 31 notifies the GDI 34 that the writing of one page has been completed. Specifically, the application 31 sends EndPage () to the GDI 34.

  S5.1: The GDI 34 notifies the drawing driver 39 that the writing of one page has been completed. Specifically, the GDI 34 sends DrvSendPage () to the drawing driver 39.

  S5.2: The drawing driver 39 sets a part of print data (including drawing data) in the Language Monitor 32 using JobID as a key.

  S6: When the drawing process for all pages is completed, the application 31 notifies the GDI 34 of the end of the print job. Specifically, the application 31 sends EndDoc () to the GDI 34.

  S6.1: The GDI 34 notifies the UI driver 38 of the end of drawing (specifically, DOCUMENTEVENT_ENDDOC_PRE).

  S6.1.1: The UI driver 38 calls the ExtEscape () function to know the JobID of the job that has finished drawing.

  S6.1.2: The UI driver obtains a JobID from the drawing driver 39 via the GDI 34.

  S6.1.3: The UI driver 38 sends SendRecvBidiDataFromPort () to the Language Monitor, and sets the creation completion of drawing data together with the JobID.

  S2.3.1.1: After this, the processing on the application side is the same as before. On the other hand, the notification display unit 252 (the module communication unit of the notification module) periodically inquires the Language Monitor 32 to detect that the setting of the drawing data has been completed.

S2.3.1.2: Upon receiving a response that the drawing data setting is completed from the Language Monitor 32, the notification display unit 252 acquires drawing data from the Language Monitor 32 using the JobID as a key, and an interactive screen including a print preview. Is displayed. The user views the print preview and selects OK (continuation) or cancel of printing.
S2.3.1.3: The notification display unit 252 sets in the Language Monitor 32 that the interactive screen is displayed using the JobID as a key and the selection result of OK or cancellation is displayed.
S2.3.1.4: When the user closes the interactive screen with OK, the notification display unit 252 ends the display. As a result, the information “finished with OK” is passed from the notification module to the language monitor 32, and the drawing driver acquires it and starts the process of sending the drawing data to the printer.

EMF spool FIG. 10 is an example of a sequence diagram of the print architecture of the Windows OS of the EMF spool. Actually, communication (not shown) is performed between the GDI 34 and the UI driver 38, or between the GDI 34 and the drawing driver 39, but is omitted.

  The UI driver 38 has received the transmission setting set by the user by S1 in FIG. 10, and when the user inputs a transmission start instruction, the application 31 acquires the transmission setting stored in DEVMODE.

  S1: The application 31 first instructs the GDI 34 to start printing preparation. Specifically, the application 31 calls the GDI 34 with the print setting as an argument using the CreateDC () function.

  S1.1: The GDI 34 sends a print setting to the drawing driver 39 by calling a DDI corresponding to the API. The print settings passed by the application to the GDI 34 with the argument of CreateDC () are stored in the argument of DrvEnablePDEV () and notified to the drawing driver 39. Thereafter, the drawing driver 39 can refer to the print setting until the job is completed (until the device context is deleted).

  S2: When the GDI 34 notifies the application 31 that the print preparation is complete, the application 31 instructs the GDI 34 to start printing. Specifically, the application 31 calls the GDI 34 using DocINFO or the like as an argument with the StartDoc () function.

  S2.1: The GDI 34 instructs the UI driver 38 to start printing. Specifically, DrvDocumentEvent () DOCUMENTEVENT_STARTDOC () is sent to the UI driver 38.

  S2.2: The GDI 34 sends a JobID to the UI driver 38. Specifically, DrvDocumentEvent () DOCUMENTEVENT_STARTDOCPOST () is sent to the UI driver 38. Since the GDI 34 sets the JobID in the IN argument of this function, the UI driver 38 can refer to the JobID. At this point, the drawing driver 39 has not acquired a JobID.

  S2.2.1: The UI driver 38 activates the notification display unit 252 immediately after calling from the GDI 34. The processing procedure of the notification display unit 252 is shown in the flowchart of FIG. At this time, the UI driver 38 notifies the job ID passed by the IN argument of DrvDocumentEvent (DOCUMENTEVENT_STARTDOCPOST) together with the activation of the notification display unit 252. The notification display unit 252 identifies the drawing data of the Language Monitor 32 by JobID.

  However, at this time, the notification display unit 252 does not display the interactive screen yet. As will be described later, the notification display unit 252 confirms whether or not the module communication unit 253 periodically communicates with the communication unit 321 of the Language Monitor to generate the drawing data associated with the JobID.

  S2.2.2: Here, the UI driver 38 detects that the print setting has a setting for accepting the change of the print setting after the print start instruction. For this reason, the UI driver 38 starts a pop-up display process. The UI driver 38 calls ExtEscape () on the GDI 34 with the device context as an argument.

  S2.2.2.1: The GDI 34 requests a print setting held by the drawing driver 39 by sending a DDI call of DrvEcape () to the drawing driver 39. The drawing driver 39 sends the print settings held through the GDI 34 to the UI driver 38.

  In S2.4: ExtEscape () processing, the UI driver 38 has acquired the print settings. When a print dialog display instruction for changing the print setting is set in the print setting after the print start instruction (during printing), the UI driver 38 accepts the change of the print setting by the user.

  S2.2.3: When the user closes the print dialog, the UI driver 38 sends the print setting changed by the user to the Language Monitor 32 using SendRecvBidiDataFromPort () :: set with JobID as a key. Thereby, the Language Monitor 32 can hold the JobID and the print setting in association with each other. At this time, the contents indicating whether the user closed the dialog with "OK" or "Cancel" is also sent. Since S3 to S6 are the same as the conventional ones, they are omitted.

  Printing in the application process (generation of EMF data) ends, but the notification display unit 252 is already activated in the application process.

  Thereafter, the printing process is again performed in the process of the spooler 35, where EMF data is converted to RAW data. The OS 10 monitors the communication between the application 31 and the GDI 34, and at a predetermined timing (for example, after StartPage ()), causes the spooler 35 to start the process.

  S7: The spooler 35 instructs the print processor 41 to start printing preparation.

  S7.1: The print processor 41 instructs the GDI 34 to start printing preparation.

  S7.1.1: The GDI 34 sends print settings to the drawing driver 39. Specifically, the print setting that the application has passed to the GDI 34 with the argument of CreateDC () is stored in the argument of DrvEnablePDEV () and notified to the drawing driver 39. Thereafter, the drawing driver 39 can refer to the print setting until the job is completed (until the device context is deleted).

  S7.1.2: The GDI 34 instructs the drawing driver 39 to start printing. Specifically, the DrvStartDoc () function is sent to the drawing driver 39. The OS 10 generates a JobID at a predetermined timing using the CreateDC () function. Since the GDI 34 sets JobID as an argument of the DrvStartDoc () function, the drawing driver 39 can refer to the JobID.

  S7.2: Thereafter, the print processor 41 repeats the processing for each page. First, the print processor 41 instructs the GDI 34 to accept print data for a new page. Specifically, the print processor 41 sends GdiStartPageEMF () to the GDI 34.

  S7.2.1: The GDI 34 sends DrvStartPage () to the drawing driver 39.

  S7.2.1.1: The drawing driver 39 requests print setting from the Language Monitor 32 with SendRecvBidiDataFromPort () :: get using the held JobID as a key only when it receives the first DDI call of DrvStartPage (). . Here, the Language Monitor 32 holds information indicating whether the user closed the print dialog in S2.2.3 by “OK” or “Cancel”. If the user is closed with “OK”, the drawing driver 39 generates print data based on the print settings. If it is closed by “Cancel”, data is not transmitted to the printer 200 or FAX.

  Further, the drawing driver 39 sets a part of print data (including drawing data) in the Language Monitor 32 using JobID as a key.

  S7.2.2: The GDI 34 sends a drawing function (document data) to the drawing driver 39. The drawing driver 39 converts the document data into print data according to the print settings.

  S7.2.2.1: The drawing driver 39 sets print data (including drawing data) in the Language Monitor 32 as needed using JobID as a key.

  S7.2.3: The GDI 34 notifies the drawing driver 39 that the writing of one page has been completed. Specifically, the GDI 34 sends DrvSendPage () to the drawing driver 39.

  S7.2.3.1: The drawing driver 39 sets a part of print data (including drawing data) in the Language Monitor 32 using JobID as a key.

  S7.3: When the drawing driver 39 completes drawing, the print processor outputs GdEndDocEMF () to GDI.

  S7.3.1: The GDI 34 notifies the UI driver 38 of the end of drawing by outputting DOCUMENTEVENT (ENDDOC).

  S7.3.2: The UI driver 38 (only when the spool format is EMF) calls ExtExcape () to acquire the JobID from the drawing driver. This is because JobD is not notified by the IN argument of DrvDocumentEvent (ENDDOC).

  S7.3.2.1: GDI calls DrvExcape () to obtain JobID from the drawing driver.

  S7.3.1.1: Next, the UI driver notifies (records) to the Language Monitor (the communication unit) that the generation of the drawing data associated with the acquired JobID has been completed.

  S7.3.3: GDI notifies drawing driver of drawing end.

  S7.3.3.1: The drawing driver inquires the Language Monitor whether or not the interactive screen has been displayed, and notifies the GDI when it is finished. This inquiry is because an interactive screen is displayed by notifying the Language Monitor that the generation of drawing data has been completed.

  S2.2.1.1: Thereafter, the notification display unit 252 periodically inquires the Language Monitor 32 to detect that the setting of the drawing data has been completed.

  S2.2.1.2: Upon receiving a response from the Language Monitor 32 that the drawing data setting has been completed, the notification display unit 252 reads the drawing data from the Language Monitor 32 using the JobID as a key, and displays an interactive screen including a print preview. To do. The user views the print preview and selects whether to continue (continue) or cancel printing.

  S2.2.1.3: The notification display unit 252 sets, in the Language Monitor 32, the fact that the interactive screen is displayed using the JobID as a key and the selection result of continuation or cancellation.

  S2.2.1.4: When the user closes the interactive screen with OK, the notification display unit 252 ends the display. The process of transmitting the drawing data acquired by the drawing driver to the printer is started.

Processing Procedure of Notification Display Unit 252 FIG. 11 is an example of a flowchart illustrating a processing procedure of the notification display unit 252.
When the printing process is started, the UI driver 38 activates the notification display unit 252 (S10). This process corresponds to S2.3.2 in FIG. 9 and S2.2.2 in FIG.

  The notification display unit 252 continues to poll the Language Monitor 32 for an inquiry “whether or not data generation by the drawing driver has been completed” (S20).

  When generation of drawing data by the drawing driver 39 is completed (Yes in S30), the notification display unit 252 acquires drawing data from the Language Monitor 32 and displays an interactive screen (S40).

  Since the user presses OK (Continue) or Cancel, the notification display unit 252 determines whether or not the process has ended with OK (S50). If the print driver 39 does not end with OK (No in S50), the drawing driver 39 stops printing. The print data of Language Monitor 32 is discarded.

  When the processing is completed with OK (Yes in S50), the drawing driver 39 transmits the print data to the spooler 35 (S60). This process is the same as the normal printing sequence.

  The printer 200 prints the print data transmitted from the spooler 35 (S60).

  As described above, since the notification module 25 is activated immediately after the print instruction from the application 31, the notification module 25 activated in the application process can display an interactive service such as a print preview. . For this reason, it is possible to prevent the warning screen from being displayed in the EMF spool (also in the RAW spool).

  In this embodiment, a printing procedure when the printer driver is installed with Point & Print will be described. When RAW spooling is performed in the Point & Print environment, the rendering location is the client 120, so the processing procedure is the same as that of the RAW spool of the first embodiment. When EMF spooling is performed in the Point & Print environment, there are two rendering locations, the client 120 and the server 110. When the rendering location is the client 120, the processing procedure is the same as that of the EMF spool of the first embodiment. .

  When the rendering location is the server 110, the location where the drawing driver 39 operates is the server 110. However, as described below, the processing procedure of the entire printing process is the same as that of the EMF spool of the first embodiment. .

  FIG. 12 shows an example of a functional block diagram of the client 120 and the server 110. Only the main part of the common part between FIG. 12 and FIG. 4 will be described.

  The printer driver 30 of the client 120 has a UI driver 38 and a notification module 25. In the server-side rendering of Point & Print installation, the drawing driver of the client 120 does not create drawing data, but operates when the application 31 acquires necessary information. In “client-side rendering”, the drawing driver of the client 120 operates.

  In the server-side rendering, the function of the language monitor 32 described in the first embodiment is provided by the language monitor 32 of the server 110. However, the language monitor 32 is also used by the client 120 in order to share data with the language monitor 32 on the server side. The language monitor 32 of the client 120 communicates with the language monitor 32 of the server to acquire drawing data.

  The server 110 includes a printer driver 30, a spooler 35, a print processor 41, a language monitor 32, a port monitor 33, and a port driver 42. The printer driver 30 does not include the UI driver 38 and the notification module 25, but is actually installed together with the drawing driver 39. The notification module activation unit 22 on the PC side can communicate with the spooler 35.

  In addition, the spooler 35, the print processor 41, the language monitor 32, the port monitor 33, and the port driver 42 are the same as those of the PC 100 in the first embodiment.

  Since the OS of the client 120 and the OS of the server 110 are both Windows, the language monitor 32 can be handled as the same instance from the client 120 and the server 110 in the server-side rendering.

  That is, in the server side rendering of the EMF spool, the GDI 34 creates EMF data at the client 120 and sends it to the spooler 35 of the client 120. The spooler 35 of the client 120 transmits EMF data to the spooler 35 of the server 110 via the OS. Thereafter, a spool process is executed by the server 110 and drawing data is stored in the Language Monitor 32. When the notification module 25 requests drawing data from the language monitor 32 of the client 120, the drawing data can be acquired from the language monitor 32 of the server 100 via the OS.

  That is, the notification module 25 does not need to be aware of where the Language Monitor 32 is. Therefore, as a printing procedure, only the spool process is executed by the server 110, and the overall procedure is the same as that in FIG. 10 of the first embodiment.

  The application process module shown in FIG. 10 is instantiated by the client 120, and the spool process module is instantiated by the server 110. However, the module shown in FIG. 12 provides the main functions in this embodiment.

For this reason, the following operations are performed in the EMF spool of Point & Print.
(i) The UI driver 38 of the client 120 activates the notification module 25 immediately after the print instruction from the application 31 (S2.2.1).
(ii) The OS of the client 120 that created the EMF data instructs the server to start the spool process. The drawing driver 39 in the server 110 creates drawing data (A in FIG. 10).
(iii) The driver communication unit 24 of the drawing driver 39 of the server 110 causes the language monitor 32 on the server side to hold drawing data in association with the JobID (S7.2.1.1, S7.2.2.1, S7.2.3.1). ). The UI driver 38 sets completion of drawing data creation in the language monitor 32 on the server side.
(iv) When the server-side UI driver calls DrvDocumentEvent (ENDDOC), the generation of drawing data is completed. Therefore, the UI driver calls ExtExcape () to acquire the JobID from the drawing driver. Next, the UI driver notification module activation unit notifies the Language Monitor that generation of drawing data associated with the acquired JobID has been completed.
(v) The module communication unit 253 of the notification module 25 on the client side inquires of the language monitor 32 of the client 120 via the spooler 35 whether or not the creation of the drawing data has been completed (S2.2.1.1). The Language Monitor 32 of the client 120 inquires of the Language Monitor 32 of the server 110 whether or not the creation of the drawing data has been completed using the OS function. When the creation of the drawing data is completed, the language monitor 32 of the client 120 acquires the drawing data from the language monitor 32 of the server 110.
(vi) The notification display unit 252 acquires drawing data from the language monitor 32 of the client 120 and notifies the user as an interactive screen (S2.2.1.2).

  As described above, in the “server side rendering” of the Point & Print environment, the printer driver 30 can notify the user by the interactive service.

  Therefore, according to the present embodiment, the printer driver 30 can notify the user by the interactive service regardless of the installation environment.

  The configuration of FIG. 12 is an example, and any one of the client 120 and the server 110 may provide the function of FIG.

  In addition, a plurality of servers 110 may be provided. Any one of the client 110 and the plurality of servers 120 may provide the function of FIG. For example, the server for installing the printer driver 30 and the server for rendering may be different.

  As described above, the print driver of this embodiment can provide a program that can provide an interactive service using data generated by the print driver regardless of the spool format or the installation format. .

  Further, the system configuration described in this embodiment is an example, and it goes without saying that there are various system configuration examples depending on the application and purpose.

In Examples 1 and 2,
(1) When printing with EMF spool, a Windows warning screen is displayed. (2) When performing “server-side rendering” in the Point & Print environment, users cannot be notified with interactive services. We were able to solve the problem.

However, there are still the following problems.
(3) In the case of print processing by RAW spool, if a print instruction is issued from a 32-bit application on a 64-bit OS, the ExtEscape () API may not operate correctly.

  A 32-bit application can run on a 64-bit OS by a Windows function called WOW64 (Windows 32-bit on Windows 64-bit). When a print instruction is issued from a 32-bit application on a 64-bit OS, an instance of a 64-bit printer driver is generated from a process on the 32-bit application in the case of print processing using a RAW spool. The phenomenon that cannot be called correctly occurs.

  More specifically, the UI driver 38 calls ExtEscape () to acquire the JobID from the drawing driver 39, and notifies the Language Monitor 32 that the generation of the drawing data associated with the JobID has been completed. The module can be displayed. However, when a print instruction is issued from a 32-bit application operating on a 64-bit OS, this processing sequence does not operate correctly.

  When a print instruction is issued from a 32-bit application running on a 64-bit OS, if the UI driver 38 calls ExtEscape () at the ENDDOC event of DrvDocumentEvent (), splwow64.exe (a 64-bit Windows OS will be This is because an exception occurs in the proxy process) and DrvEscape () of the drawing driver 39 is not correctly called.

  Therefore, in this embodiment, the above-described inconvenience is avoided by the following processing sequence. The following processing sequence is valid only when printing with the RAW spool. This is because at the time of EMF spooling, the instance of the UI driver 38 is not generated from the application, but is newly instantiated from the spooler process, so that the UI driver 38 cannot use the global memory described later.

  However, since the UI driver 38 is newly instantiated from the spooler process at the time of EMF spooling, there is no inconvenience because an exception does not occur in splwow64.exe when ExtEscape () is called.

  FIG. 13 is an example of a functional block diagram of the PC of this embodiment. In this embodiment, a global memory 43 is arranged in the PC. This global memory is a memory that can be accessed by the instantiated UI driver 38 at an arbitrary timing. Specifically, it is a part on the RAM 13.

  In this embodiment, when printing on the RAM spool, the UI driver 38 stores the JobID passed from the OS in the global memory 43 in association with the device context. When the UI driver 38 receives a drawing data generation completion notification from the OS, the UI driver 38 reads out the JobID stored in the global memory 43 in association with the device context. Then, it notifies the Language Monitor 32 of the completion of generation of the drawing data associated with the JobID. The notification module communicates with the language monitor 32 and acquires drawing data from the language monitor 32. The notification module provides an interactive service using the acquired drawing data.

  Therefore, when the drawing data generation is completed, the UI driver 38 calls ExtEscape () and does not acquire the JobID from the drawing driver 39, so that no splwow64.exe exception occurs.

  FIG. 14 is an example of a sequence diagram of the print architecture of the RAW spool Windows-based OS of this embodiment. Since the overall flow is the same as that of FIG. 9 of the first embodiment, the characteristic part of the present embodiment will be mainly described.

  S2.3.1.1: The UI driver 38 that has activated the notification module records the JobID in the global memory 43 in association with the device context handle (HDC).

  S6.1: When the drawing driver 39 completes drawing, the GDI 34 notifies the UI driver 38 of the end of drawing (specifically, DOCUMENTEVENT_ENDDOC_PRE).

  S6.1.1: The UI driver 38 reads JobID from the global memory 43 using HDC as a key.

  S6.1.2: The UI driver 38 sends SendRecvBidiDataFromPort () to the Language Monitor 32, and sets the creation completion of drawing data together with the JobID.

  That is, since the job ID is not included in the argument of the DOCUMENTEVENT_ENDDOC_PRE function, the UI driver 38 may call ExtEscape () to receive the Job ID from the drawing driver 39. However, when a print instruction is issued from a 32-bit application operating on a 64-bit OS, this ExtEscape () call fails. Therefore, in this embodiment, the JobID associated with the HDC is acquired from the global memory 43 by using the fact that the HDC is included in the argument of the DrvDocumentEvent (ENDDOCPRE).

  The UI driver 38 records the job ID and drawing data creation completion in the Language Monitor 32, so that the notification module that has monitored the Language Monitor 32 can detect the completion of the drawing data. Therefore, the drawing data is acquired and the interactive screen is displayed. Can be displayed.

  When the user selects “OK” on the interactive screen, the information “completed with OK” is recorded in the language monitor 32 from the notification module. Thereafter, when the drawing driver 39 receives a notice of completion of the drawing process and reads the information “finished with OK” in the Language Monitor 32, the drawing driver 39 sends drawing data to the printer side. In the case of the Point & Print environment, the server-side drawing driver 39 acquires information “Ended with OK” from the Language Monitor 32 and starts processing for sending drawing data to the printer.

  As described above, the printer driver according to the present embodiment can display an interactive screen using drawing data even when a print instruction is issued from a 32-bit application on a 64-bit OS in the case of print processing using a RAW spool. it can.

[About command examples]
The following supplements the APIs and functions of the Windows OS used in this embodiment. These functions are explanations of the Windows OS, but can also be applied to other OSs having equivalent functions.

  FIG. 17 is an example of a diagram for explaining the operation of the Language Monitor 32. The LanguageMonitor 32 receives the print data transmitted from the print processor 41 and transmits it to the port monitor 33. The port monitor 33 performs processing based on the communication protocol and transmits print data to the port driver 42. The port driver 42 controls a connection interface (USB, NIC, etc.) between the printer 200 and the PC 100 and transmits print data to the printer 200.

FIG. 18A is an example of a diagram illustrating the format of the DrvDocumentEvent () function. The DrvDocumentEvent () function is a DLL that processes a specific event related to printing of document data.
HPrinter is the handle of the printer.
Hdc is a device context handle.
IEsc is an escape code provided by the calling module for identifying the event to be processed.
CbIn is the size of data transmitted with pvIn.
PvIn is a pointer to the data to be transmitted.
CbOut stores the value specified by the function as the cbOutput parameter of ExtEscape () when iEsc is DOCUMENTEVENT_ESCAPE. When iEsc is DOCUMENTEVENT_QUERYFILTER, the size of the structure pvOut received by the receiving side is stored.
PvOut is a pointer to the structure pvOut received by the receiving side.

  In this embodiment, the DrvDocumentEvent () function is called as appropriate during a DDI call that the GDI 34 or the like calls the drawing driver 39 during printing after CreateDC (). Since DrvDocumentEvent () is a DDI for performing a single process, data cannot be shared between the preceding and succeeding DrvDocumentEvent (). This is different from DDI that calls the drawing driver 39. Since it is a UI type DDI, it is possible to display a dialog.

  Since the device context (hdc) is included in the argument, after the DDI call of DrvDocumentEvent (), the module can call an API that requires the device context. For example, when the UI driver 38 calls a drawing system API with a device context as an argument, a drawing command can be notified to the corresponding drawing driver 39.

FIG. 18B is an example of a diagram illustrating the format of SendRecvBidiDataFromPort (). The SendRecvBidiDataFromPort () function is a function implemented in the LanguageMonitor 32. Similar to the printer driver 30, the Language Monitor 32 has an I / F determined by the OS 10. The SendRecvBidiDataFromPort () function is one of them, and supports bidirectional communication between the application and the printer and between the application and the print server.
HPort is the handle of the port given by the calling module.
DwAccessBit is an ACCESS_MASK structure that is given by the calling module and allows access to the printer or print server.
PAction is a request action given by the calling module.
PReqData is a pointer to the PBIDI_REQUEST_CONTAINER structure that has the request data.
PpResData is a pointer to a memory area that receives the address of the BIDI_RESPONSE_CONTAINER structure having response data.

FIG. 19A is an example for explaining the format of the ExtEscape () function. The ExtEscape () function is an API for accessing a specific module that cannot be accessed via the GDI by a module (each block in the sequence diagram and functional block diagram). When the application transmits data to the driver without involving the GDI 34, the application may be used when acquiring data without involving the GDI 34 from the module.
Hdc is a device context handle.
NEscape is an argument for checking and setting the function of the ExtEscape () function.
CbInput is the size of the structure to be sent with the ExtEscape () function.
LpszInData is a structure pointer that is sent with the ExtEscape () function.
CbOutput is the size of the structure that receives the structure sent with the ExtEscape () function.
LpszOutData is a structure pointer that receives the structure sent by the ExtEscape () function.

  The ExtEscape () function is an API that can be called with respect to the device context acquired by CreateDC (). Therefore, the UI driver 38 and the like can call the ExtEscape () function within a certain range within the device context during the sequence processing.

FIG. 19B shows an example of a sequence diagram when the application calls ExtEscape ().
(i) The application calls ExtEscape () on the GDI 34.
(ii) The GDI 34 converts ExtEscape () into a DDI call called DrvEscape () and notifies the drawing driver 39 of it.

  Conversely, the drawing driver 39 or the UI driver 38 can also call ExtEscape (). Each module can call ExtEscape () between CreateDC () and DeleteDC ().

  FIG. 20 is an example for explaining the positioning of the Language Monitor 32 in the Point & Print environment. LanguageMonitor 32 is a module incorporated in the printing architecture of the Windows OS. Therefore, even if the client PC side handles the processing of the UI driver 38 and the server PC side handles the processing of the drawing driver 39 by Point & Print, only one Language Monitor 32 functions on the server PC side. For this reason, the printer driver 30 of the client PC and the printer driver 30 of the server PC 110 access one Language Monitor 32. That is, the OS 10 of the client PC and the OS 10 of the server PC establish communication between the client PC and the server PC 110 when the UI driver 38 of the client PC accesses the Language Monitor 32 (for example, using RPC (Remote Procedure Call)). Then, the UI driver 38 appears to be accessing the Language Monitor 32 of the client PC.

  As described above, since the client PC and the server PC 110 have the same Windows OS 10 installed, the Language Monitor 32 of the Windows OS print architecture can be used in common. For this reason, the access authority and communication error that are likely to occur in a module developed by a manufacturer are unlikely to occur. For the same reason, the affinity with OS10 is also high.

  Note that Point & Print also has RAW spools and EMF spools as spool formats, but in the case of RAW spools, there is no server-side rendering. This is because the RAW spool is a process of an application, so that the rendering location is limited.

  In other cases, the Language Monitor 32 is used as shown in FIG. 20 in any of the client side rendering of the RAW spool, the client side rendering of the EMF spool, and the server side rendering of the EMF spool.

10 OS
22 Notification Module Starter 25 Notification Module 30 Printer Driver 32 Language Monitor
38 UI driver 39 Drawing driver 43 Global memory 100 PC
110 Client 120 Server 200 Printer 500 Printing System

JP 2002-333968 A JP 2010-066876 A

Claims (14)

A program that causes an information processing device that operates based on a predetermined program to execute processing,
Displaying image data output setting conditions and receiving the setting conditions;
Before starting the operation of the image processing program, starting a notification program for displaying a notification screen using print data; a setting reception program for causing the information processing apparatus to execute;
Obtaining document data from an application, and converting the print data into print data based on the setting condition received by the setting receiving program;
Holding the print data in a print data holding program included in the predetermined program; an image processing program for causing the information processing apparatus to execute;
A notification program that causes the information processing apparatus to execute a step of acquiring the print data from the print data holding program and displaying the notification screen using the print data. The notification program accepts a setting for either continuing printing or canceling printing on the notification screen;
Outputting the setting to the print data holding program, causing the information processing apparatus to execute,
The image processing program, when the setting acquired from the print data holding program is print stop, stops outputting the print data,
The program according to claim 1. The notification program causes the information processing apparatus to execute a process of displaying an image of the print data output on paper on the notification screen.
The program according to claim 1. The notification program is
Based on the print data, the color information when the print data is printed and the number of output sheets are determined, the amount charged for printing is calculated, and the amount of money displayed on the notification screen is displayed. Let the information processing device execute
The program according to claim 1. The notification program is started by the setting reception program, and inquires the print data holding program whether or not the holding of the print data is completed;
When the holding of the print data is completed, the information processing apparatus executes the step of acquiring the print data from the print data holding program and displaying the notification screen using the print data.
The program according to claim 1. The predetermined program is a predetermined operating system;
The print data holding program is Language Monitor.
The program according to claim 1. Setting accepting means for displaying image data output setting conditions and receiving the setting conditions;
Image processing means for obtaining document data from an application and converting the print data into print data based on the setting conditions received by the setting receiving means;
A notification screen generating means for displaying a notification screen using the print data generated by the image processing means, and an information processing apparatus that operates based on a predetermined program,
An activation unit that activates the notification screen generation unit before the image processing unit starts operation;
Print data holding means for holding the print data output by the image processing means provided by the predetermined program;
The notification screen generation unit activated by the activation unit acquires the print data from the print data holding unit, and displays the notification screen using the acquired print data.
An information processing apparatus characterized by that. The notification screen generation unit receives a setting for either continuing printing or canceling printing on the notification screen, and outputs the setting to the print data holding unit.
The image processing unit cancels output of the print data when the setting acquired from the print data holding unit is print cancel;
The information processing apparatus according to claim 7. The notification screen generation means displays an image of the print data output on paper on the notification screen.
The information processing apparatus according to claim 7. The notification screen generation means includes
Based on the print data, determine the color information when the print data is printed, and the number of output sheets, calculate the amount charged for printing,
Displaying the amount on the notification screen;
The information processing apparatus according to claim 7. The notification screen generation means, after being activated by the setting accepting means, inquires of the print data holding means whether or not the holding of the print data is completed, and when the holding of the print data is completed, Obtaining the print data from the holding means and displaying the notification screen using the print data;
The information processing apparatus according to claim 7. The predetermined program is a predetermined operating system;
The print data holding means is Language Monitor.
The information processing apparatus according to claim 7. Setting accepting means for displaying image data output setting conditions and receiving the setting conditions;
Image processing means for obtaining document data from an application and converting the print data into print data based on the setting conditions received by the setting receiving means;
Notification screen generation means for generating a notification screen using the print data generated by the image processing means;
An activation unit that activates the notification screen generation unit before the image processing unit starts operation;
Print data holding means for holding the print data output by the image processing means, provided by a predetermined program,
The notification screen generation unit activated by the activation unit acquires the print data from the print data holding unit, and generates the notification screen using the acquired print data. In the first information processing apparatus that operates based on a predetermined program,
Displaying image data output setting conditions and receiving the setting conditions;
A step of starting a notification program for displaying a notification screen using print data before the image processing unit included in the second information processing apparatus operating based on a predetermined program starts the operation. A reception program,
Obtaining the print data from a print data holding program included in the predetermined program operating in the second information processing apparatus in the first information processing apparatus;
A step of displaying the notification screen using the acquired print data, and a program for executing the program,
Image processing means for acquiring document data created by an application operating on the first information processing apparatus and converting the document data into the print data based on the setting condition received by the setting receiving program;
A print data holding program for holding the print data created by the image processing means.

Images