Patent Application
20070070392
1. Field of the Invention
The present invention relates to a method, system, and program for processing requests for data sinks in a logical printer.
2. Description of the Related Art
A printer controller contains one or more logical printers, where each logical printer represents a single printer as viewed by an end user. A single logical printer controls either one or more physical print engines. A logical printer, also known as a logical printer domain (LPD), provides software components to process print jobs from different external sources. The logical printer includes one or more Protocol Interface Modules (PIMs) to handle print jobs for different transmission protocols. The logical printer may include a multiplexer or MUX to manage contentious requests from PIMs to have their print jobs processed by interpreters within the logical printer. The MUX may apply rules to determine which PIM to grant access to a data sink, such as an interpreter or spool.
In certain systems, the PIMs and MUX execute on different threads in a single process. The PIMs execute on threads and must obtain a semaphore or lock from the MUX thread before forwarding their print job to a data sink, such as an interpreter or spool. PIM processing is delayed until the PIM receives the semaphore from the MUX.
There is a need in the art for improved techniques for logical printers to manage the flow of print jobs.
Provided are a method, system, and program for processing requests for data sinks in a logical printer. A request is received to process a print job from one of a plurality of protocol components. A determination is made of one of a plurality of data sinks for the print job and whether the determined data sink is available. A return code is returned to the component initiating the request. A data sink available message is returned to the component initiating the request in response to determining that the determined data sink is available after returning the return code. Additional asynchronous operations are performed before returning the data sink available message.
The PIMs 20a, 20b . . . 20n receive print job data from an external source and deliver the data to an internal data sink 22a, 22b, 22c by calling a Multiplexer (MUX) 24 component. The PIMs 20a, 20b . . . 20n may package incoming data being sent to the MUX 24.
A RIP despool PIM 26 is used to cause the despooling of rasterized print jobs from the interpreter/RIP spool 22b to send to the print mechanism 6. Thus, the data sink for the RIP despool PIM 26 is the print mechanism 6. A raw despool PIM 28 despools print jobs from the raw spool 22c to send to a RIP spool 22b or the interpreter/mechanism 22a. The RIP 22b and raw 22c spools may include the functionality of a despooler, such that their despooler functionality operates as a PIM to despool a queued job. The Raw Despool PIM 28 forwards data to Interpreter/mechanism 22a or Interpreter/RIP Spool 22b. The RIP Despool PIM 26 forwards a request to RIP Despooler 27 that sends to Mechanism 6. In this way, the spools 22b, 22c comprise subsystems that include the capability to spool print jobs in a queue and to despool the print jobs using RIP Despool PIM 26 or Raw Despool PIM 28.
Certain components may function both as a data sink and a PIM. For instance a raw spool component may receive a print job as a data sink to a PIM 20a, 20b . . . 20n, but then a sub component may request a data sink to send spooled data to a downstream component, such as the interpreter/RIP spool 22b or the mechanism 6.
The MUX 24 comprises a software component that is called by the PIMs 20a, 20b. 20n to deliver data to a data sink 22a, 22b, 22c. The MUX determines what data sink will be used for the job, and delivers the data to the selected data sink. In one embodiment, the MUX 24 maintains an association of PIMs to data sinks 30 that associates a data sink 22a, 22b . . . 22n with one or more PIMs. Other parameters of a print job may also be used to determine the data sink in addition to the identity of the PIM, such as the content of the job, and the state of the path to the mechanism and the state of spooling system. For example, certain PIMs 22a, 22b . . . 22n that receive an intelligent printer data stream (IPDS) require that their data be supplied directly to an interpreter/mechanism 22a. Other types of print job content, such as email content, Portable Document Format (PDF) content, etc, are always spooled. If the MUX 14 receives multiple requests for a data sink from different PIMs, then the MUX 14 may use rules and criteria to select a contending request based on the PIM submitting the request and/or parameters of the print job. For instance, some data sinks can only process one job at a time, such as an interpreter/mechanism 22a. Other data sinks may queue jobs. Further, a spool may allow up to a maximum number of jobs to be spooled concurrently. The MUX 24 may consist of library routines that are called by the PIMs 20a, 20b . . . 20n, as well as a separate MUX process that communicates through messages.
The logical printer 14 may further maintain a pending data sink request list 32 identifying requests from PIMs 20a, 20b . . . 20n for which data sinks have been requested. The system may use rules based on the content of the print job or the requesting PIM 20a, 20b . . . 20n, pending time waiting, etc., to select a PIM when a data sink becomes available.
In one embodiment, the components, such as the PIMs 20a, 20b . . . 20n, MUX 32, interpreter/mechanism 22a and despoolers 26, 28 may execute within separate processes, where each process is allocated its own non-overlapping memory with respect to other processes and computational resources. In this way, the components may spawn additional threads to execute asynchronous operations while waiting for the MUX to respond to a request for a data sink.
In certain embodiments, the MUX code that returns the “need data sink” return code to the requesting PIM may comprise a MUX library routine called by the thread executing the requesting PIM. The executed MUX library routine may then communicate the data sink request to the MUX 14, which may execute on a separate process from the process executing the requesting PIM. In an alternative embodiment, the MUX 14 process may respond with the “need data sink” return code or other message.
If (at block 104) the determined data sink 20a, 20b, 20c is a raw spool 22c, then a determination is made (at block 106) as to whether the number of concurrent spooled jobs exceeds a maximum number for that data sink. If the maximum number is not exceeded, then the MUX 14 returns (at block 108) a data sink available message to the PIM 20a, 20b . . . 20n to allow the PIM to forward the print job to a next processing component. Otherwise, if the data sink (spool) is not available, then the MUX 14 adds (at block 110) an entry 60 to the pending data sink request list 32 identifying the print job 62, the requesting PIM 64 receiving the wait, and the print job 64. The MUX 14 then waits (at block 112) for the data sink to become available.
If (at block 104) the determined data sink is not a raw spool 22c, then the data sink may be an interpreter/mechanism 22a or RIP spool 22b. If (at block 114) the interpreter/mechanism 22a or RIP spool 22b is not available as a data sink, then control proceeds to block 110 et seq. Otherwise, if (at block 114) the interpreter/mechanism 22a or RIP spool 22b is available, then control proceeds to block 108 to send a data sink available message to the requesting PIM 20a, 20b . . . 20n.
In an additional embodiment, the PIM request may comprise a data sink request in an immediate form requiring an immediate response as to data sink availability. In response to such an immediate form data sink request, the MUX code may provide a return code that indicates to wait, but that a response is guaranteed soon. The MUX 14 would subsequently provide a response on whether the data sink is available. In such an embodiment, the requesting PIM waits for an immediate response to the request. The response indicates the availability of a data sink, or the rejection of the data sink request due to the unavailability of a data sink.
A print job from a PIM receiving the print jobs from an external source that is received and immediately sent to an interpreter is subjected to the output selection process once when the job is received. A job that is spooled and then printed is subjected to the output selection process twice, once when the job is received (and spooled) and again when the job is despooled (and interpreted and printed). A RIP spool job may go through the process two or three times: first, when the job is received (RIP spool jobs are directed first to a spool); second, when the job is despooled, interpreted and directed to the RIP spool; and third when the job is despooled from the RIP spool 22b to send to the mechanism 6.
Described embodiments provide a logical printer system that allows components to engage in asynchronous operations while they are waiting to forward their print jobs to a spool or interpreter mechanism via a MUX interface. In certain embodiments, the components, such as the PIMs, MUX, interpreters, etc., may be executed by separate processes in the operating systems and have the capability to spawn multiple threads to perform asynchronous and concurrent operations. This allows PIMs to perform asynchronous operations while waiting for a response to a data sink request from the MUX.
The described operations may be implemented as a method, apparatus or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The described operations may be implemented as code maintained in a “computer readable medium”, where a processor may read and execute the code from the computer readable medium. A computer readable medium may comprise media such as magnetic storage medium (e.g., hard disk drives, floppy disks, tape, etc.), optical storage (CD-ROMs, DVDs, optical disks, etc.), volatile and non-volatile memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs, DRAMs, SRAMs, Flash Memory, firmware, programmable logic, etc.), etc. The code implementing the described operations may further be implemented in hardware logic (e.g., an integrated circuit chip, Programmable Gate Array (PGA), Application Specific Integrated Circuit (ASIC), etc.). Still further, the code implementing the described operations may be implemented in “transmission signals”, where transmission signals may propagate through space or through a transmission media, such as an optical fiber, copper wire, etc. The transmission signals in which the code or logic is encoded may further comprise a wireless signal, satellite transmission, radio waves, infrared signals, Bluetooth, etc. The transmission signals in which the code or logic is encoded is capable of being transmitted by a transmitting station and received by a receiving station, where the code or logic encoded in the transmission signal may be decoded and stored in hardware or a computer readable medium at the receiving and transmitting stations or devices. An “article of manufacture” comprises computer readable medium, hardware logic, and/or transmission signals in which code may be implemented. Of course, those skilled in the art will recognize that many modifications may be made to this configuration without departing from the scope of the present invention, and that the article of manufacture may comprise suitable information bearing medium known in the art.
Reference letters, such as 22a, 22b, 22c, 20a, 20b . . . 20n, used to denote a number of instances of an element may indicate any number of that element. Further, uses of the same reference letter in different instances with the same element or with different elements may indicate the same or different number of instances of that element.
Although
The terms “an embodiment”, “embodiment”, “embodiments”, “the embodiment”, “the embodiments”, “one or more embodiments”, “some embodiments”, and “one embodiment” mean “one or more (but not all) embodiments of the present invention(s)” unless expressly specified otherwise.
The terms “including”, “comprising”, “having” and variations thereof mean “including but not limited to”, unless expressly specified otherwise.
The enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise.
The terms “a”, “an” and “the” mean “one or more”, unless expressly specified otherwise.
Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries.
A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary a variety of optional components are described to illustrate the wide variety of possible embodiments of the present invention.
Further, although process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously.
When a single device or article is described herein, it will be readily apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be readily apparent that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the present invention need not include the device itself.
The illustrated operations of
The foregoing description of various embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto. The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.
