Patent Publication Number: US-8526020-B2

Title: Paper size support for a print system

Description:
RELATED APPLICATION DATA 
     This application is related to U.S. patent application Ser. No. 12/399,799 entitled “Driverless Architecture For Printing Systems”, filed Mar. 6, 2009, U.S. patent application Ser. No. 12/399,884 entitled “Approach For Printing to Web Services-Enabled Printing Devices”, filed Mar. 6, 2009, and U.S. patent application Ser. No. 12/399,895 entitled “Print Driver Localization Support From Printing Device To Support Multiple User Profiles”, filed Mar. 6, 2009, U.S. patent application Ser. No. 11/846,884 entitled “Capability-Based Control Of A Computer Peripheral Device”, filed Aug. 29, 2007, U.S. patent application Ser. No. 11/846,926 entitled “Automatically Generating Capability-Based Computer Peripheral Device Drivers”, filed Aug. 29, 2007, U.S. patent application Ser. No. 12/019,610 entitled “On-Demand Print Driver”, filed Jan. 24, 2008, U.S. patent application Ser. No. 12/253,823 entitled “Providing Device Defined User Interface Modifiers To A Computer System”, filed Oct. 17, 2008, and U.S. patent application Ser. No. 12/360,794 entitled “Automatically Updating A Printer Driver With New Printing Device Features”, filed Jan. 27, 2009, the contents all of which are incorporated by reference in their entirety for all purposes as if fully set forth herein. 
     FIELD OF THE INVENTION 
     The present invention generally relates to printing and, more particularly, to supporting seemingly unlimited paper sizes in a printing system. 
     BACKGROUND 
     The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. 
     Part of the utility of a printing device includes the number of features and options on the printing device that are available to users of the printing device. One of those features is paper size. The more paper size options that are available, the more varying types of print jobs a user can submit. However, the number of different paper size options tends to be limited by the number of paper size options defined in the corresponding print driver. Thus, even if a printing device is capable of 100 different paper size options, the corresponding print driver may be configured to only recognize a relatively small number of paper sizes. 
     A print driver is software that executes on a client device (e.g., a PC) and converts data to be printed to the form specific to a printing device of a particular model. The purpose of printer drivers is to allow software application programs to cause printing without being aware of the technical details of the corresponding printing device. 
     Some printing devices include a configurable input paper tray, which is adjustable to take print media of an almost unlimited number of paper sizes. However, because print drivers are defined to only support a certain number of paper sizes, if a user wants to print with a paper size that the print driver does not support, then the user must take one of two approaches. According to a first approach, the user determines the new paper size and creates a new form for the new paper size using an application program&#39;s graphical user interface (GUI). According to a second approach, the user uninstalls the old print driver, locates a new print driver that supports the new paper size (assuming one exists), and installs the new print driver. 
     One example is envelope printing where a printing device includes an adjustable envelope input tray. If a user adjusts the envelope input tray and wants to print to the envelope input tray, then the user is required to (1) know the exact dimensions of the envelope that the user is inserting and then (2) select the size of the envelope from a pre-defined list of envelope sizes that the current print driver supports. If the user does not know the exact size, then the user may either select a wrong paper size or not be able to print. This results in a significant inconvenience to the user. 
     According to the first approach, if the user is inserting an envelope whose paper size is not supported by the corresponding print driver, then the user must perform (according to the first approach described above) a number of steps in order to be able print with that envelope.  FIG. 1  is a flow diagram  100  that depicts these manual steps. At step  110 , the user adjusts the input paper tray (or simply “input tray”) to fit the envelope. At step  120 , the user measures the dimensions of the envelope. At step  130 , using a GUI of an application program, the user creates a new form based on the dimensions of the envelope. The print application provides user interface controls that allow the user to input a new paper size and save the new paper size for subsequent selection when submitting a print job. At step  140 , the user opens the application program (if not already open) and prints with the new form. Even though the user is able to print using a paper size that is not supported by the corresponding print driver, the user must perform a number of manual steps that may significantly inconvenience the user. 
     One of the problems with the second approach is that a new print driver must be generated and distributed to a large number of users. Printing device manufacturers attempt to provide current print drivers available on their Website for download, but many users do not know to check a manufacturer&#39;s Website for current drivers. Furthermore, many print drivers must be certified by the company that makes the operating system or by printing device manufactures, which can be time consuming and expensive. Any changes to a print driver typically trigger a re-certification requirement. 
     SUMMARY 
     Techniques are provided for printing electronic data. According to one technique, a print driver, executing on a client device, retrieves, from a Web Service-enabled printing device, paper size data that indicates a particular paper size that the Web Service-enabled printing device is currently configured to support. The particular paper size is not supported by the print driver. In response to retrieving the paper size data, the print driver updates, based at least upon the paper size data, printer description data, associated with the print driver, to indicate the particular paper size. Printer description data specifies display data for one or more features and options from the plurality of features and options currently supported by the Web Service-enabled printing device. The print drive then generates, based at least upon the display data contained in the printer description data, graphical user interface data which, when processed at the client device, causes at least the particular paper size to be displayed on a graphical user interface. The print driver then receives, from an application program, application data generated by the application program. The application data indicates the particular paper size. The print driver generates print data and a print job ticket based upon the application data. The print driver causes the print data and the print job ticket to be transmitted to the Web services-enabled printing device. 
     According to another technique, a print driver, executing on a client device, retrieves, from a Web Service-enabled printing device, paper size data that indicates a particular paper size that the Web Services-enabled printing device is currently configured to support. Again, the particular paper size is not supported by the print driver. In response to retrieving the paper size data, the print driver creates, based at least upon the paper size data, a form that corresponds to the particular paper size and indicates the particular paper size. An application program then generates, based at least upon the form, graphical user interface data which, when processed at the client device, causes at least the particular paper size to be displayed on a graphical user interface. The print driver receives, from the application program, application data generated by the application program. The application data indicates the particular paper size. The print driver generates, based upon the application data, print data and a print job ticket. The print driver causes the print data and the print job ticket to be transmitted to the Web services-enabled printing device. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which: 
         FIG. 1  is a flow diagram that depicts manual steps that, according to one approach, a user performs to be able to print with a paper size that is not defined by a print driver; 
         FIG. 2  is a flow diagram that depicts manual steps that a user performs to be able to print with a paper size that is not defined by a print driver, according to an embodiment of the invention; 
         FIG. 3  is a block diagram that depicts an example printing arrangement, according to an embodiment of the invention; 
         FIG. 4  is a sequence diagram that depicts an example set of communications between elements of a client device and a printing device when a new paper size is detected, according to an embodiment of the invention; 
         FIG. 5  is a flow diagram depicting an approach for generating printer description data for a particular feature from printing device capabilities data, according to an embodiment of the invention; 
         FIG. 6  is a sequence diagram that depicts an approach for updating printer description data, according to an embodiment of the invention; and 
         FIG. 7  is a block diagram that illustrates a computer system upon which an embodiment of the invention may be implemented. 
     
    
    
     DETAILED DESCRIPTION 
     In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention. 
     General Overview 
     Techniques are provided to allow a user to print with a paper size that is not supported by a print driver. Thus, the print driver is configurable in being able to process print jobs that specify a seemingly unlimited number of paper sizes. 
     Although the following description references “paper size,” embodiments of the invention are not limited to paper as the sole print media. Embodiments of the invention include any other type of print media. Thus, “paper size” is merely shorthand for “print media size.” 
       FIG. 2  is a flow diagram  200  that depicts manual steps that a user performs to be able to print with a paper size that is not supported by a print driver, according to an embodiment of the invention. At step  210 , the user adjusts an input tray on a printing device to fit a print medium on which print data will be printed. At step  220 , the user opens an application program and causes the application program to issue a print job with (a) a new form that the print driver automatically created (i.e., without user assistance) based on the adjusted input tray or (b) a selection, in a GUI generated by the print driver, of a paper size that corresponds to the adjusted input tray. 
     Printing System Architecture 
       FIG. 3  is a block diagram that depicts an example printing arrangement  300  that includes a client device  302  and a Web Services-enabled (WSD) printing device  304  communicatively coupled via a network  306 . Network  306  may be implemented by any medium or mechanism that provides for the exchange of data between client device  302  and WSD printing device  304 . Examples of network  306  include, without limitation, a network such as a Local Area Network (LAN), Wide Area Network (WAN), Ethernet or the Internet, or one or more terrestrial, satellite or wireless links. 
     WSD printing device  304  includes a WSD printing service  308 . Client device  302  includes a user interface  310 , an application program  312 , a print driver installation application  314 , a print driver  316 , with a User Interface (UI) module and a rendering module  320 , a port monitor and Web Services Device (WSD) Application Program Interface (API) module  322 , a spooler  324 , and a storage  326 . Storage  326  stores printing capabilities data  328 , print data  330 , and a print job ticket  332 . Storage also includes a print driver storage  334  and a registry  336  that stores printer description data  338  and a default print ticket  340 . Each of these elements is briefly described below and in more detail hereinafter. 
     User interface  310  is a mechanism and/or medium for presenting information to a user and allowing user input. Application program  312  may be any type of program that prints data. Examples of application program  312  include, without limitation, a word processing program, a spreadsheet program, an email client, etc. A single application program  312  is depicted in  FIG. 3  for purposes of explanation, but client device  302  may have any number of application programs. 
     Printer driver installation application  314  performs installation of print driver  316  which may include installing any data or files required by print driver  316 . Installation of print driver  316  may also include obtaining data and/or files from other sources and locations, depending upon an implementation, as well as performing any configuration required by an operating system. 
     Print driver  316  interacts with application program  312  to generate print data for printing on WSD printing device  304 . UI module  318  generates graphical user interface data which, when processed by application program  312 , provides a graphical user interface on user interface  310  for a user to select the features and options to be used when printing a particular electronic document. Rendering module  320  processes application data generated by application program  312  and generates print data which, when processed by WSD printing device  304 , cause a printed version of an electronic document reflected in the print data to be printed at WSD printing device  304 . Print driver  316  performs various other functions that are described in more detail hereinafter. 
     Port monitor and WSD API module  322  allow communications between print driver  316  and WSD printing device  304 . For example, the WSD API module  322  may be installed on a custom port and print driver  316  communicates with the WSD API module  322  via the custom port. The port monitor and WSD API module  322  communicate with WSD printing device  304 . Thus, port monitor and WSD API module  322  is capable of converting client side commands, e.g., BiDi function calls, to SOAP requests, in the form of SOAP envelopes, and is also capable of extracting XML information from SOAP responses, in the form of SOAP envelopes, received from WSD printing device  304  and generating BiDi function call responses. Port monitor and WSD API module  322  sends SOAP requests to the port associated with WSD printing service  308 . 
     Printing device capabilities data  328  is data that specifies the current features and options, i.e., allowed values for each feature, of WSD printing device  304 . Examples of printing device features include, without limitation, a paper tray, duplex printing, stapling, hole punching, ultraviolet (UV) coating, etc. Each feature has one or more options, i.e., values. Some features may only have two options. For example, UV coating typically has two options, such as “enabled” or “disabled”. Other features, for example, paper size, may have many options, e.g., “A4”, “legal”, “8½×11”, etc. Printing device capabilities data  328  stored on client device  302  may include printing device capability data for any number of WSD printing devices. 
     Print data  330  is data generated by print driver  316 , based at least upon application data generated by application program  312 , which when processed by WSD printing device  304 , causes a printed version of an electronic document represented in the print data  330  to be printed. Print job ticket  332  specifies one or more parameters that indicate how print data  330  is to be processed at WSD printing device  304 . Print data  330  may include data for multiple print jobs and print job ticket  332  may include multiple print job tickets. 
     Printer driver storage  334  contains one or more print drivers that are used by client device  302  to print on printing devices. Registry  336  is an area of storage  326  for storing printer description data  338  and the default print ticket  340 . Registry  336  may be a protected area of storage  326  that is under the control of an operating system on client device  302 . Default print ticket  340  includes data that indicates default options for the features supported by WSD printing device  304 . Default print ticket  340  may include default print tickets for any number of printing devices. 
     Print driver  316  generates printer description data  338  based at least upon printing device capabilities data  328 . Printer description data specifies display data for one or more feature and options currently supported by WSD printing device  304 . Print driver  316  uses printer description data  338  to generate graphical user interface data and also for generating print data  330  and/or print job ticket  332 . 
     Reporting a New Paper Size 
       FIG. 4  is a sequence diagram that depicts an example set of communications between elements of client device  302  and WSD printing service  308  when a new paper size is detected, according to an embodiment of the invention. 
     At step  1 , WSD printing service  308  sends an event notification that indicates that there is a change to a feature and/or option provided by WSD printing service  308 . The event notification is a SOAP message that includes a portion that conforms to a WS-Eventing specification. The event notification may be sent in response to WSD printing device  304  detecting that the configuration of an input tray of WSD printing device  304  has changed or that a new input tray has been inserted into WSD printing device  304 . 
     At step  2 , in response to receiving the event notification, port monitor  322  creates, from the event notification, a modified notification that indicates that there is a change to a feature and/or option provided by WSD printing service  308 . The modified notification is in a format that UI module  318  is configured to process. Thus, port monitor  322  effectively removes the SOAP and WS-Eventing-related format portions from the event notification. Port monitor  322  then sends the modified notification to spooler  324 . 
     At step  3 , spooler  324  forwards the modified notification to UI module  318 . 
     At step  4 , in response to receiving the modified notification, UI module  318  generates a request message and sends the request message to spooler  324 . The request message indicates a request to query WSD printing device  304  for the features and options provided by WSD printing device  304 . 
     At step  5 , spooler  324  forwards the request message to port monitor  322 . 
     At step  6 , in response to receiving the request message, port monitor  322  creates, based on the request message, a SOAP request. The SOAP request includes a request to query WSD printing device  304  for the features and options provided by WSD printing device  304 . Port monitor  322  then sends the SOAP request message to WSD printing device  304 . If WSD printing device  304  implements a print device/service standard that defines an API to query a printing device/service, then the SOAP request includes a call to that API. An example of such a print service standard is Print Service Definition V1.0 for Web Services on Devices. 
     At step  7 , in response to receiving the SOAP request, WSD printing device  304  generates a SOAP response. The SOAP response includes new paper size data in addition to the other features and options provided by WSD printing device  304 . WSD printing device  304  then sends the SOAP response to port monitor  322 . 
     At step  8 , in response to receiving the SOAP response, port monitor  322  creates, from the SOAP response, a modified response that also includes the features and options currently supported by WSD printing service  308  and the new paper size data. The modified response is in a format that UI module  318  is configured to process. Thus, port monitor  322  effectively removes the SOAP-related format portions from the SOAP response. Port monitor  322  then sends the modified response to spooler  324 . 
     At step  9 , spooler  324  forwards the modified response to UI module  318 . 
     At step  10 , in response to receiving the modified response, UI module  318  creates, based at least in part on the new paper size data, a new form for the new paper size. A form is a set of data that indicates a paper size and other information related to the paper size, such as margins. UI module  318  then provides the new form to the operating system of client device  302 . In this way, one or more application programs (including application program  312 ) may use the new form as a native form of WSD printing device  304 . Also, UI module  318  updates its user interface to display the new paper size as a selectable option. 
     According to an embodiment, step  10  includes UI module  318  updating printer description data  338  in response to receiving the modified response that includes the new paper size data. The process of generating and updating printer description data  338  is described in detail below. 
     At step  11 , application program  312  generates a GUI, based at least in part on the new form, in response to user input that indicates a user&#39;s desire to print electronic data onto one or more print media. Then, in response to a user selection of the new paper size via the new form and the submission of a print job, application program  312  generates application data and sends the application data, including an indication that the new paper size was selected, to rendering module  320 . 
     At step  12 , rendering module  320  gathers information from the new form, generates print data (e.g., in the form of a PDL stream) from the application data, and sends the print data and a print ticket to spooler  324 . In addition to other print specifications, the print ticket includes paper size data that indicates that the new paper size is a customized paper size rather than a new paper size. 
     At step  13 , spooler  324  forwards the print data and the print ticket to port monitor  322 . 
     At step  14 , port monitor  322  generates a SOAP print request and includes the print data and the print ticket in the SOAP message. Port monitor  222  then sends the SOAP print request to WSD printing service  308 . In response to receiving the SOAP print request message, WSD printing service  308  prints to the input tray that includes one or more print media on which the print data is to be printed. The dimensions of the one or more print media correspond to the new paper size. 
     According to an embodiment, the event notification, from WSD printing device  304  in step  1 , specifically indicates what change has occurred, i.e., that a new paper size is supported. In this embodiment, the event notification may itself include the new paper size data. If the event notification does not include the new paper size, then, at step  4 , UI module  318  may be configured to request only the new paper size, instead of requesting features and/or other options provided by WSD printing device  304 . 
     As indicated above, in some situations, application program  312  may not provide its own print GUI to allow a user to (1) view certain features of WSD printing device  304  and (2) select options associated with those features. In such a scenario, steps  10 - 12  may be different. For example, at step  10 , UI module  318  does not create a new form and, thus, does not provide the new form to the operating system. Instead, UI module  318  updates printer description data  338 , which updating is described in detail below. Then, at step  11 , UI module  318  generates, in response to user input indicating the user&#39;s desire to print, a GUI that displays the new paper size as a selectable option. The user selects the new paper size option on the GUI and submits a print job. This scenario is described in more detail below. 
     Generating Printer Description Data 
     As previously described herein, UI module  318  is configured to generate and store in registry  336  printer description data  338  and is also configured to store default print tickets received from WSD printing device  304 . Printer description data  338  is used by UI module  318  to generate GUI data which, when processed by application program  312 , causes a GUI to be displayed on user interface  310  that displays the features and options supported by WSD printing device  304  and allows a user to select one or more features and options to be used when printing a particular electronic document. 
     The process for generating printer description data  338  generally involves combining information from the printing device capabilities data  328  for WSD printing device  304  and data from Core Mapping Data that is provided as part of the basic installed print driver. Appendix A includes example printing device capabilities data, Appendix B includes example core mapping data and Appendix C includes example printer description data. 
     According to an embodiment of the invention, UI module  318  examines the printing device capabilities data  328  and identifies the printing device features specified therein. For each feature in printing device capabilities data  328 , UI module  318  determines whether the feature is defined in the core mapping data. Core mapping data includes PDLKeywords and rcNameIDs for a standard set of printing device features and options. If a particular feature in printing device capabilities data  328  is defined in the core mapping data, then UI module  318  retrieves a PDLkeyWord value and rcNameID Value for the particular feature and each of the corresponding options from the core mapping file and stores the PDLkeyWord values and the rcNameID Values in printer description data. The PDLkeyWord value provides a mapping between a feature or option terminology understood by print driver  316  and the terminology understood by WSD printing service  308  for the same feature or option. The rcNameID Value indicates the name of a string variable (resource ID) that contains the string for the feature or option. The string is included in the GUI data that is generated by UI module  318  and provided to application program  312 . Consider the following example. Suppose that printing device capabilities data  328  includes a feature named “InputTray 4 ”. Suppose further that this feature is defined in the core mapping data as indicated below in Table I. 
     
       
         
           
               
               
             
               
                   
                 TABLE I 
               
               
                   
                   
               
             
            
               
                   
                 &lt;DeviceFeature Value=“InputTray4”&gt; 
               
               
                   
                  &lt;PDLKeyword Value=“InputTray4”/&gt; 
               
               
                   
                  &lt;rcNameID Value=“RC_STR_TRAY4” /&gt; 
               
               
                   
                  &lt;FeatureOption Value=“NotInstalled”&gt; 
               
               
                   
                   &lt;PDLKeyword Value=“NotInstalled” /&gt; 
               
               
                   
                   &lt;rcNameID Value=“RC_STR_NOTINSTALLED” /&gt; 
               
               
                   
                  &lt;/FeatureOption &gt; 
               
               
                   
                  &lt;FeatureOption Value=“Installed”&gt; 
               
               
                   
                   &lt;PDLKeyword Value=“Installed” /&gt; 
               
               
                   
                   &lt;rcNameID Value=“RC_STR_INSTALLED” /&gt; 
               
               
                   
                  &lt;/FeatureOption &gt; 
               
               
                   
                 &lt;/DeviceFeature &gt; 
               
               
                   
                   
               
            
           
         
       
     
     As indicated in Table I, the feature InputTray 4  has two options that include “NotInstalled” and “Installed”. Note that the feature and each option has both a specified PDLKeyword value and a specified rcNameID value, which UI module  318  retrieves and stores in printer description data. 
     If the particular feature in printing device capabilities data  328  is not defined in the core mapping file, then the particular feature is typically a new feature. In this situation, UI module  318  uses the feature name for the particular feature from the printing device capabilities data  328  to generate the PDLkeyWord value for printer description data  338 . In addition, UI module  318  includes the DisplayName values for the particular feature in printer description data  338 . Multiple DisplayName values may be included in printer description data  338  for each feature and/or option to provide support for multiple languages. The display name values are included in the GUI data that is generated by UI module  318  and provided to application program  312 . Referring to the prior example, suppose that the feature named “InputTray 4 ” is not defined in the core mapping data. Suppose further that this feature is defined in printing device capabilities data  328  as indicated below in Table II. 
     
       
         
           
               
             
               
                 TABLE II 
               
               
                   
               
             
            
               
                 &lt;rodp:InputTray4&gt; 
               
               
                   &lt;rodp:DisplayName xml:lang=“en-US”&gt;Tray 4&lt;/rodp:DisplayName&gt; 
               
               
                   &lt;rodp:DefaultOption&gt;NotInstalled&lt;/rodp:DefaultOption&gt; 
               
               
                   &lt;rodp:InputTray4Entry Name=“NotInstalled”&gt; 
               
               
                    &lt;rodp:DisplayName 
               
               
                    xml:lang=“en-US”&gt;Not Installed&lt;/rodp:DisplayName&gt; 
               
               
                   &lt;/rodp:InputTray4Entry&gt; 
               
               
                   &lt;rodp:InputTray4Entry Name=“Installed”&gt; 
               
               
                    &lt;rodp:DisplayName 
               
               
                    xml:lang=“en-US”&gt;Installed&lt;/rodp:DisplayName&gt; 
               
               
                   &lt;/rodp:InputTray4Entry&gt; 
               
               
                  &lt;/rodp:InputTray4&gt; 
               
               
                   
               
            
           
         
       
     
     As indicated in TABLE II, there are no PDLKeyword values or rcNameID values contained in the definition of the InputTray 4  feature in printing device capabilities data  328 . In this example, the feature name “InputTray 4 ” is stored in printer description data  338  as the PDLKeyword value. Also, UI module  318  retrieves the DisplayName values for the feature and each option and stores the DisplayName values in printer description data  338 . 
       FIG. 5  is a flow diagram  500  depicting an approach for generating printer description data  338  for a particular feature from printing device capabilities data  328 , according to one embodiment of the invention. This approach may be used for any number of features and also for any number of options for each feature. In step  502 , a feature is retrieved from printing device capabilities data  328 . In step  504 , a determination is made whether the feature is defined in the core mapping data. In step  506 , if the feature is defined in the core mapping data, then in step  508 , the PDLkeyword and rcNameID are retrieved from the core mapping data. In step  510 , the PDLkeyword and rcNameID are stored in printer description data  338 . As previously mention herein, printer description data  338  may include printer description data for any number of WSD printing devices. 
     If, in step  506 , a determination is made that the feature is not defined in the core mapping data, then in step  512 , the feature name and display name(s) are retrieved from printing device capabilities data  328 . As previously described herein, multiple display names may be used to provide support for multiple languages. In step  514 , the feature name is stored in printer description data  338  as the PDLkeyword for the feature. Also, the display name(s) are stored in printer description data  338  in association with the feature. 
     Dynamic Updating of Printer Description Data 
       FIG. 6  is a sequence diagram that depicts an approach for updating printer description data, according to one embodiment of the invention. In Step  1 , WSD printing device  304  generates an event indicating a change in printing features or options. This may include the deletion, addition or change of a printing feature or option. Port monitor and WSD API module  322  has subscribed to receive this event and receives the event. For example, port monitor and WSD API module  322  may receive an event notification in the form of a SOAP message specifying the event. 
     In Step  3 , port monitor and WSD API module  322  receives the event notification and notifies spooler  324 . In Step  3 , spooler  324  notifies UI module  318 . In Step  4 , UI module sends to the port monitor and WSD API module  322  a request for the device capabilities of WSD printing device  304 . The request may be implemented, for example, by a call to a SendRecvBiDiData function that contains a request for the device capabilities data of WSD printing device  304 . In this situation, the SendRecvBiDiData function makes a call to port monitor and WSD API module  322 . 
     In Step  5 , the port monitor and WSD API module  322  receives, from UI module  318 , the request for the device capabilities data of WSD printing device  304 . Port monitor and WSD API module  322  generates a SOAP request message, in the form of a SOAP envelope, based at least upon the request received from UI module  318  and forwards the SOAP request to WSD printing device  304 . 
     In Step  6 , WSD printing device  304  generates and sends to port monitor and WSD API module  322  a SOAP response message, in the form of a SOAP envelope, that includes the device capabilities data for WSD printing device  304 . The device capabilities data for WSD printing device  304  specifies the features and options currently supported by WSD printing device  304 . The device capabilities data in the SOAP response may include any portion or all of the device capabilities data available on WSD printing device  204 , depending upon a particular implementation. For example, the device capabilities data retrieved in response to the event notification may include all of the device capabilities data available on WSD printing device  204 . Alternatively, only the device capabilities data that corresponds to the change in features or options may be retrieved from WSD printing device  204 . In addition, the device capability data may be retrieved using any number of SOAP requests and responses. The SOAP response message may also include a default print ticket that specifies default options for WSD printing device  304 . 
     In Step  7 , port monitor and WSD API module  322  sends to UI module  318  a response that contains the device capabilities data of WSD printing device  304 . This may include port monitor and WSD API module  322  extracting XML information from the SOAP response and generating a response that includes the extracted information. In the situation where the request was implemented using a call to SendRecvBiDiData function, the response to the function call contains the device capabilities data from WSD printing device  304 . 
     In Step  8 , UI module  318  generates printer description data  338  for WSD printing device  304  and stores printer description data  338  in registry  336  as previously described herein. Alternatively, UI module  318  may update the existing printer description data for WSD printing device  304  to reflect the change in the features and/or options made to WSD printing device  304 . 
     In Step  9 , application program  312  makes a request to UI module  318  for GUI data. In Step  10 , UI module  318  retrieves printer description data  338  from registry  336  and generates the requested GUI data. The GUI data includes data which, when processed by application program  312 , allows a user to view and change the features and settings supported by WSD printing device  304 . The GUI data may include, for example, display data that includes display strings that correspond to features and options currently supported by WSD printing device  304 . In Step  11 , UI module  318  provides the GUI data to application program  312 . The process for processing a print job then continues as previously described in  FIG. 4 . 
     Implementation Mechanisms 
     According to one embodiment, the techniques described herein are implemented by one or more special-purpose computing devices. The special-purpose computing devices may be hard-wired to perform the techniques, or may include digital electronic devices such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are persistently programmed to perform the techniques, or may include one or more general purpose hardware processors programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination. Such special-purpose computing devices may also combine custom hard-wired logic, ASICs, or FPGAs with custom programming to accomplish the techniques. The special-purpose computing devices may be desktop computer systems, portable computer systems, handheld devices, networking devices or any other device that incorporates hard-wired and/or program logic to implement the techniques. 
     For example,  FIG. 7  is a block diagram that illustrates a computer system  700  upon which an embodiment of the invention may be implemented. Computer system  700  includes a bus  702  or other communication mechanism for communicating information, and a hardware processor  704  coupled with bus  702  for processing information. Hardware processor  704  may be, for example, a general purpose microprocessor. 
     Computer system  700  also includes a main memory  706 , such as a random access memory (RAM) or other dynamic storage device, coupled to bus  702  for storing information and instructions to be executed by processor  704 . Main memory  706  also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor  704 . Such instructions, when stored in storage media accessible to processor  704 , render computer system  700  into a special-purpose machine that is customized to perform the operations specified in the instructions. 
     Computer system  700  further includes a read only memory (ROM)  708  or other static storage device coupled to bus  702  for storing static information and instructions for processor  704 . A storage device  710 , such as a magnetic disk or optical disk, is provided and coupled to bus  702  for storing information and instructions. 
     Computer system  700  may be coupled via bus  702  to a display  712 , such as a cathode ray tube (CRT), for displaying information to a computer user. An input device  714 , including alphanumeric and other keys, is coupled to bus  702  for communicating information and command selections to processor  704 . Another type of user input device is cursor control  716 , such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor  704  and for controlling cursor movement on display  712 . This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane. 
     Computer system  700  may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system  700  to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system  700  in response to processor  704  executing one or more sequences of one or more instructions contained in main memory  706 . Such instructions may be read into main memory  706  from another storage medium, such as storage device  710 . Execution of the sequences of instructions contained in main memory  706  causes processor  704  to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. 
     The term “storage media” as used herein refers to any media that store data and/or instructions that cause a machine to operation in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device  710 . Volatile media includes dynamic memory, such as main memory  706 . Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge. 
     Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus  702 . Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications. 
     Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor  704  for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system  700  can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus  702 . Bus  702  carries the data to main memory  706 , from which processor  704  retrieves and executes the instructions. The instructions received by main memory  706  may optionally be stored on storage device  710  either before or after execution by processor  704 . 
     Computer system  700  also includes a communication interface  718  coupled to bus  702 . Communication interface  718  provides a two-way data communication coupling to a network link  720  that is connected to a local network  722 . For example, communication interface  718  may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface  718  may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface  718  sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information. 
     Network link  720  typically provides data communication through one or more networks to other data devices. For example, network link  720  may provide a connection through local network  722  to a host computer  724  or to data equipment operated by an Internet Service Provider (ISP)  726 . ISP  726  in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet”  728 . Local network  722  and Internet  728  both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link  720  and through communication interface  718 , which carry the digital data to and from computer system  700 , are example forms of transmission media. 
     Computer system  700  can send messages and receive data, including program code, through the network(s), network link  720  and communication interface  718 . In the Internet example, a server  730  might transmit a requested code for an application program through Internet  728 , ISP  726 , local network  722  and communication interface  718 . 
     The received code may be executed by processor  704  as it is received, and/or stored in storage device  710 , or other non-volatile storage for later execution. 
     In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention, and is intended by the applicants to be the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.