Information processing apparatus and method using a printer driver, obtains first print settings information supports the internet printing protocol (IPP) and further obtains second print settings that does not support the internet printing protocol (IPP) from printer for printing

A printer driver communicates with a printer using a predetermined print protocol to obtain first attribute information related to printing from the printer. The print driver generates a print job conforming to the predetermined print protocol based on data received from an application and transmits the generated print job to the extension application (S606). The extension application obtains attribute information in a different form from the first attribute information (S611). The extension application displays a user interface (UI) for print settings based on at least the second attribute information (S613). The extension application generates a print job to be transmitted to the printer based on settings made via the UI and the print job received from the printer driver.

BACKGROUND OF THE INVENTION

The present invention relates to an information processing apparatus that communicates with a printer, a control method, and a storage medium.

A configuration for transmitting print data to a printer using a printer driver is generally known. The information processing apparatus is loaded with an operating system (OS), which is fundamental software. The printer driver is configured according to a print architecture defined by the OS and is called up by the OS to operate. A vendor that provides a printer provides a printer driver conforming to the specifications of the OS. The OS and the printer driver cooperate to achieve the function of printing using the output target printer.

In using a version prior to Windows® 8 of Microsoft® as the OS, the printer driver is formed of an architecture called “V3 printer driver”.

In Windows 8.1 or later, an architecture called “V4 printer driver” has appeared. Since the V4 printer driver places great importance on security, the scalability of the printer driver itself is lower than that of the V3 printer driver. To compensate for such a decrease in scalability, vendors that provide printers can provide dedicated applications for assisting the function of the printer driver. These applications are called Universal Windows Platform Device Apps (UWP Device Apps). The UWP Device Apps can enhance user experience in printing via store applications (UWPs). The V4 printer driver can be linked to Printer Extension, which is a print setting application for performing vendor-unique print settings.

A printer driver called “universal printer driver” is known as a printer driver for controlling a plurality of types of printer with different functions (Japanese Patent Application Laid-Open No. 2013-187571). The printer driver can display an operating screen suitable for an individual printer by type or model.

Another conceivable method is transmitting print data to a printer without using a printer driver. For example, Ubuntu® 17.04 has, as a default function of the OS, a scheme for transmitting print data to a printer conforming to IPP Everyware®. IPP Everyware is a series of standards that enables printing using various printers, for which formulation and popularization are being performed by an industry organization or the like.

The universal printer driver as disclosed in Japanese Patent Application Laid-Open No. 2013-187571 is generally provided vendor by vendor. This allows a plurality of types of printer with different functions sold by the same vendor can be supported by a single universal printer driver. However, it is difficult to support printers of different vendors with a single universal printer driver. This is because communication of print data is performed using different communication methods, page description languages (PDLs) and job description languages (JDLs), vendor by vendor, making it difficult to unify the print drivers. Another reason is that print setting items differ for each vendor, or even similar setting items are differently interpreted, which makes it difficult to support them using a single universal printer driver.

A conceivable method is providing a common printer driver or print client using a scheme conforming to the Internet Printing Protocol (IPP) typified by IPP Everyware, as described above. However, this has a problem in that functions that are uniquely provided by the vendors cannot be used with the common printer driver conforming to the IPP.

SUMMARY OF THE INVENTION

The present invention is made in view of at least one of the above problems. An object of the present invention is to provide a scheme for appropriately using extended capabilities provided by printers of a plurality of vendors even for printing using a printer driver or a print client that generates a print job conforming to a predetermined print protocol. Another object is to achieve both of security and convenience by implementing the printer driver as a class driver conforming to a predetermined print protocol and by implementing extension by vendor using an extension application operating on a sandboxed virtual environment. A still another object is to enable printing that reflects extension capabilities of each vendor using the extension application.

An information processing apparatus of the present invention for achieving at least one of the above objects is an information processing apparatus including a printer driver that communicates with a printer using a predetermined print protocol and an extension application related to the printer driver. The printer driver includes first acquisition means configured to obtain first attribute information related to printing from the printer using the predetermined print protocol, generation means configured to generate a print job conforming to the predetermined print protocol based on data received from the application, and transmission means configured to transmit the generated print job to the extension application. The extension application includes second acquisition means configured to obtain the generated print job, third acquisition means configured to obtain second attribute information related to printing from the printer, the attribute information being in a different form from the first attribute information, display control means configured to display a user interface for print settings based on at least the second attribute information, and generation means configured to generate a print job to be transmitted to the printer based on settings made via the user interface and the print job generated by the printer driver.

DESCRIPTION OF THE EMBODIMENTS

Embodiments of the present invention will be described hereinbelow with reference to the drawings. The following embodiments do not necessarily limit the present invention. Not all combinations of the features described in the present embodiments are essential for the solution of the present invention.

First Embodiment

Referring first toFIG.1, the configuration of a printing system according to the present invention will be described. The printing system according to present embodiment includes a client computer100and printers200ato200c. The client computer100and the printers200ato200care connected on a network300so as to communicate with each other. The communication among the devices may be a communication via a wireless network or a communication via a wired network. The communication via a wireless network may be a wireless communication via an access point conforming to IEEE802.11 or a direct wireless communication, such as Wi-Fi Direct®. In the present embodiment, the above configuration is described as an example of the printing system. However, this is not intended to limit the present invention. One or more communication apparatuses and printing apparatuses need only be communicably connected via a network.

In the present embodiment, single-function printers200ato200care described as an example of a printer that receives a print job and print images on a sheet. However, this is not intended to limit the present invention. The printer may be a multi-function peripheral (MFP) having both of a printing function and a scanning function.

In the present embodiment, the printers200ato200care manufactured by different vendors for illustrative purposes. The printers200ato200ccan receive a print job conforming to Internet Printing Protocol (IPP) from the client computer100or the like and can print images on a sheet on the basis of the print job.

The printers200ato200calso have a function of receiving a print job of a different format from that of the IPP and interpreting it. For example, the printer200acan interpret a print job including page description language (PDL) data conforming to a laser-beam-printer (LBP) image processing system (LIPS®) format. Furthermore, the printer200acan interpret a print job containing PDL data conforming to a Printer Command Language (PCL®) format. The LIPS format is also referred to as Ultra Fast Rendering (UFR®) format. The printer200bcan interpret a print job containing PDL data conforming to Printer Command Language (PCL®) format. However, the printer200bdoes not support a print job of the LIPS (UFR) format. The printer200cis an inkjet printer and can interpret a print job conforming to Epson Standard Code for Printer (ESC/P). However, the printer200cdoes not support a print job of the PCL format and the LIPS format. Thus, when the vendors which are the manufacturers of the printers differ, the kinds of support PDL also differ. Even the same printers have a little difference in support functions, depending on the type of PDL used. The type of PDL that the individual printers can interpret is given for mere illustrative purposes. The formats of the PDL that the printer can interpret may be PCL, LIPS, ESC/P, Refined Printing Command Stream (RPCS), Post Script (PS), and Advanced Rendering Tools (ART). The formats may include Sharp Printer Description Language2 (SPDL2) format. The formats may also include a format derived on the basis of the PDL described above. Each printer supports at least one of the PDL formats derived on the basis of the above PDL format.

Next, the client computer100, which is one example of the information processing apparatus, will be described. In the present embodiment, the client computer100is a personal computer (PC). However, this is given for mere illustrative purposes. The client computer100may be a terminal, such as a tablet terminal or a wearable computer in which a head-mounted display and a computer are installed.

The client computer100can communicate with the printers200ato200con the network300. The client computer100can generate a print job on the basis of print target data and transmit the print job to each printer.

The hardware configuration of the client computer100will be described with reference toFIG.2.FIG.2is a block diagram illustrating an example of the hardware configuration of the client computer100.

A central processing unit (CPU)101is a processor that controls the overall operation of a control unit120. The control unit120includes a read only memory (ROM)1021and a random access memory (RAM)1022, which are memories, and a storage105, which are connected via a system bus107. The control unit120further includes interfaces (I/Fs)103and104for connecting input/output devices and a communication I/F106for communicating with an external device over a network.

The RAM1022is a volatile memory, which is used as a temporary storage area in which various control programs stored in a work area, the ROM1021, and the storage105are to be expanded.

The ROM1021is a nonvolatile memory, in which a computer boot program and so on are stored. Examples of the storage105include a nonvolatile flash memory and a hard disk drive (HDD) with a larger capacity than that of the RAM1022. The storage105stores an operating system (OS)1053for controlling the entire computer100and programs of various applications1051that operate on the OS1053. The storage105also stores a common printer driver1054that generates a print job conforming to a predetermined print protocol, such as the IPP, and programs of device apps1052ato1052bthat work with the common printer driver1054(as will be hereinafter described in detail).

The various applications, such as the applications1051and the device apps1052ato1052b, can be installed in the computer100via a compact disk (CD)-ROM, a universal serial bus (USB) memory, or the network300.

The CPU101executes the programs of the OS and the programs of the applications expanded on the RAM1022to control the computer100. Thus, the hardware, such as the CPU101, the ROM1021, the RAM1022, and the storage105, constitute what is called a computer.

Although the client computer100is such that a single CPU101executes the processes illustrated in the flowcharts described later, the client computer100may have another configuration. For example, a plurality of processors may execute the processes illustrated in the flowcharts described later in cooperation.

The input I/F103connects a keyboard108and a pointing device109with the control unit120. The keyboard108and the pointing device109function as a receiving unit for receiving instructions from the user. The receiving unit can detect the selection of a display item, such as a key, displayed on the screen. The output I/F104connects a monitor110that displays information with the control unit120. The monitor110functions as a display that displays information. If the client computer100is a tablet terminal or the like, display of information to the user and reception of operations are performed via a touch panel display serving both as a receiving unit and a display. In this case, the user can input a desired operator instruction to the client computer100by performing a touch operation using an object, such as a finger.

The communication I/F106is an interface for communication with an external device, such as a printer on the network300, or a server on a cloud.

[Software Configuration of Computer100]

FIG.3is a diagram illustrating an example of the software configuration of the client computer100in the present embodiment. The OS1053is system software for controlling the entire computer100. Here, an OS of Windows® 10 or later is installed as an example.

The OS1053provides a print architecture10531for printing using a printer driver. The print architecture10531is what is called a V4 print architecture that converts spool data in XML paper specification (XPS) format to print data (PDL) with the printer driver.

An example of a printer driver that can be installed in a computer is a driver that is referred to as a universal printer driver. An OS, such as Ubuntu® 17.04, has a scheme for transmitting print data to a printer that supports IPP Everyware® as a default function of the OS. IPP Everyware is a series of standards that enables printing using various printers, for which formulation and popularization are being performed by an industry organization or the like.

The universal printer driver described above is generally provided vendor by vendor. This allows a plurality of types of printer with different functions sold by the same vendor can be supported by a single universal printer driver. However, it is difficult to support printers of different vendors with a single universal printer driver. This is because communication of a print job is performed using different communication methods, PDLs and job description languages (JDLs), vendor by vendor, making it difficult to unify the print drivers. Another reason is that print setting items differ for each vendor, or even similar setting items are differently interpreted, which makes it difficult to support them using a single universal printer driver.

If a scheme for executing printing without individually installing a V3-format or V4-format printer driver provided by vendors is provided also in an environment of Windows or the like, user convenience will be increased.

In view of the above, the present embodiment provides a common printer driver using the scheme of a predetermined print protocol can be provided in a Windows environment. The following description is made using an example in which the predetermined print protocol is the commonly used IPP.

Suppose a case in which a common printer driver conforming to the IPP is simply installed. In this case, a print job including printing attributes conforming to the IPP and a PDL based on the IPP are generated and transmitted to the printer. This has a problem in that functions that are not defined in the IPP and are independently provided by a vendor (for example, a needleless binding function for binding prints without using needles and a box storage function for storing print data in a storage of a printer) cannot be used.

Accordingly, the present embodiment enables an extension application for using functions specific to each vender to be invoked from a common printer driver conforming to the IPP so that extended functions of each vendor can be provided. A specific scheme will be described hereinbelow.

Referring back toFIG.3, the common printer driver1054that supports printers of a plurality of vendors is installed in the client computer100as a printer driver. The common printer driver1054may be a class driver installed as a standard function of the OS1053or a universal printer driver that is separately installed in the computer100by the user.

The print architecture10531includes a GDI to XPS conversion module307, the common printer driver1054, an OS standard-printing UI305, a print manager318, and a device communication unit319. It is also possible to install a printer driver different from the common printer driver (for example, a printer driver only for a model that the vendor provides).

[Print Processing Using Common Printer Driver1054]

First, print processing that uses the common printer driver1054will be described. Examples of a desktop app301include “Win32/64 application” and “.NET application”. A UWP app302is a universal windows platform (UWP) application that operates on the OS1053. The UWP application is an application distributed via a Windows store and operates in an execution environment different from those of the desktop app301and the print architecture10531. The UWP app operates in an individual sandbox (virtual environment) and is limited in access to the system area and in available application programming interface (API). In other words, the UWP app has low access authority to resources in the apparatus, compared with the desktop app and the device driver. For this reason, the UWP app is less likely to affect the system than the desktop app and the driver programs.

These desktop app301and UWP app302can print contents (for example, documents and images) in cooperation with the print architecture10531.

The desktop app301performs printing using Graphics Device Interface (GDI), which is a graphics component that generates a print image of the printer. When printing using the GDI, the desktop app301transmits GDI drawing data to the GDI to XPS conversion module307, which is a module of the OS1053. The module307converts the GDI drawing data to an XPS spool file. The converted XPS spool file is temporarily stored in an area306. In contrast, for printing via the UWP app302, there are two methods, a method for creating an XPS file with the UWP app itself and a method for creating an XPS file with the OS1053according to a drawing command from the UWP app. The XPS file created by either method is transferred to the area306, where it is temporarily stored.

The user executes print processing via the desktop app301or the UWP app302displayed on the monitor110of the output unit using the input unit, such as the keyboard108or the pointing device109typified by a touch panel/mouse. Here, printing via the UWP app302will be described as an example.FIG.8illustrates an example of a screen displayed when printing is performed via the UWP app302, which is an example of a setting screen (user interface), referred to as a modern print dialog, provided by the OS1053. When a print instruction is given via the UWP app302, the CPU101displays the print dialog on the monitor110. The user can select an area801to select a printer to be used for printing and can select print settings by selecting the items in an area804. The user can give a print instruction using a print key803. Here, an example in which a printer compliant with the common printer driver1054is selected by the user will be described. An additional settings key802is a key for detailed print settings. Upon detecting that the key is selected, the OS activates the OS standard-printing UI305to display a print setting screen (user interface) conforming to the IPP (not illustrated).

Upon detecting a user operation to change the print settings, the OS1053invokes a standard-printing setting unit308of the common printer driver1054. The standard-printing setting unit308refers to a definition file for the printer, selected from the standard-printing-function definition file group309. The standard-printing setting unit308creates standard setting data (303or304) indicating the current print settings and PrintCapabilities indicating the printing capabilities of the selected printer on the basis of the definition file referred to.

The standard-printing-function definition file is a definition file indicating the capabilities of the printer, generated on the basis of attribute information obtained from the printer at searching for an IPP printer, for example. Accordingly, the standard-printing-function definition file group309stores different files printer by printer.

Next, generation of the definition file will be described. If a definition file for the selected printer is not stored in the storage, the common printer driver1054sends an inquiry to the printer about capability information. The common printer driver1054inquires of the printer the capabilities via the print manager318and the device communication unit319. The print manager318can search for a printer supporting the IPP and obtain the printer capabilities, in addition to controlling the print job, to be described later. Specifically, the printer capabilities are obtained by a printer-attribute requesting operation (Get-Printer-Attributes Operations) defined in RFC2911. First, the print manager318transmits Get-Printer-Attributes Request to the printer200. In response to the request, attribute information on the printer200is obtained. Examples of the printer capability information obtained by the printer-attribute requesting operation include standard print-setting capability information, for example, whether “two-sided” and “color printing” are available. The capabilities (attributes) obtained by the printer-attribute requesting operation is support information on attributes prescribed in the IPP. Accordingly, vendor-specific functional information (for example, a needleless function and a box printing function) cannot be obtained by the printer-attribute requesting operation of the IPP. The obtained attribute information is transferred to the standard-printing setting unit308. The standard-printing setting unit308generates a definition file on the basis of the attribute information obtained using the IPP and stores the definition file in the storage105.

Returning to the description of the print settings, the desktop app301uses binary DEVMODE303as standard setting data indicating the current print settings. The UWP app302uses PrintTicket304described in XML, which is a markup language. The DEVMODE303or PrintTicket304is standard setting data that holds print settings to be reflected to a print job conforming to the IPP.

FIGS.4A and4Bare diagrams for illustrating PrintCapabilities and PrintTicket. Both are XML-format files conforming to rules prescribed in the print architecture. A file400illustrated inFIG.4Ais an example of PrintCapabilities. The file400lists combinations of an available print setting item and a set value that can be set for the print setting item. Applications and user interfaces for print settings provided by the OS can constitute a print setting screen on the basis of the file400. Although this illustrates partial settings because of space limitations, this is not intended to limit the present invention. The file400may further include print setting items based on the attribute information conforming to the IPP and setting items for post-processing.

In contrast, a file401illustrated inFIG.4Bis an example of PrintTicket304, in which current print settings are listed. User interfaces for print settings provided by the application1051and the OS1053can change the print settings by rewriting the PrintTicket304.

The OS standard-printing UI305provides a screen for print settings (user interface) on the basis of the information described in PrintCapabilities for a selected printer.

Upon detecting that a print instruction is given from the user, the OS or the application generates an XPS spool file. The generated XPS spool file is transferred to the standard-printing processing unit312. The standard-printing processing unit312renders the received XPS spool file to convert it to PDL data conforming to the IPP. Examples of the PDL data conforming to the IPP include Portable Document Format (PDF) and PWG-Raster format data.

Furthermore, the standard-printing processing unit312generates print attribute information conforming to the IPP on the basis of the settings specified by the PrintTicket304included in the XPS spool file.

The PDL data and the IPP-compliant print attribute information are managed by the print manager318that manages the schedule of print processing. The print manager318creates a print job conforming to the IPP on the basis of the PDL data and the IPP-compliant print attribute information and registers the created print job with a queue (a waiting line). When the printer200becomes ready for printing, the IPP-compliant print jobs are transmitted in order of registration with the queue via the device communication unit319. To convert the print data coming from the application to PDL data conforming to the IPP in this manner is the main role of the common printer driver1054.

The above processing can only cope with the capabilities prescribed as IPP specifications and cannot cope with various functions provided by the printers200ato200c. Accordingly, in the present embodiment, the device app1052, which is an extension application, uses acquisition of detailed capability information using another communication method to deal with extended print settings other than the standard print settings.

The device apps1052ato1052bare different applications from the common printer driver1054and operate on a UWP platform. These applications are applications for making the functions of the printer200flexibly available as necessary on the basis of printing using the common printer driver based on the IPP. These applications operate in a sand-boxed UWP execution environment. This reduces the influence on the entire system even if the applications are hung up or make an error.

Here, an example in which the device app1052ais installed as a device application for the printer200ais illustrated, and an example in which the device app1052bis installed as a device application for the printer200bis illustrated. However, a device application for the printer200cis not installed.

Accordingly, if the user selects the printer200cas the output target of the common printer driver, the processing for extended print settings is skipped, and processing conforming to the IPP is performed. A given number of users do not need extended print settings using an extension application. The common printer driver1054stores setting on whether to activate the extended print settings in a setting storage unit320for each printer. The setting can be changed by user operation.

The standard-printing processing unit312determines whether to activate the device app on the basis of the installation situation of the extension application and the setting stored in the setting storage unit320.

The device app1052includes a printing startup app unit10521, an extended-printing setting unit10522, a print-job generation unit10525, and a device-app communication unit10524. The printing startup app unit10521is a module invoked for printing and manages the extended-printing setting unit10522, the device-app communication unit10524, and the print-job generation unit10525. The device app1052is linked with printers. The device app1052can provide a function of displaying a preview immediately after printing, a function of displaying a user interface that prompts changing print settings, and so on. Although the present embodiment assumes that a screen provided by the device app is invoked after PDL conversion is performed by the standard-printing processing unit312, this is not intended to limit the present invention. The extended-printing setting unit10522has a function of displaying an extension user interface that allows more-detailed print settings than the print settings conforming to the IPP. The device-app communication unit10524has a function for the individual modules of the device app1052for communicating with the printer200. The device-app communication unit10524obtains information on the printer200using a specific communication method or a specific control method. Examples of the specific communication method include Web Services for Devices (WSD) protocol and Simple Network Management Protocol (SNMP). The specific communication method may be a communication method using a vendor-specific protocol. Printer information can also be obtained using a control command defined in a job control language or a printer control language. For example, information may be requested from the printer using a command defined in Printer Job Language (PJL), PostScript, or Common Peripheral Controlling Architecture (CPCA). Information can also be obtained from the printer using another protocol, Network Printing Alliance Protocol (NPAP).

The print-job generation unit10525has a function of reflecting PDL conversion processing and extended print settings in the print job.

For example, the print-job generation unit10525of the device app1052ahas a function of converting PDL data included in an IPP-compliant print job to LIPS format (UFR format). The print-job generation unit10525of the device app1052bhas a function of converting PDL data contained in an IPP-compliant print job to PCL format. The PDL format converted by the device app1052is given for mere illustrative purposes and is not intended to limit the present invention. The PDL format be converted to PCL, RPCS, PS, ART, or SPDL2 format. The PDL data conversion processing is not indispensable. For example, when the printers200ato200csupport PDF direct printing, the conversion processing may be skipped.

Next, data processing in executing printing will be described, in outline, with reference toFIG.5.FIG.5is a schematic diagram illustrating the processing procedure of printing performed by the user.

First, the application1051obtains standard setting data that is set in PrintTicket format or DEVMODE format using the standard-printing setting unit308. The standard-printing setting unit308obtains a definition file for a selected printer from the definition file group309and generates standard setting data indicating the current print settings on the basis of the definition file. The standard setting data is changed as appropriate via a screen (user interface) for changing the print settings displayed by the application1051or the OS. Upon receiving a print start instruction, the application transfers the standard settings and the XPS spool file obtained by the standard-printing setting unit308to the standard-printing processing unit312.

The standard-printing processing unit312converts the received XPS spool file to PDL conforming to the IPP. The standard-printing processing unit312generates print attributes conforming to the IPP on the basis of the standard setting data indicating the current print settings. Then, the common printer150generates a print job on the basis of the converted PDL and the attribute information based on the IPP and passes the print job to the device app1052. If it is determined that the device app is not to be used, then the IPP-compliant print job is transmitted directly to the printer.

Next, the device app1052generates an extension setting screen (user interface) containing setting items that are not defined in the IPP from the capability information indicating extended settings, obtained from the printer200, and displays the screen on the monitor110.

The device app1052afor the printer200awill be described by way of example.

FIG.9illustrates an example of the print setting screen that the device app1052adisplays on the monitor110. Reference sign901denotes an example of the standard print settings. Reference sign902denotes an example of the extended print settings based the device capability information. The settings “box printing”, “secure printing”, and “needleless binding” displayed in902are examples of print settings that operate in vender-specific specifications. This allows the user to perform print setting based on specifications that are not defined in the IPP via the extension setting screen. An OK key903is a key for starting printing that reflects the print settings.

Upon detecting that the OK key903is selected, the device app1052agenerates extended settings, which are job attributes to be given to the print job, on the basis of the settings made via the extension setting screen. Next, the device app1052atransmits the print job containing the PDL and the job attributes to the printer200a. In this case, the job attributes contained in the print job can be expressed with a common peripheral controlling architecture (CPCA) command, and the PDL data can be expressed in LIPS format (UFR) format.

Finally, the printer200receives the IPP-compliant print job or the vendor-specific print job and prints an image on a sheet on the basis of the print job.

Next, the specific control will be described with reference to the flowcharts ofFIGS.6and7.

[Control of Client Computer100]

First, the operation of the client computer100will be described.FIG.6is a flowchart illustrating control of the client computer100. The operations (steps) illustrated in the flowchart ofFIG.6are implemented by the CPU101reading programs for implementing the control modules stored in the ROM1021or the storage105into the RAM1022and executing the programs. The processes illustrated in the flowcharts are implemented by the modules of the application1051, the OS1053, and the device app1052and software components in cooperation. Some processes, such as data transmission and input and output of information, are implemented in cooperation with the individual I/Fs. The processes are described with the software components and the applications as subject words to clearly illustrate the programs, which serves as subjects for implementing the processes.

The flowchart ofFIG.6illustrates processes executed when a printer that supports the common printer driver1054is specified as a printer to be used and an instruction for printing is received from the user.

In step S601, the application1051detects that the print key803in the common print dialog is pressed by the user. In step S602, the application1051generates drawing data and passes the drawing data to the OS1053.

In step S603, the OS1053generates an XPS spool file. In the case of printing via the desktop app301, the OS generates the XPS spool file using the GDI to XPS conversion module307.

In step S604, the print architecture10531and the common printer driver1054cooperate to generate a print job. The standard-printing processing unit312converts the XPS spool file to PDL conforming to the IPP. The standard-printing processing unit312generates print attributes conforming to the IPP on the basis of standard settings indicating print settings to be set for the job. The print manager318generates the print job on the basis of the PDL and print attributes conforming to the IPP.

Next, in step S605, the OS1053determines whether to use a device app. Specifically, the OS1053determines whether a device app supporting a printer selected as an output target (hereinafter referred to as selected printer) is present. If a device app for the selected printer is not present, the processing proceeds to S616. In contrast, a device app for the selected printer is present, the OS1053determines whether to start the device app for the selected printer with reference to the extension-app-setting storage unit320further. Specifically, the OS1053refers to settings for each printer, stored in the extension-app-setting storage unit320, on the basis of the ID or the like of the selected printer. If the settings referred to on the basis of the ID indicate setting not to start the device app, the processing proceeds to S616. In contrast, if the setting referred to on the basis of the ID indicates setting to start the device app, the processing proceeds to S606.

In S616, the OS1053transmits the IPP-compliant print job to the selected printer. Upon completion of the transmission, the series of processes ends.

In contrast, in step S606, the OS1053activates the device app1052for the selected printer and passes the IPP-compliant print job to the device app1052. At that time, information for uniquely identifying the selected printer and information for communicating with the selected printer (for example, an IP address) are also passed.

In step S607, the printing startup app unit10521of the device app1052receives the print job and the information on the selected printer, passed from the OS1053. In step S608, the printing startup app unit10521of the device app1052analyzes the print job.

In step S609, the printing startup app unit10521of the device app1052determines whether the capability information on the selected printer is stored (whether extended capabilities have been obtained). If the capability information on the selected printer is stored, the processing proceeds to S613, and if the capability information on the selected printer is not stored, the processing proceeds to S610.

In step S610, the device-app communication unit10524inquires capability information from the selected printer200. The device-app communication unit10524of the device app1052requests the capability information from the selected printer200using the specific communication method and the specific control command described above. In step S611, the device-app communication unit10524receives device capability information in response to the request transmitted in S610. The received capability information and the information in which the identifier of the selected printer is associated are stored in a common storage area that is accessible from the device app1052. This processing allows omitting processing for acquiring device capability information in the next and subsequent processing. The device capability information stored here contains setting items that are more detailed than attribute information (capability information) that can be obtained by a printer-attribute requesting operation (Get-Printer-Attributes Operations) of the IPP.

Next, in step S613, the extended-printing setting unit10522of the device app1052displays the extended print setting UI illustrated inFIG.9on the basis of the print job analysis result and the device capability information.

In step S614, the extended-printing setting unit10522of the device app1052receives an instruction to change the print settings based on user operation. As illustrated inFIG.9, print setting902, which is not prescribed in the IPP, can be set on the extended print setting screen (UI).

In step S615, the print-job generation unit10525of the device app1052generates a print job converted to a command that can be received by the selected printer on the basis of the extended print settings. For example, if the selected printer is the printer200a, and the device app is1052a, the print-job generation unit10525generates a print job whose job attributes are defined by the CPCA, and in which the PDL is converted to LIPS (UFR) is generated. If the selected printer is the printer200b, and the device app is1052b, a print job whose job attributes are defined by the JPL, and in which the PDL is converted to PCL is generated. In S617, the device-app communication unit10524transmits the print job generated in S615to the selected printer. The device-app communication unit10524connects directly to the printer200and performs job control using the WSD protocol or a vendor-specific protocol to execute printing.

Although the present embodiment illustrates an example in which the device-app communication unit10524of the device app1052transmits a print job directly to the printer200, this is not intended to limit the present invention. For example, the print job may be transmitted via the print manager318and the device communication unit319provided by the OS. In this case, the conversion of the PDL is not performed, and only the print attributes are rewritten to settings including vender extension. In other words, the print-job generation unit10525does not convert the PDL received from the OS and generates a print job including character string information indicating the extended print settings and binary data. The converted print job is input to the print manager318again and is transmitted to the printer200.

Next, control of the printer200will be described.FIG.7is a flowchart illustrating control of the printer200. The operations (steps) in the flowchart are implemented by the processor of the printer executing programs for implementing the control modules stored in the memory. The flowchart ofFIG.7is executed in response to activation of the printer200.

In step S701, the processor of the printer200determines whether a request to obtain capability information has been received from an external device. If the request to obtain capability information is received from an external device, the processing proceeds to S702, and if not, the processing proceeds to S703. In step S702, the processor of the printer200sends information indicating the capability of the device in response to the request. Here, if the acquisition request is a request for the Get-Printer-Attributes of the IPP, attribute information indicating capabilities that can be used in the IPP is sent by return. In contrast, if the acquisition request is an acquisition request from the device app described in S610ofFIG.6, device capability information indicating capabilities that are more detailed than the attribute information indicating capabilities available in the IPP is sent by reply.

Next, in step S704, the processor of the printer200determines whether a print job has been received from an external device. If a print job has been received from an external device, the processing proceeds to S705, and if not, the processing proceeds to S703.

In step S703, the processor of the printer200determines whether a shutdown instruction has been received. If a shutdown instruction has been received, the sequence of processing ends. In contrast, if a shutdown instruction has not been given, the processing returns to S701, and the processor waits for a request or a print job sent from an external device.

As described above, in the present embodiment, even in printing using a printer driver or a print client that generates a print job conforming to a predetermined print protocol, extended capabilities provided by printers of a plurality of vendors can be used as appropriate. The printer driver can be implemented as a class driver conforming to a predetermined print protocol, and extension for each vendor can be implemented by an extension application that operates in a sand-boxed environment. This makes it possible to achieve both of security and convenience. Furthermore, the extension application enables printing that makes use of vendor-specific resources (for example, vendor-specific PDL or JDL). If no extension application is provided or if the user wants no print settings using an extension application, the extension application need not be activated. This allows supporting both of users who like simple printing and users who want detailed print settings.

Second Embodiment

The first embodiment illustrates an example in which a PDL is generated by the common printer driver1054, and then print settings are extended using the device app1052. A second embodiment provides a scheme for print settings using a vendor-specific print setting screen also before a print instruction is given.

Since the hardware configuration and the software configuration of the second embodiment are the same as those of the first embodiment, descriptions thereof will be omitted.

First, data processing in executing printing in the second embodiment will be described, in outline, with reference toFIG.10.FIG.10is a schematic diagram illustrating the flow of data when the user performs printing.

The application1051obtains standard setting data using the standard-printing setting unit308, as in the first embodiment.

When an “Additional Settings” key802for advanced printing is pressed in a print dialog invoked from the application1051or the like, the print architecture10531of the OS activates a device app.

The device app1052activated by the OS generates extended settings on the basis of capability information obtained from the selected printer. The device app1052displays a screen (user interface) for print settings as inFIG.9using standard setting data (PrintTicket) passed from the standard-printing setting unit308and the extended settings obtained from the capability information obtained from the printer200. The screen for print settings can display an illustration indicating the form of an output based on printing conditions. The illustration is created as appropriate every time the user changes the print settings and can notify the user how the output will look. Furthermore, favorite print settings or the like can be registered via the screen for print settings. The favorite print settings are stored in a common data area of the device app1052. The user can select a display item for invoking favorite print settings from a list (not illustrated) to reflect the settings in the print settings.

Upon detecting that the print settings are changed by the user and an OK key is selected, the device app1052stores information on the extended settings in the common data area of the device app1052and passes the standard settings to the standard-printing setting unit308. The standard-printing setting unit308does not know the information on extended settings that can be provided by the printer200. Therefore, even if the information on the extended settings is given, the standard-printing setting unit308determines that the settings are unknown settings, leading to incorrect control. For this reason, the device app1052temporarily stores the extended settings in the common data area. This allows an extended print setting function to be provided without causing the OS1053to control the extended settings by the device app1052, which is activated in different processing in printing, reading the extended settings stored in the common data area.

Specific control will be described with reference toFIGS.11to12.FIGS.11to12are flowcharts illustrating control of the client computer100. The operations (steps) in the flowchart ofFIG.11are implemented by the CPU101reading a program for implementing the control modules stored in the ROM1021or the storage105into the RAM1022and executing it. The flowchart inFIG.11is executed in response to user operation indicating the intention of printing via a user interface provided by the applications1051.

In step S1101, the application1051receives key selection indicating print intention. In step S1102, the application1051displays a common print dialog as illustrated inFIG.8. In step S1103, the application S1051receives key selection for advanced printing. An example of the key for advanced printing is “Additional Settings” key802. Upon receiving a press on the key, the applications1051transmits information that specifies a printer driver and a printer and a request for an advanced-printing screen to the OS1053.

In step S1104, the OS1053determines whether to use a device app for prior print settings on the basis of the received information that specifies the printer driver and the selected printer. If a device app that supports the selected printer is not present, the processing proceeds to S1105. In contrast, if a device app for the selected printer is present, the OS1053determines whether to activate the device app on the basis of the extension-app-setting storage unit320. Since the determination is the same as in S605, a description thereof will be omitted. If it is determined to activate the device app, the processing proceeds to S1108, and if not, the processing proceeds to S1105.

In step S1105, the OS1053displays a standard print setting screen of the OS on the basis of PrintCapabilities and PrintTicket. The setting screen enables print settings based on the attributes obtained with the IPP. If an instruction for advanced print settings is given from the desktop app, the current print settings are interpreted by converting the print settings to PrintTicket using API that converts DEVMODE and PrintTicket to each other.

In step S1106, the OS1053receives an instruction to change the print settings based on the user operation. In step S1107, the OS1053updates the standard setting data (DEVMODE or PrintTicket) in S1105. Upon completion of the update, the processing proceeds to S1117.

In contrast, in step S1108, the OS1053activates a device app for the selected printer and passes print setting data (standard setting data) to be set for the print job to the device app. If the standard setting data is described in DEVMODE, the OS1053sends data converted to PrintTicket.

In step S1109, the activated device app receives the print setting information described in PrintTicket. In S1110to S1112, extension-setting acquisition processing similar to S609to S611in the first embodiment is performed.

In step S1113, the device app displays an extended print setting UI on the basis of the received print setting information and the device capabilities. In step S1114, the device app receives an instruction to change the print settings based on the user operation. In step S1115, the device app updates PrintTicket, which is print setting information. Next in S1116, PrintTicket containing the extended settings updated in S1115is temporarily stored in the common area that can be accessed from the device app. Upon completion of the processing of S1116, the processing proceeds to S1117. The device app sends standard setting data without the extended settings as the print attribute information to be sent back to the OS.

In step S1117, the applications1051displays the common print dialog again on the basis of OS standard function or the standard setting data updated by the device app1052. In step S1118, the application1051receives a print-button selecting operation in the common print dialog. Upon receiving the selecting operation, the sequence of processes for the print setting ends. Next, the print processing inFIG.12is performed.

FIG.12is a flowchart executed in place of the flowchart ofFIG.6in the first embodiment. The difference fromFIG.6is that the processing of S1301is executed in place of the processing of S613.

Since S601to S611are the same as those of the first embodiment, descriptions thereof will be omitted. The processing of the device app activated in S606and the processing of the device app activated in S1108are different processes. Accordingly, PrintTicket containing extended settings is transferred via the common storage area that can be accessed by the device apps.

In S1301, the device app1052displays the extended print setting UI on the basis of the attributes of the received IPP-compliant print job and PrintTicket containing extended settings stored in the storage area that the device app1052can access. The extended print setting UI displayed here may display a display item for calling up the favorite settings stored in the common data area of the device app1052. This enables the user to use the pre-registered favorite settings also on a print setting screen displayed after the print instruction is given. Upon completion of the display, the processing proceeds to S614. Subsequent processing is the same as the processing of the first embodiment.

The present embodiment provides the effect of being able to allow for pre-settings before printing is started.

Although the second embodiment illustrates an example in which extended settings are stored in a common data area, a method for transferring extended settings to a device app is not limited to the above. For example, when an area in which vendors can extend standard settings conforming to the IPP (hereinafter referred to as “vendor extension area”) is defined, processing similar to that of the second embodiment can be performed using the area. This processing will be described with reference to the schematic diagram ofFIG.13.

First, the application1051obtains standard setting data, which is information conforming to the IPP, using the standard-printing setting unit308. Upon receiving an instruction for advanced printing via a print dialog, the OS1053activates the device app1052. The device app1052displays the extended settings UI illustrated inFIG.9using the standard setting data (PrintTicket) transferred from the standard-printing setting unit308and extended settings obtained from the capability information obtained from the printer200. When the OK button inFIG.9is pressed by the user, the device app1052writes vendor-extension information into PrintTicket. For example, the device app1052writes a character string indicating extended settings available to the printer200, like1401inFIG.14, and transfers the character string to the OS1053. For the vendor extension area, the vendor-extension information is written so as to be based on specifications prescribed in the IPP. Accordingly, this data is appropriately dealt with also by the standard printer driver1054conforming to the IPP. The standard-printing processing unit312writes the vendor-extension information written in PrintTicket into attributes indicating the vendor extension area of the IPP-compliant print job as it is. This allows the extension setting information written in the vendor extension area to be transmitted to the device app1052, which operates in printing, allowing providing an extension setting changing function using this information.

In another modification example, the vendor extension area or the like is not used. For example, the standard-printing processing unit312and the print manager318generate an IPP-compliant print job containing only attributes conforming to the IPP from PrintTicket. At the same time, in activating the device app, in addition to the IPP-compliant print job, PrintTicket containing the extended settings illustrated inFIG.14is passed to the device app. In this case, the device app cancels the print settings conforming to the IPP and displays an extension UI on the basis of the received PrintTicket and the independently obtained device capability information.

In a modification example of the second embodiment, when extended print setting processing before printing using the device app1052is started is received, the setting processing (S1113and S1301) via the extended print setting UI after a print instruction is given may be skipped.

In an aspect of the present invention, even in printing using a printer driver or a print client supporting printers of a plurality of vendors, extended functions of each vendor can be appropriately used. In another aspect of the present invention, the driver is implemented as a class driver conforming to a predetermined print protocol, and extension for each vendor is implemented by an extension application that operates in a sand-boxed environment. This provides both of security and convenience. In another aspect of the present invention, an extension application for a printer driver that generates a print job conforming to a predetermined print protocol is provided so that printing that reflects print settings for each vendor can be performed via the application.

Other Embodiments