WO2021118591A1

WO2021118591A1 - Method and apparatus of bidirectional (bidi) communication of printer driver

Info

Publication number: WO2021118591A1
Application number: PCT/US2019/066191
Authority: WO
Inventors: Sangmin Lee; Mikyung CHOI; Rajivkumar Vinodchandra MISTRY; Woochul SHIN; Yu Rim Han; Junyoung Choi
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2019-12-13
Filing date: 2019-12-13
Publication date: 2021-06-17

Abstract

The disclosure provides a method and device of bidirectional (BiDi) communication of a version 4 (V4) printer driver. An example method includes obtaining data from a printer without using an operating system (OS) port monitor, converting the data to driver data, and applying the driver data to a print queue configuration.

Description

METHOD AND APPARATUS OF BIDIRECTIONAL (BIDI) COMMUNICATION

OF PRINTER DRIVER

BACKGROUND

[0001] Port monitors may provide a communication path between user mode print spoolers and kernel-mode port drivers that access input/output (I/O) port hardware. Port monitors may also support management and configuration of a server’s printer ports.

[0002] Windows™ supports a number of standard compatible identifiers (CompatiblelDs), in order to support several manufacturer-neutral print class drivers which support a limited set of features. Manufacturers that use these class drivers should implement enhanced driver configuration, using BiDi, to add more specific paper sizes, configurations, etc.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] FIG. 1 is a flow diagram illustrating operations of printing in version 4 (V4) according to the related art.

[0004] FIG. 2 is a diagram illustrating bidirectional (BiDi) communication within document print flow according to an example.

[0005] FIG. 3 is a flow diagram illustrating a Custom BiDi operating within V4 according to an example.

[0006] FIG. 4 is a flowchart of BiDi communication within document print flow according to an example.

[0007] FIG. 5 is a diagram illustrating BiDi communication outside document print flow according to an example.

[0008] FIG. 6 is a flowchart of BiDi communication outside the document print flow according to an example. DETAILED DESCRIPTION OF EXAMPLES

[0009] The present disclosure relates to a custom BiDirectional (BiDi) communication for a vendor specific printer driver. The BiDi may be based, for example, on the version 4 (V4) printer driver architecture for the Windows™ Operating System (OS).

[0010] Recent Windows operating systems (i.e. , Windows 8.0 and later versions) introduced the V4 printer driver architecture to support printing from various form factors of devices such as tablets, X-Box, laptops, desktops, HoloLens, and the like. To support these various form factors of devices, V4 printer driver architecture supported connecting to a printer through Microsoft released port monitors. These port monitors, in addition to delivering a print job to the printer, have also performed BiDi communication. However, a V4 printer driver’s BiDi communication is limited to what is provided by the operating system. In the V4 driver architecture, the operating system provided a mechanism to translate a BiDi response to a print queue configuration for printer vendors by using “Extension BiDi schema (XML)”. However, this mapping is restricted to Simple Network Management Protocol (SNMP) and Microsoft’s Device Web Services Capabilities (WS Capabilities) protocol over a network. Third-party port monitors and language monitors are not supported in the V4 driver model or with print class drivers.

[0011] Windows provides a process to extend a BiDi scheme of the port monitor for printer vendors to acquire custom data from the printer. However, this customization is limited to small and simple conversion, cannot handle complex interrogative queries, and the data format is restricted to either SNMP or WS capabilities. For example, a printer vendor cannot use a complex data structure that is defined in a proprietary format, in V4. Nevertheless, printer vendors continue to use proprietary formats and are expected to continue doing so. [0012] Thus, there is a need for a method and apparatus to read proprietary data from printers using interrogative queries and to configure a print queue to provide a feature rich experience to users using existing proprietary data models, within V4. [0013] An "image forming apparatus" may be any device capable of performing an image forming job, such as a printer, a copier, a scanner, a fax machine, a multi-function printer (MFP), or a display device. The "image forming job" may be at least one of printing, copying, scanning, and faxing.

[0014] Below, a description will be given of examples of the present disclosure with reference to attached drawings such that those of ordinary skill in the art may easily perform examples. In this regard, the present disclosure may have different forms and should not be construed as being limited to the descriptions set forth herein.

[0015] FIG. 1 is a diagram illustrating operations of printing in version 4 (V4) according to the related art.

[0016] Referring to FIG. 1 , vendor driver components include a generic printer description (GPD) 130, a configurer 140, a filter 160, a retrieval of bidirectional (BiDi) data from a printer 120 as written in BiDi Scriptl 80, and a user interface (Ul) 190. Operating System (OS) components include a print queue 150 and a port monitor 170. A print job is intended to be printed on a printer 120. [0017] In the related art, a user may enter configuration information (or “configuration data”) by opening a print properties Ul 190 at 106. Printer driver settings are obtained from the GPD 130 at 101. Printer capabilities are obtained from the printer 120 at 102. The port monitor 170 reads BiDi data in a standard format from the printer 120 at 103, and provides the BiDi data from the printer as written in BiDi script (e.g., transmission control protocol (TCP), web services on devices (WSD), universal serial bus (USB), etc.).

[0018] The BiDi data is provided to the configurer 140 at 105. The configurer 140 configures the printer driver by sending the printer driver settings through a print ticket to the print queue 150, at 107. The print queue 150 sends the printing job, including the print ticket, to the filter 160 at 108. The filter 160 renders the printer job and sends the job to the port monitor 170, at 109. The port monitor 170 sends the printing job to the printer 120, at 110.

[0019] FIG. 2 is a diagram illustrating bidirectional (BiDi) communication within document print flow according to an example.

[0020] Referring to FIG. 2, a BiDi manager 210 controls a BiDi workflow. When the BiDi manager 210 is requested to perform Custom BiDi, the BiDi manager 210 acquires printer data from the printer using a printer input/output (I/O) 220 and converts the printer data to driver data, which is understood by the printer driver, using a data converter 230. After the driver data is ready, the BiDi manager 210 updates the printer queue configuration using a data update manager 240. The configuration might include property bags, registry, or GPDs. After updating the data, the driver can use the data, and apply the data to printing jobs. The data may be applied by rendering a page to be printed in a page description language (PDL), based on the driver data.

[0021] The printer I/O 220 obtains proprietary data from the connected printer via a network or USB channel by performing interrogative queries. The printer I/O 220 may use a proprietary protocol or a standard protocol (e.g., Simple Network Management Protocol (SNMP), WSD, Internet Printing Protocol (IPP), etc.) to obtain the data.

[0022] Printer data might be either proprietary or in one or more standard formats which must be translated to the format of the V4 printer driver. The data converter 230 has the task of converting these different printer data formats to formats supported by the V4 printer driver. The V4 driver also has multiple types of formats based on the configuration aspect of the print queue. For example, some configuration, such as adding or removing a feature, might require a change in the GPD data format, or some configuration to change a behavior of a feature might require modifying a particular property of the print queue. The property might be implemented as a simple key value pair.

[0023] The data update manager 240 applies the driver data to the print queue configuration. According to the driver data format, the data update manager 240 will update the data to be in the proper format. The print queue configuration may include at least one of a property bag, a registry, or a GPD. [0024] The print queue configuration may then be applied to a printing job. [0025] The printer data may be proprietary. The printer data might correspond to a make of the printer, to a model of the printer, to a network protocol, or to a combination of one or more of these. The printer data is not limited thereto, and may correspond to other characteristics or information as well. [0026] The printer data might be obtained only if a print queue configuration change is needed, or might be obtained without regard to whether the print queue configuration change is needed.

[0027] Various trigger points may initiate the Custom BiDi and configure the print queue.

[0028] The printer data may be obtained in response to a filter of the printing job. This trigger may be activated within the document print flow by the user printing a document without opening the driver Ul, from the driver “filter” code. [0029] The printer data may be obtained in response to the user opening a print properties Ul. This trigger may be activated from the driver Ul code outside the document print flow.

[0030] The printer data may be obtained in response to particular events being detected outside of the document print flow.

[0031] The Custom BiDi may first obtain an address of the printer. For example, the printer might be saved by name and address in a user’s computer, or may be discovered by a search or query.

[0032] The Custom BiDi may perform a query to determine whether the printer is available. For example, the user might transport a computer such as a laptop or notebook computer to home and work, such that the computer might not be able to connect to the printer when not at the same location.

[0033] The Custom BiDi may connect to the printer, via the printer I/O 220, in response to determining that the printer is available. After connecting, the custom BiDi may obtain the data from the printer.

[0034] FIG. 3 is a flow diagram illustrating a Custom BiDi operating within V4 according to an example.

[0035] Referring to FIG. 3, some elements illustrated therein are substantially similar to corresponding elements in FIG. 1 , and in the interest of brevity a description thereof will not be repeated. FIG. 3 also includes an additional vendor driver component, a data repository (e.g., queue properties bag) 345. FIG. 3 further includes a Custom BiDi 300, which may correspond to the Custom BiDi described above with regard to FIG. 2.

[0036] As illustrated in FIG. 3, the Custom BiDi 300 may obtain the BiDi data from a printer 320 to discover and utilize capabilities and features of the printer 320 in V4. When a user opens a print properties Ul 390 at 306, the Ul 390 may open the Custom BiDi 300 at 311 to retrieve the data from the printer 320 outside the print flow, that is, without a print job having been sent for printing. Also, when a print job is sent from a print queue 350 to a filter 360 at 308, the filter may open the Custom BiDi 300 at 315 within the print flow, that is, with a print job that has been sent for printing.

[0037] The Custom BiDi 300 may read the BiDi data from the printer 320 at 314, for example, by interrogative queries. The Custom BiDi 300 may save the BiDi data in a print queue configuration and store the same in the data repository 345. A configurer 340 may thereafter refer to the printer data stored in the data repository 345 to configure the printer settings in the printer ticket.

[0038] FIG. 4 is a flowchart of BiDi communication within document print flow according to an example.

[0039] Referring to FIG. 4, the process may be entered by the user opening the print properties Ul 390 as described above, or by the filter 360 receiving the printing job including the print ticket as described above.

[0040] At operation 401 the Custom Bidi is opened. The Custom BiDi acquires the printer address from the port information of the queue at operation 403. The Custom BiDi determines whether the printer is available at operation 405, and in response to determining that the printer is not available may end the process at operation 415.

[0041] If the Custom BiDi determines at operation 405 that the printer is available, it connects to the printer to get the printer data at operation 407. The Custom BiDi may determine whether the printer BiDi data is available at operation 409, and may read the printer BiDi data by interrogative queries. The Custom BiDi may also determine that the printer BiDi data has already been saved to the data repository, and therefore avoid re-obtaining the data.

[0042] The Custom BiDi may convert the printer data to driver data at operation 411 and may update the print queue configuration with the driver data at operation 413. Thereafter the Custom BiDi exits the process at operation 415. [0043] FIG. 5 is a diagram illustrating BiDi communication outside document print flow according to an example.

[0044] Referring to FIG. 5, some elements illustrated therein are substantially similar to corresponding elements described above with regard to FIG. 2, and in the interest of brevity a description thereof will not be repeated. [0045] In addition to the Custom BiDi application/service being opened within the document print flow as described above, the Custom BiDi may also be opened or entered in response to various events outside the document print flow. For example, an event may be detected by an event handler 550, where the event is recognized as invoking the Custom BiDi. Such events may include, for example, that a port is changed, a new printer is added, a network is changed, a system reboots, a spooler starts, or the like.

[0046] Custom BiDi can work with an external application or a service provided as part of a print eco system. The external application or service will register for various system events which are necessary to simplify print experience for user. Some examples of such events may include a change in network, a change in printer connection, a new printer being installed, etc. On receiving the events, the external application or service will pass the event to the Event Flandler 550.

[0047] When event handler 550 receives the event, the event handler 550 calls a printer manager 560, which routes the event to print queues. To perform routing, the printer manager 560 may enumerate print queues from the repository and match a queue with the event. The printer manager 560 will route the events only when there is a queue configuration change needed. A BiDi manager 510 associated with the print queue will acquire the data from the printer.

[0048] The event handler 550 may inform the printer manager 560 of the event. The printer manager 560 may determine whether a print queue configuration which has the corresponding driver data applied is in the stored printer driver and queue data 570 (i.e., in the data repository). If the print queue configuration is not among the stored printer driver and queue data 570, the printer manager 560 may request the BiDi manager 510 to obtain the printer data. The BiDi manager 510 may control a printer I/O 520 to acquire the data from the printer, and may provide the data to the data converter 530 to convert the data to driver data. The driver data may be provided to the data update manager 540 to update the data of the print queue configuration.

[0049] FIG. 6 is a flowchart of BiDi communication outside the document print flow according to an example.

[0050] Referring to FIG. 6, the Custom BiDi process is entered at operation 601 in response to the event handler detecting a particular event which is recognized as invoking the Custom BiDi. Such events may include, for example, that a port is changed, a new printer is added, a network is changed, a system reboots, a spooler starts, or the like. The Custom BiDi retrieves the printer or queue information from the event data at operation 603 and determines whether the corresponding printer data is available at operation 605, for example, by checking whether the data is in the stored printer driver and queue data in the data repository.

[0051] If the Custom BiDi determines the printer data is available at operation 605, the Custom BiDi selects a printer queue using the printer data from the printer driver and queue data at operation 609.

[0052] If the Custom BiDi determines that the printer data is not available at operation 605, the Custom BiDi selects all the print queue from the printer driver and queue data at operation 607.

[0053] The Custom BiDi acquires the printer address information from the port information of the queue at operation 611 and determines whether the printer is available at operation 613. If the printer is not available, the Custom BiDi exits the process at operation 623.

[0054] If the printer is available, the Custom BiDi connects to the printer and determines whether the printer data for the printer is available, for example, by interrogative queries, at operation 617. If the printer data is not available, the Custom BiDi exits the process at operation 623.

[0055] If the printer data is available, the Custom BiDi obtains the printer data from the printer if the printer data is not in the data repository, and converts the printer data to the driver data at operation 619. The Custom BiDi updates the print queue configuration with the driver data at operation 621 , and may then exit the process at operation 623. [0056] The above-described method may be implemented as a non- transitory computer-readable recording medium storing instructions or data executable by a computer or a processor. The examples may be written as computer programs and may be implemented in general-use digital computers that execute programs using the computer-readable recording medium. The computer-readable recording medium may include read only memory (ROM), random access memory (RAM), flash memory, CD-ROMs, CD-Rs, CD+Rs, CD- DVD-Rs, DVD-Rs, DVD-RWs, DVD+RWs, DVD-RAMs, BD-ROMs, BD-Rs, BD- R LTHs, BD-REs, magnetic tapes, floppy disks, magneto-optical data storage devices, optical data storage devices, hard disks, or solid-state disks (SSD), and may be any device capable of storing instructions or software, associated data, data files, and data structures, and providing the instructions or software, associated data, data files, and data structures to a processor or a computer such that the processor or computer may execute the instructions.

[0057] Although the examples have been described with reference to the accompanying drawings, those of ordinary skill in the art will understand that various changes and modifications may be made therein. For example, the relevant results may be achieved even when the described technologies are performed in a different order than the described methods, and/or even when the described elements such as systems, structures, devices, and circuits are coupled or combined in a different form than the described methods or are replaced or substituted by other elements or equivalents.

[0058] It should be understood that embodiments described herein should be considered in a descriptive sense only and not for purposes of limitation. Descriptions of features or aspects within each embodiment should typically be considered as available for other similar features or aspects in other embodiments. While one or more embodiments have been described with reference to the figures, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope as defined by the following claims.

Claims

WHAT IS CLAIMED IS:

1 . A method of bidirectional (BiDi) communication of a version 4 (V4) printer driver, the method comprising: obtaining data from a printer without using an operating system (OS) port monitor; converting the data to driver data; and applying the driver data to a print queue configuration.

2. The method of claim 1 , further comprising obtaining the data in response to at least one of a filter of the printing job, an opening of a print properties user interface (Ul), or a print queue configuration change being needed.

3. The method of claim 2, further comprising: storing the driver data in a data repository; and refraining from repeating the obtaining of the data in response to the driver data being present in the data repository.

4. The method of claim 1 , wherein the data comprises proprietary data corresponding to at least one of a make of the printer, a model of the printer, or a network protocol.

5. The method of claim 1 , further comprising: obtaining an address of the printer; determining that the printer is available; in response to determining that the printer is available, connecting to the printer; determining that the data is available; and in response to determining that the data is available, obtaining the data from the printer.

6. The method of claim 1 , further comprising rendering a page to be printed in a page description language (PDL) based on the driver data.

7. The method of claim 1 , further comprising obtaining the data in response to detection of at least one of a port change, an adding of a new printer, a network change, a system reboot, or a spooler service start.

8. A device for custom bidirectional (BiDi) communication of a version 4 (V4) printer driver, the device comprising: an input/output (I/O) to connect to a printer; a BiDi manager to obtain data from the printer, via the I/O, without using an operating system (OS) port monitor; a data converter to convert the data to driver data; and a data update manager to apply the driver data to a print queue configuration.

9. The device of claim 8, wherein the data is obtained in response to at least one of a filter of the printing job, an opening of a print properties user interface (Ul), or a print queue configuration change being needed.

10. The device of claim 9, wherein the driver data is stored in a data repository, and wherein the device is to refrain from repeating the obtaining of the data in response to the driver data being present in the data repository.

11 . The device of claim 8, wherein the data comprises proprietary data corresponding to at least one of a make of the printer, a model of the printer, or a network protocol.

12. The device of claim 8, wherein the BiDi manager is to: obtain an address of the printer; determine that the printer is available; in response to determining that the printer is available, connect to the printer using the I/O; determine that the data is available; and in response to determining that the data is available, obtain the data from the printer.

13. The device of claim 8, wherein the print queue configuration configures a print queue to render a page to be printed in a page description language (PDL) based on the driver data.

14. The device of claim 8, wherein the BiDi manager is to obtain the data in response to detection of at least one of a port change, an adding of a new printer, a network change, a system reboot, or a spooler service start.

15. A non-transitory computer-readable storage medium encoded with instructions executable by a processor, the non-transitory computer-readable storage medium comprising: instructions to obtain data from a printer without using an operating system (OS) port monitor; instructions to convert the data to driver data; and instructions to apply the driver data to a print queue configuration.