Information processing device, control method, and program

Abstract

The aim is to enable the proper use of vendor-specific extensions even when printing using printer drivers that support printing devices from multiple vendors. [Solution] The printer driver communicates with the printing device using a predetermined printing protocol and obtains first attribute information related to printing from the printing device. It also generates a print job in accordance with the predetermined printing protocol based on the data received from the application and sends the generated print job to the extended application (S606). The extended application obtains attribute information in a different format from the first attribute information (S611). It then displays a UI related to print settings based at least on the second attribute information (S613). The extended application generates a print job to send to the printing device based on the settings made via the UI and the print job received from the driver.

Description

Technical Field

[0001] The present invention relates to an information processing apparatus, a control method, and a program that communicate with a printing apparatus.

Background Art

[0002] A configuration in which print data is transmitted to a printing apparatus using a printer driver is generally known. An operating system (OS), which is basic software, is installed in an information processing apparatus. The printer driver is configured according to a print architecture defined by the OS and is called by the OS to operate. A vendor that provides a printing apparatus provides a printer driver that conforms to the specifications of the OS. The OS and the printer driver cooperate to realize a function of performing printing using the output destination printing apparatus.

[0003] By the way, when using a version of Microsoft (registered trademark)'s Windows (registered trademark) prior to Windows 8 as the OS, the printer driver is configured with an architecture called a V3 printer driver.

[0004] Also, since security is emphasized in the V4 printer driver, the extensibility of the printer driver itself has decreased compared to the V3 printer driver. To compensate for such a decrease in extensibility, a vendor that provides a printing apparatus can provide a dedicated application for assisting the functions of the printer driver. This application is called UWP Device Apps (Universal Windows Platform Device Apps). UWP Device Apps can enhance the user experience when printing from a store application (UWP). In addition, a PrinterExtension, which is a print setting application for performing vendor-specific print settings, can be associated with the V4 printer driver.

[0005] Furthermore, a printer driver known as a universal printer driver is conventionally known for controlling multiple types of printing devices with different functions (Patent Document 1). This printer driver can display an operation screen suitable for each individual printing device, depending on the model and type.

[0006] Furthermore, there are plans to enable sending print data to printing devices without using a printer driver. For example, Ubuntu® 17.04 includes a mechanism for sending print data to IPP Everyware®-compatible printing devices as a default OS function. IPP Everyware is a set of standards that enable printing using various printing devices, and industry organizations are working to develop and promote these standards. [Prior art documents] [Patent Documents]

[0007] [Patent Document 1] Japanese Patent Publication No. 2013-187571 [Overview of the project] [Problems that the invention aims to solve]

[0008] Universal printer drivers, such as the one disclosed in Patent Document 1, are generally provided by each vendor. Therefore, a single universal printer driver could handle multiple types of printing devices with different functions sold by the same vendor. However, it was difficult to handle printing devices from different vendors with a single universal printer driver. This is because each vendor uses different communication methods, such as PDL (Page Description Language) or JDL (Job Description Language), to exchange print data, making it difficult to unify them. Furthermore, print settings also differ from vendor to vendor, or even similar settings may be interpreted differently, making it difficult to handle them all with a single universal printer driver.

[0009] As mentioned earlier, it is conceivable to provide common printer drivers and print clients using mechanisms compliant with IPP, such as IPP Wveryware. However, a problem with common printer drivers compliant with IPP is that they cannot utilize features provided independently by vendors.

[0010] The present invention has been made in view of at least one of the above-mentioned problems. One of the objectives of the present invention is to provide a mechanism that can appropriately utilize extended functions provided by printing devices from multiple vendors, even when printing is performed using a printer driver or print client that generates a print job conforming to a predetermined printing protocol. Another objective is to achieve both security and convenience by implementing the printer driver as a class driver conforming to a predetermined printing protocol, and implementing vendor-specific extensions as extension applications that run on a sandboxed virtual environment. Another objective is to enable printing that reflects vendor-specific extended functions through said extension applications. [Means for solving the problem]

[0011] To achieve at least one of the above objectives, the present invention provides an information processing device comprising a printer driver that communicates with a printing device using a predetermined printing protocol, and an extended application associated with the printer driver, wherein the printer driver comprises a first acquisition means for acquiring first attribute information related to printing from a printing device using the predetermined printing protocol, a generation means for generating a print job in accordance with the predetermined printing protocol based on data received from the application, and a transmission means for transmitting the generated print job to the extended application, and the extended application comprises a second acquisition means for acquiring the generated print job, a third acquisition means for acquiring second attribute information related to printing from the printing device, which is in a different format from the first attribute information, a display control means for displaying a user interface relating to print settings based at least on the second attribute information, and a generation means for generating a print job to transmit to the printing device based on settings made via the user interface and the print job generated by the printer driver. [Effects of the Invention]

[0012] One aspect of the present invention is that even when printing is performed using printer drivers or print clients that support printing devices from multiple vendors, vendor-specific extensions can be appropriately utilized. Another aspect of the present invention is that the driver is implemented as a class driver conforming to a predetermined printing protocol, and vendor-specific extensions are implemented by extension applications that operate in a sandboxed environment, thus achieving both security and convenience. Another aspect of the present invention is that by providing an extension application for a printer driver that generates print jobs conforming to a predetermined printing protocol, printing that reflects vendor-specific print settings can be performed via this application. [Brief explanation of the drawing]

[0013] [Figure 1] This is a diagram showing an example of a printing system. [Figure 2] It is a diagram showing an example of the hardware configuration of the client computer 100. [Figure 3] It is a diagram showing an example of the software configuration of the client computer 100. [Figure 4] It is a diagram showing an example of information regarding print settings. [Figure 5] It is a schematic diagram explaining an example of the processing procedure in the printing system. [Figure 6] It is a flowchart explaining an example of the control of the client computer 100. [Figure 7] It is a flowchart explaining an example of the control of the printer 200. [Figure 8] It is a diagram showing an example of a screen displayed on the display unit of the client computer 100. [Figure 9] It is a diagram showing an example of a screen displayed on the display unit of the client computer 100. [Figure 10] It is a schematic diagram explaining an example of the processing procedure in the printing system. [Figure 11] It is a flowchart explaining an example of the control of the client computer 100. [Figure 12] It is a flowchart explaining an example of the control of the client computer 100. [Figure 13] It is a schematic diagram for explaining a modification example. [Figure 14] It is a diagram for explaining an example of an extended setting in a modification example.

Mode for Carrying Out the Invention

[0014] Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings. Note that the following embodiments do not limit the invention according to the claims, and not all combinations of the features described in the embodiments are essential for the solution means of the invention.

[0015] <First Embodiment> First, the configuration of the printing system according to the present invention will be described using FIG. 1. The printing system according to the present embodiment includes a client computer 100 and printers 200a to 200c. On the network 300, the client computer 100 and the printers 200a to 200c are connected to each other so as to be communicable. Note that the form of communication between devices may be communication via a wireless network or communication via a wired network. Also, in the case of communication via a wireless network, it may be wireless communication via an access point compliant with IEEE802.11, or direct wireless communication such as Wi-Fi Direct (registered trademark). In the present embodiment, the above configuration will be described as an example of a printing system, but it is not limited thereto. It is only necessary that one or more communication devices and a printer are connected to each other so as to be communicable via a network.

[0016] In the present embodiment, single-function printers 200a to 200c will be described as an example of a printing device that receives a print job and prints an image on a sheet, but it is not limited thereto. A device such as an MFP (Multi Function Peripheral) having a printing function and a scanning function may be used.

[0017] In the present embodiment, for the sake of explanation, it is assumed that the printers 200a to 200c are manufactured by different vendors. The printers 200a to 200c can receive a print job conforming to the IPP (Internet Printing Protocol) from the client computer 100 or the like, and print an image on a sheet based on the print job.

[0018] Furthermore, printers 200a to 200c also have the ability to receive and interpret print jobs in formats other than IPP. For example, printer 200a can interpret print jobs containing PDL (Page Description Language) data conforming to the LIPS (Registered Trademark, LBP Image Processing System) format. In addition, printer 200a can interpret print jobs containing PDL data conforming to the PCL (Registered Trademark, Printer Command Language) format. Note that the LIPS format is also called the UFR (Registered Trademark, Ultra Fast Rendering) format. Printer 200b can interpret print jobs containing PDL data conforming to the PCL (Registered Trademark, Printer Command Language) format. On the other hand, it does not support LIPS (UFR) format print jobs. Printer 200c is an inkjet printer and can interpret print jobs conforming to ESC / P (Epson Standard Code for Printer). However, it does not support PCL or LIPS format print jobs. Thus, naturally, the types of PDL supported differ depending on the printer manufacturer's vendor. Furthermore, even with the same printer, there may be slight differences in supported functions depending on the type of PDL used. Note that the types of PDLs that each printer can interpret are just examples. Printers can interpret PDL formats such as PCL, LIPS, ESC / P, RPCS (Refined Printing Command Stream), PS (Post Script), and ART (Advanced Rendering Tools). They may also use formats such as SPDL2 (Sharp Printer Description Language 2). Furthermore, they may use formats derived from the aforementioned PDLs. Each printer is required to support at least one of the above-mentioned PDL formats, or PDL formats derived from the above-mentioned PDL formats.

[0019] Next, we will describe a client computer 100, which is an example of an information processing device. In this embodiment, the client computer 100 is shown as a PC (Personal Computer), but it is not limited to this. It may also be a tablet terminal or a wearable computer that incorporates a head-mounted display and a computer.

[0020] The client computer 100 can communicate with printers 200a to 200c on the network 300. The client computer 100 can also generate print jobs based on the data to be printed and send them to each printer.

[0021] The hardware configuration of client computer 100 will be explained using Figure 2. Figure 2 is a block diagram showing an example of the hardware configuration of client computer 100.

[0022] The CPU (Central Processing Unit) 101 is a processor that controls the operation of the entire control unit 120. The control unit 120 consists of memory, specifically ROM (Read Only Memory) 1021, RAM (Random Access Memory) 1022, and storage 105, and each part is connected by a system bus 107. The control unit 120 also includes interfaces (I / F) 103 and 104 for connecting input / output devices, and a communication I / F 106 for communicating with external devices via a network.

[0023] RAM1022 is volatile memory and is used as a temporary storage area for deploying various control programs stored in the work area, ROM1021, and storage105.

[0024] ROM 1021 is non-volatile memory and stores the computer's boot program and other data. Storage 105 is a large-capacity non-volatile flash memory or HDD (Hard Disk Drive) compared to RAM 1022. Storage 105 stores the OS (Operating System) 1053 for controlling the entire computer 100, and various application programs 1051 that run on OS 1053. It also stores a common printer driver 1054 that generates print jobs in accordance with predetermined printing protocols such as IPP, and device applications 1052a~b that work in conjunction with the common printer driver 1054 (details will be described later).

[0025] Various applications, such as application 1051 and device applications 1052a~b, can be installed on the computer 100 via CD-ROM, USB memory, or network 300.

[0026] The CPU 101 executes the OS program and various application programs deployed on the RAM 1022, and controls the computer 100. In this way, the hardware such as the CPU 101, ROM 1021, RAM 1022, and storage 105 constitute what is known as a computer.

[0027] In this example, the client computer 100 is configured so that a single CPU 101 executes each of the processes shown in the flowchart described later, but other configurations are also possible. For example, multiple processors can work together to execute each of the processes shown in the flowchart described later.

[0028] The input interface 103 connects the keyboard 108 and the pointing device 109 to the control unit 120. The keyboard 108 and the pointing device 109 function as reception units that receive user instructions. The reception units can detect the selection of display items such as keys displayed on the screen. The output interface 104 connects the monitor 110, which displays information, to the control unit 120. The monitor 110 functions as a display unit that displays information. If the client computer 100 is a tablet terminal or the like, information will be displayed to the user and operations will be accepted via a touch panel display that serves as both a reception unit and a display unit. In this case, the user can input desired operation instructions to the client computer 100 by performing touch operations using an object such as a finger.

[0029] Communication I / F106 is an interface for communicating with external devices such as printing equipment on network 300, or servers on the cloud.

[0030] <Software configuration of computer 100> Figure 3 shows an example of the software configuration of the client computer 100 in this embodiment. OS 1053 is system software that controls the entire computer 100. Here, as an example, it is assumed that an OS of Windows® 10 or later is installed.

[0031] OS1053 provides a printing architecture 10531 for printing using a printer driver. The printing architecture 10531 is a so-called V4 printing architecture that uses XPS format data as spool data and converts this spool data into print data (PDL) by the printer driver.

[0032] Incidentally, there are printer drivers that can be installed on a computer, known as universal printer drivers. Also, operating systems such as Ubuntu® 17.04 have a built-in mechanism for sending print data to IPP Everyware®-compatible printers as a default OS function. IPP Everyware is a set of standards that enable printing using various printers, and industry organizations are working to develop and promote these standards.

[0033] As mentioned earlier, universal printer drivers are generally provided by each vendor. Therefore, traditionally, one universal printer driver could handle multiple types of printers with different functions sold by the same vendor. However, it is difficult to handle printers from different vendors with a single universal printer driver. This is because each vendor uses different communication methods, such as PDL or JDL (Job Description Language), to exchange print jobs, making it difficult to unify them. Furthermore, print settings also differ from vendor to vendor, or even similar settings may be interpreted differently, making it difficult to handle them all with a single universal printer driver.

[0034] Therefore, it is assumed that providing a mechanism that allows printing to be performed without individually installing vendor-provided printer drivers in V3 or V4 format, even in environments such as Windows, would enhance user convenience.

[0035] In light of this, this embodiment implements a common printer driver in a Windows environment using a predetermined printing protocol mechanism. Hereafter, the case where the predetermined printing protocol is the commonly used IPP will be used as an example.

[0036] Now, let's consider the case where a common printer driver compliant with IPP is simply implemented. In this case, a print job containing IPP-compliant print attributes and an IPP-compliant PDL is generated and sent to the printer. In this case, there is a problem in that vendor-specific functions not defined in IPP (for example, stapleless binding functions that bind printed materials without using staples, or box saving functions that store print data in the printer's storage) cannot be used.

[0037] Therefore, in this embodiment, an extension application for utilizing vendor-specific functions can be called from a common printer driver compliant with IPP, thereby providing vendor-specific extension functions. The specific mechanism is described below.

[0038] Returning to the explanation of Figure 3, the client computer 100 has a common printer driver 1054 installed that supports printers from multiple vendors. This common printer driver 1054 may be a class driver built into the OS 1053 as a standard function, or it may be a universal printer driver separately installed by the user on the computer 100.

[0039] The printing architecture 10531 consists of a GDI-to-XPS conversion module 307, a common printer driver 1054, an OS standard printing UI unit 305, a print manager 318, and a device communication unit 319. It is also possible to install a printer driver different from the common printer driver (for example, a model-specific printer driver provided by a vendor).

[0040] <Printing process using common printer driver 1054> First, we will explain the printing process using the common printer driver 1054. Desktop applications 301 include "Win32 / 64 applications" and ".NET applications." UWP applications 302 are UWP (Universal Windows Platform) applications that run on OS 1053. UWP applications are applications distributed through the Windows Store and operate in a different execution environment than desktop applications 301 and the printing architecture 10531. UWP applications run in their own sandbox (virtual environment), and their access to system areas and available APIs is restricted. In other words, they have lower access privileges to resources within the device compared to desktop applications and device drivers. Therefore, they have the characteristic of being less likely to affect the system compared to desktop applications and driver programs.

[0041] These desktop apps 301 and UWP apps 302 can work with the printing architecture 10531 to print content (such as documents and images).

[0042] Desktop application 301 prints using GDI (Graphics Device Interface), a graphics component that generates print images for the printer. When printing using GDI, desktop application 301 sends GDI drawing data to the GDI-to-XPS conversion module 307, a module of OS1053. Module 307 converts the GDI drawing data into an XPS spool file. The converted XPS spool file is temporarily stored in area 306. On the other hand, when printing from UWP application 302, there are two methods: the UWP application itself generates the XPS file, and OS1053 generates the XPS file in response to drawing commands from the UWP application. In either case, the generated XPS file is transferred to area 306 and temporarily stored.

[0043] The user uses input devices such as a keyboard 108 or a pointing device 109, such as a touch panel / mouse, to perform printing operations from a desktop application 301 or a UWP application 302 displayed on the output device's monitor 110. Here, we will explain using the case of printing from a UWP application 302 as an example. Figure 8 is an example of the screen displayed when printing from a UWP application 302, and is an example of a settings screen (user interface) called the modern print dialog, provided by the OS 1053. When a print command is issued via the UWP application 302, the CPU 101 displays the print dialog on the monitor 110. The user can select the printer to use for printing by selecting area 801, or change the print settings by selecting each item in area 804. The user can also issue a print command using the print key 803. Here, we will explain using the case where the user has selected a printer that corresponds to the common printer driver 1054 as an example. Other setting keys 802 are used for detailed print settings. When the OS detects that the key has been selected, it activates the OS standard printing UI unit 305 and displays a print settings screen (user interface) in accordance with IPP (not shown).

[0044] When OS1053 detects a user operation to change the print settings, it calls the standard print settings unit 308 of the common printer driver 1054. The standard print settings unit 308 refers to the definition file corresponding to the selected printer from the standard print function definition file group 309. Based on the referenced definition file, it also creates standard setting data (303 and 304) that shows the current print settings and PrintCapabities that shows the printing capabilities of the selected printer.

[0045] The standard print function definition file is a definition file that indicates the capabilities of a printer, generated based on attribute information obtained from the printer, such as when searching for an IPP printer. Therefore, the standard print function definition file group 309 stores a separate file that is different for each printer.

[0046] Next, we will explain the generation of definition files. If a definition file corresponding to the selected printer is not stored in storage, the common printer driver 1054 queries the printer for capability information. The common printer driver 1054 queries the printer for capability information via the print manager 318 and the device communication unit 319. In addition to the print job control function described later, the print manager 318 can search for printers that support IPP and obtain printer capabilities. Specifically, the acquisition of printer capabilities is performed by printer attribute request operations (Get-Printer-Attributes Operations) defined in RFC2911. First, the print manager 318 sends a Get-Printer-Attributes Request to the printer 200. In response to this request, attribute information of the printer 200 is obtained. The printer capability information obtained by the printer attribute request operation is, for example, capability information for standard print settings such as whether "double-sided printing" and "color printing" are possible. Here, the capabilities (attributes) that can be obtained by the printer attribute request operation are support information regarding attributes defined in IPP. Therefore, vendor-specific functional information (such as stapleless binding or box printing) cannot be obtained through the IPP printer attribute request operation. The obtained attribute information is transferred to the standard print setting unit 308. The standard print setting unit 308 generates a definition file based on the attribute information obtained using IPP and stores it in the storage 105.

[0047] Returning to the explanation of print settings, the desktop app 301 uses the binary DEVMODE303 as standard setting data that indicates the current print settings. The UWP app 302 uses PrintTicket304, which is written in the markup language XML. This DEVMODE303 or PrintTicket304 is standard setting data that holds the print settings that should be reflected in the print job in accordance with IPP.

[0048] Figures 4(A) and 4(B) illustrate PrintCapabilies and PrintTicket. Both are XML files conforming to the rules defined in the printing architecture, and file 400, shown as an example in Figure 4(A), is an example of PrintCapabilies. File 400 lists the available print settings items and the combinations of configurable values ​​for those print settings items. User interfaces for print settings provided by applications and the OS can configure the print settings screen based on file 400. Note that only some settings are shown as examples here due to space limitations, but this is not an exhaustive list. Other print settings items and post-processing settings items based on attribute information compliant with IPP may also be included.

[0049] On the other hand, file 401, illustrated in Figure 4(B), is an example of PrintTicket304, which lists the current print settings. The user interface for print settings provided by application 1051 or OS1053 allows the print settings to be changed by rewriting PrintTicket304.

[0050] Furthermore, the OS standard printing UI unit 305 provides a screen (user interface) for print settings based on the information described in PrintCapabilities corresponding to the selected printer.

[0051] When the OS or application detects that a user has issued a print command, it generates an XPS spool file. The generated XPS spool file is passed to the standard print processing unit 312. The standard print processing unit 312 renders the received XPS spool file and converts it into PDL data compliant with IPP. PDL data compliant with IPP is, for example, data in PDF (Portable Document Format) or PWG-Raster format.

[0052] Furthermore, the standard print processing unit 312 generates print attribute information in accordance with IPP based on the settings specified in PrintTicket 304 included in the XPS spool file.

[0053] PDL data and print attribute information conforming to IPP are managed by the print manager 318, which manages the print processing schedule. The print manager 318 generates IPP-compliant print jobs based on the PDL data and IPP-compliant print attribute information, and registers the generated print jobs in a queue. When the printer 200 is ready to print, it sends the IPP-compliant print jobs via the device communication unit 319 in the order they were registered in the queue. In this way, the main role of the common printer driver 1054 is to convert print data from applications into IPP-compliant PDL data.

[0054] The above process can only handle the capabilities specified in the IPP specifications and cannot support the various functions provided by printers 200a to c. Therefore, in this embodiment, the device application 1052, which is an extension application, uses a different communication method and obtains detailed capability information to enable it to handle extended print settings other than the standard print settings.

[0055] Device applications 1052a and 1052b are separate applications from the common printer driver 1054 and run on the UWP platform. These applications are based on printing using the IPP-based common printer driver, but also allow for more flexible use of the printer 200's features as needed. These applications run in a sandboxed UWP execution environment. Therefore, even if the application hangs or encounters errors, the impact on the overall system is minimized.

[0056] This example illustrates the case where device application 1052a is installed as the device application for printer 200a. It also illustrates the case where device application 1052b is installed as the device application for printer 200b. On the other hand, no device application is installed for printer 200c.

[0057] Therefore, if a user selects printer 200c as the output destination for the common printer driver, the extended print settings process is skipped, and printing compliant with IPP is performed. Furthermore, a certain number of users do not require extended print settings via extended applications. Considering this, the common printer driver 1054 stores a setting in the setting storage unit 320 for each printer, indicating whether or not to activate extended print settings. This setting can be changed by the user.

[0058] The standard printing processing unit 312 determines whether or not to launch the device application based on the installation status of the extended application and the settings stored in the setting storage unit 320.

[0059] The device application 1052 consists of a print-start application unit 10521, an extended print settings unit 10522, a print job generation unit 10525, and a device application communication unit 10524. The print-start application unit 10521 is a module that is called when printing and manages the extended print settings unit 10522, the device application communication unit 10524, and the print job generation unit 10525. The device application 1052 is linked to the printer. The device application 1052 can provide functions such as displaying a preview immediately after printing and displaying a user interface that prompts changes to print settings. In this embodiment, it is assumed that the screen provided by the device application is called after PDL conversion is performed in the standard print processing unit 312, but it is not limited to this. The extended print settings unit 10522 has a function to display an extended user interface that allows for more detailed print settings compared to print settings compliant with IPP. The device application communication unit 10524 has a function for each module of the device application 1052 to communicate with the printer 200. The device application communication unit 10524 acquires information about the printer 200 using a specific communication method or a specific control method. A specific communication method could be, for example, the WSD (Web Services for Devices) protocol or SNMP (Simple Network Management Protocol). Alternatively, a vendor-specific protocol may be used. Information about the printer can also be acquired using control commands defined in a job control language or printer control language. For example, information may be requested from the printer using commands defined in PJL (Printer Job Language), PostScript, or CPCA (Common Peripheral Controlling Architecture). Furthermore, information can also be acquired from the printer using NPAP (Network Printing Alliance Protocol).

[0060] The print job generation unit 10525 has the function of reflecting PDL conversion processing and extended print settings in the print job.

[0061] For example, the print job generation unit 10525 of device application 1052a has a function to convert PDL data included in a print job conforming to IPP into LIPS format (UFR format). Similarly, the print job generation unit 10525 of device application 1052b has a function to convert PDL data included in a print job conforming to IPP into PCL format. Note that the PDL format converted by device application 1052 is just an example and is not limited to this. It may also be converted to PCL, RPCS, PS, ART, SPDL2 format, etc. Note that the PDL data conversion process is not always necessary. For example, if printers 200a~c support direct PDF printing, the conversion process can be skipped.

[0062] Next, we will explain the overview of data processing when printing using Figure 5. Figure 5 is a schematic diagram illustrating the data flow when a user performs a print job.

[0063] First, application 1051 uses the standard print settings unit 308 to obtain standard setting data set in PrintTicket format or DEVMODE format. The standard print settings unit 308 obtains the definition file corresponding to the selected printer from the definition file group 309 and generates standard setting data indicating the current print settings based on that definition file. The standard setting data is modified as needed via application 1051 or a screen (user interface) for changing print settings displayed by the OS. When the application receives a print start command, it passes the standard settings obtained by the standard print settings unit 308 and the XPS spool file to the standard print processing unit 312.

[0064] The standard print processing unit 312 converts the received XPS spool file into a PDL that conforms to IPP. It also generates print attributes that conform to IPP based on standard setting data indicating the current print settings. Subsequently, the common printer 150 generates a print job based on the converted PDL and IPP attribute information and passes it to the device application 1052. If it is determined that the device application will not be used, the IPP-compliant print job is sent directly to the printer, as indicated by the dashed line.

[0065] Next, the device application 1052 generates an extended settings screen (user interface) that includes setting items not defined in IPP, based on capability information indicating extended settings obtained from the printer 200, and displays it on the monitor 110.

[0066] For the purpose of this explanation, we will use device application 1052a, which is compatible with printer 200a, as an example.

[0067] Figure 8 shows an example of the print settings screen displayed on the monitor 110 by the device application 1052a. 901 shows an example of standard print settings, and 902 shows an example of extended print settings based on device capability information. The extended print settings displayed in 902, "Box Printing," "Secure Print," and "Stapleless Binding," are examples of print settings that operate according to each vendor's unique specifications. Users can configure print settings based on specifications not defined by IPP through the extended settings screen. The OK key 903 is used to start printing and apply the print settings.

[0068] When device application 1052a detects that the OK key 903 has been selected, it generates extended settings, which are job attributes to be assigned to the print job, based on the settings made via the extended settings screen. Subsequently, device application 1052a sends the print job, including the PDL and job attributes, to printer 200a. In this case, for example, the job attributes included in the print job can be expressed using CPCA commands, and the PDL data can be expressed in LIPS format (UFR format).

[0069] Finally, the printer 200 receives print jobs that comply with IPP standards or vendor-specific formats, and prints images onto sheets based on those print jobs.

[0070] Next, we will explain the specific control methods using the flowcharts in Figures 6 and 7.

[0071] <Control of client computer 100> First, the operation of the client computer 100 will be explained. Figure 6 is a flowchart showing the control of the client computer 100. Each operation (step) shown in the flowchart of Figure 6 is realized by the CPU 101 reading the program for realizing each control module stored in the ROM 1021 or storage 105 into the RAM 1022 and executing it. Note that each process shown in the flowchart is realized through the cooperation of modules and software components of application 1051, OS 1053, and device application 1052. In addition, some processes such as data transmission and information input / output are realized in cooperation with each I / F. To clarify the program that is the main entity that realizes each process, software components and applications will be described as the subject.

[0072] The flowchart in Figure 6 shows the processes that are executed when a printer corresponding to the common printer driver 1054 is specified as the printer to be used, and when a print command is received from the user.

[0073] In step S601, application 1051 detects that the user has pressed the print key 803 of the common print dialog. In step S602, application 1051 generates drawing data and passes the drawing data to OS 1053.

[0074] In step S603, OS1053 generates an XPS spool file. Note that in the case of printing from the desktop application 301, the OS generates the XPS spool file using the GDI-to-XPS conversion module 307.

[0075] In step S604, the print architecture 10531 and the common printer driver 1054 work together to generate a print job. The standard print processing unit 312 converts the XPS spool file into a PDL that conforms to IPP. It also generates IPP-compliant print attributes based on standard settings that indicate the print settings to be set for the job. The print manager 318 then generates a print job based on the PDL and the IPP-compliant print attributes.

[0076] Next, in step S605, OS1053 determines whether or not to use a device application. Specifically, it first determines whether or not a device application exists for the printer selected as the output destination (hereinafter referred to as the selected printer). If no device application exists for the selected printer, the process proceeds to S616. On the other hand, if a device application exists for the selected printer, OS1053 further refers to the extended application setting storage unit 320 and determines whether or not to launch the device application for the selected printer. Specifically, it refers to the settings for each printer stored in the extended application setting storage unit 320 based on the ID of the selected printer. If the setting referred to based on the ID indicates a setting that does not launch the device application, the process proceeds to S616. On the other hand, if the setting referred to based on the ID indicates a setting that launches the device application, the process proceeds to S606.

[0077] In S616, OS1053 sends a print job conforming to IPP to the selected printer. Once the transmission is complete, the series of processes ends.

[0078] Meanwhile, in step S606, the OS 1053 launches the device application 1052 corresponding to the selected printer and passes a print job in accordance with IPP to the device application 1052. At this time, information to uniquely identify the selected printer and information to communicate with the selected printer (e.g., an IP address) are also passed.

[0079] In step S607, the print-start application unit 10521 of the device application 1052 receives information about the print job and selected printer that has been passed to the OS 1053. In step S608, the print-start application unit 10521 of the device application 1052 analyzes the print job.

[0080] In step S609, the print-start application unit 10521 of the device application 1052 determines whether the capability information of the selected printer is stored (i.e., whether the extended capabilities have been acquired). If the capability information of the selected printer is stored, the process proceeds to S613; otherwise, the process proceeds to S610.

[0081] In step S610, the device application communication unit 10524 queries the selected printer 200 for capability information. The device application communication unit 10524 of the device application 1052 requests capability information from the selected printer 200 using the specific communication method and specific control commands described above. In step S611, the device application communication unit 10524 receives device capability information as a response to the request sent in S610. It also stores the received capability information and the identifier of the selected printer in a shared storage area accessible from the device application 1052. This process makes it possible to omit the process of obtaining device capability information from the next time onward. The device capability information stored here is assumed to include more detailed setting items than the attribute information (capability information) that can be obtained by the IPP's printer attribute request operation (Get-Printer-Attributes Operations).

[0082] Next, in step S613, the extended print settings unit 10522 of the device application 1052 displays the extended print settings UI exemplified in Figure 9, based on the analysis results of the print job and the device capability information.

[0083] In step S614, the extended print settings unit 10522 of the device application 1052 receives a user instruction to change the print settings. As illustrated in Figure 9, the extended print settings screen (UI) allows setting print settings 902 that are not defined in IPP.

[0084] In step S615, the print job generation unit 10525 of the device application 1052 generates a print job converted into a command that the selected printer can receive, based on the extended print settings. For example, if the selected printer is printer 200a and the device application is 1052a, it generates a print job with the job attribute defined as CAPA and the PDL converted to LIPS(UFR). Alternatively, if the selected printer is printer 200b and the device application is 1052b, it generates a print job with the job attribute defined as JPL and the PDL converted to PCL. In S617, the device application communication unit 10524 sends the print job generated in S615 to the selected printer. The device application communication unit 10524 connects directly to printer 200 and performs job control using the WSD protocol or a vendor-specific protocol to execute printing.

[0085] In this embodiment, the device application communication unit 10524 of the device application 1052 directly sends a print job to the printer 200, but this is not the only example. For example, the print job may be sent via the print manager 318 and device communication unit 319 provided by the OS. In this case, no PDL conversion is performed, and only the print attributes are rewritten to include vendor extensions. That is, the print job generation unit 10525 does not convert the PDL received from the OS, but passes it through and generates a print job that includes string information and binary data indicating the extended print settings. The converted print job is then resubmitted to the print manager 318 and sent to the printer 200.

[0086] <Controlling Printer 200> Next, we will explain the control of printer 200. Figure 7 is a flowchart of the control of printer 200. Each operation (step) shown in the flowchart is realized by the printer's processor executing a program to implement each control module stored in memory. The flowchart in Figure 7 is assumed to be executed in response to printer 200 being started up.

[0087] In step S701, the printer 200's processor determines whether or not it has received a request to acquire capability information from an external device. If it has received a request to acquire capability information from an external device, it proceeds to S702; otherwise, it proceeds to S703. In step S702, the printer 200's processor returns information indicating the device's capabilities as a response to the request. Here, if the acquisition request is an IPP Get-Printer-Attributes request, it returns attribute information indicating the capabilities usable with IPP. On the other hand, if the acquisition request is from a device application as described in S610 of Figure 6, it returns device capability information indicating detailed capabilities, compared with the attribute information indicating the capabilities usable with IPP.

[0088] Next, in step S704, the printer 200's processor determines whether or not it has received a print job from an external device. If it has received a print job from an external device, it proceeds to S705; otherwise, it proceeds to S703.

[0089] In step S703, the printer 200's processor determines whether or not it has received a shutdown command. If it has received a shutdown command, it terminates the series of processes. On the other hand, if it has not received a shutdown command, it returns to the process in S701 and waits for requests or print jobs to be sent from an external device.

[0090] As described above, in this embodiment, even when printing is performed using a printer driver or print client that generates print jobs in accordance with a predetermined printing protocol, the extended functions provided by printing devices from multiple vendors can be appropriately utilized. Furthermore, the printer driver is implemented as a class driver in accordance with a predetermined printing protocol, and vendor-specific extensions can be implemented as extension applications that operate in a sandboxed environment. Therefore, both security and convenience can be achieved. In addition, the extension application enables printing that utilizes the vendor's proprietary assets (e.g., vendor-specific PDLs and JDLs). Moreover, if an extension application is not provided, or if the user does not wish to configure print settings using an extension application, the extension application can be deliberately not launched. Therefore, it is possible to accommodate both users who prefer simple printing and users who want to configure detailed print settings.

[0091] <Second Embodiment> In the first embodiment, an example was given in which the print settings are extended using the device application 1052 after generating a PDL with the common printer driver 1054. In the second embodiment, a mechanism is provided that allows print settings to be made using the vendor's own print settings screen even before issuing a print command.

[0092] Note that the hardware and software configurations in the second embodiment are the same as those in the first embodiment and are therefore omitted.

[0093] First, an overview of the data processing when printing is performed in the second embodiment will be explained using Figure 10. Figure 10 is a schematic diagram illustrating the data flow when a user performs printing.

[0094] Application 1051, similar to the first embodiment, obtains standard setting data using the OS standard print setting unit 208.

[0095] When the "Other Settings" key 802 is pressed to perform detailed printing from a print dialog called from application 1051, the OS print architecture 10531 launches the corresponding device application.

[0096] The device application 1052, launched by the OS, generates extended settings based on capability information obtained from the selected printer. The device application 1052 also uses the standard setting data (PrintTicket) passed from the OS standard print setting unit 208 and the extended settings obtained from the capability information of the printer 200 to display a screen (user interface) that allows users to configure print settings equivalent to those shown in Figure 9. This print setting screen can also display illustrations indicating the format of the output based on the print conditions. These illustrations are generated as needed each time the user changes the print settings, notifying the user of what the output will look like. Furthermore, users can register their favorite print settings via this screen. Favorite print settings are stored in the shared data area of ​​the device application 1052. The user can select a display item from a list (not shown) to recall their favorite print settings and apply them to the print settings.

[0097] When the device app 1052 detects that the user has changed the print settings and selected the OK key, it stores the extended settings information in a shared data area owned by the device app 1052 and passes the standard settings to the OS standard print settings unit 208. Since the OS standard print settings unit 208 is unaware of the extended settings information that the printer 200 can provide, it will treat the passed extended settings information as an unknown setting and will not be able to control it correctly. Therefore, the device app 1052 temporarily holds the extended settings in the shared data area. When printing, the device app 1052, which is launched as a separate process, reads the extended settings held in the shared data area, thereby providing the extended print settings function without requiring the OS 1053 to control the extended settings.

[0098] The specific control will be explained using the flowcharts in Figures 11 and 12. Figures 11 and 12 are flowcharts showing the control of the client computer 100. Each operation (step) shown in the flowchart in Figure 6 is realized by the CPU 101 reading the program for realizing each control module stored in ROM 1021 or storage 105 into RAM 1022 and executing it. Note that the flowchart in Figure 11 is executed in response to a user operation indicating the intention to print via the user interface provided by application 1051.

[0099] In step S1101, application 1051 accepts the selection of a key to indicate the intention to print. In step S1102, application 1051 displays a common print dialog as illustrated in Figure 8. In step S1103, application S1103 accepts the selection of a key for detailed printing. The key for detailed printing is, for example, the "Other Printing" key 802. Upon receiving confirmation that this key has been pressed, application 1051 sends information identifying the printer driver and printer, along with a request for the detailed print screen, to OS 1053.

[0100] In step S1104, the OS1053 determines whether to use a device application for the pre-print settings based on the received printer driver and information identifying the selected printer. If there is no device application corresponding to the selected printer, the process proceeds to S1105. On the other hand, if there is a device application corresponding to the selected printer, the OS1053 further determines whether to launch the device application based on the extended application setting storage unit 320. This determination is the same as that made in S605, so the explanation is omitted. If it is determined that the device application should be launched, the process proceeds to S1108; if it is determined that it should not be launched, the process proceeds to S1105.

[0101] In step S1105, OS1053 displays the OS's standard print settings screen based on PrintCapablities and PrintTicket. On this settings screen, print settings can be configured based on attributes obtained by IPP. If detailed print settings are instructed from a desktop application, an API that converts between DEVMODE and PrintTicket will be used to convert them to PrintTicket and interpret the current print settings.

[0102] In step S1106, OS1053 receives a user instruction to change the print settings. In step S1107, OS1053 updates the standard setting data (DEVMODE or PrintTikect) from S1105. Once the update is complete, the process proceeds to S1117.

[0103] Meanwhile, in step S1108, OS1053 launches the device application corresponding to the selected printer and passes the print settings data (standard settings data) to be set for the print job to the device application. If the standard settings data is written in DEVMODE, the data converted to PrintTicket is passed instead.

[0104] In step S1109, the launched device application receives the print settings information described in the PrintTicket. In steps S1110 to S1112, the same process for acquiring extended settings as in steps S609 to S611 of the first embodiment is performed.

[0105] In step S1113, the device application displays the extended print settings UI based on the received print settings information and the device's capabilities. In step S1114, the device application accepts a print setting change instruction based on user operation. In step S1115, the device application updates the PrintTicket, which contains the print settings information. Subsequently, in S1116, the PrintTicket, including the extended settings updated in S1115, is temporarily saved to a shared area accessible from the device application. Once the process in S1106 is complete, the process proceeds to S1117. Note that the device application returns standard setting data, deliberately excluding the extended settings, as print attribute information to the OS.

[0106] In step S1117, application 1051 redisplays the common print dialog based on the standard settings data updated by the OS standard function or device application 1052. In step S1118, application 1051 accepts a selection operation for the print button in the common print dialog. Once the selection operation is accepted, the series of processes related to print settings are completed. Subsequently, the print process shown in Figure 12 is performed.

[0107] Figure 12 is a flowchart that is executed in place of the flowchart in Figure 6 in the first embodiment. The difference from Figure 6 is that the process in S1301 is executed instead of the process in S613.

[0108] Steps S601 to S611 are the same as in the first embodiment and are therefore omitted. Note that the device application process launched at S606 and the device application process launched at S1108 are separate processes. Therefore, PrintTickets, including extended settings, are exchanged via a common storage area accessible to the device application.

[0109] In S1301, the device application 1052 displays an extended print settings UI based on the attributes of the print job according to the received IPP and the PrintTicket containing the extended settings stored in a storage area accessible to the device application 1052. The extended print settings UI displayed here may also include display items for calling up favorite settings stored in the shared data area of ​​the device application 1052. In this case, the user will be able to use pre-registered favorite settings even on the print settings screen displayed after the print command. Once the display is complete, the process proceeds to S614. The subsequent processing is the same as in the first embodiment.

[0110] As described above, this embodiment offers the advantage of being able to handle pre-configurations before starting printing.

[0111] <Variation> In the second embodiment, an example was given of storing extended settings in a shared data area, but the method of passing extended settings to the device application is not limited to this. For example, if a vendor-extendable area (hereinafter referred to as the vendor extension area) is defined for the standard settings in accordance with IPP, it is possible to perform the same processing as in the second embodiment using that area. This processing will be explained using the schematic diagram in Figure 13.

[0112] First, application 1051 uses the standard print settings unit 308 to obtain standard setting data, which is information compliant with IPP. When OS 1053 receives a detailed print instruction via the print dialog, it launches device application 1052. Device application 1052 uses the standard setting data (PrintTicket) passed from the OS standard print settings unit 208 and the extended settings obtained from the capability information acquired from printer 200 to display the extended settings UI exemplified in Figure 9. When the user presses the OK button in Figure 9, device application 1052 writes vendor extension information to PrintTicket. For example, as shown in 1401 in Figure 14, it writes a string representing the extended settings available to printer 200 and passes it to OS 1053. The vendor extension area is written according to the specifications defined in IPP. Therefore, the data can be handled appropriately even by the standard printer driver 1054 that complies with IPP. The standard print processing unit 312 directly records the vendor extension information described in the PrintTicket into the attribute that indicates the vendor extension area of ​​the print job in accordance with IPP. Therefore, the extended setting information described in the vendor extension area can be transmitted to the device application 1052 that operates during printing, and this information can be used to provide an extended setting change function.

[0113] Another variation involves not using vendor extension areas, etc. For example, the standard print processing unit 312 and the print manager 318 generate an IPP-compliant print job from the PrintTicket that includes only IPP-compliant attributes. On the other hand, when the device application is launched, the PrintTicket containing the extended settings exemplified in Figure 14, in addition to the IPP-compliant print job, is passed to the device application. In this case, the device application can discard the IPP-compliant print settings and display the extended UI based on the received PrintTicket and the device capability information it has independently acquired.

[0114] Furthermore, as a variation of the second embodiment, if the device app 1052 accepts an extended print setting process before printing starts, it is also possible to control the system to skip the setting process (S1311 and S1312) performed by the extended print setting UI after the print command is issued.

[0115] <Other Embodiments> The present invention can also be realized by supplying a program that implements one or more of the functions of each of the embodiments described above to a system or device via a network or storage medium, and by having one or more processors in the computer of that system or device read and execute the program. It can also be realized by a circuit (e.g., an ASIC or FPGA) that implements one or more functions. [Explanation of Symbols]

[0116] 100 client computers 200 Printing device 101 CPU 1054 Common Printer Driver 1053 OS

Claims

[Claim 1] An information processing device having a printer driver that communicates with a printing device using a predetermined printing protocol, and an extended application related to the printer driver, The aforementioned printer driver A first acquisition means for acquiring first attribute information related to printing from a printing device using the predetermined printing protocol, A generation means that generates a print job in accordance with the predetermined print protocol based on data received from an application, A transmission means for sending the generated print job to the extended application, It has, The aforementioned extension application is A second acquisition means for acquiring the generated print job, A third acquisition means for acquiring second attribute information related to printing, which is in a different format from the first attribute information, from the printing apparatus, A display control means that displays a user interface relating to print settings based at least on the second attribute information, A generation means that generates a print job to send to the printing device based on the settings made via the user interface and the print job generated by the printer driver, An information processing device characterized by having the following features.

Images