Patent Application
20080278741
1. Field of the Invention
The present invention relates to an improvement to the Microsoft® Windows® family of operating systems, and in particular, to the addition of a pseudo-multithread framework to the filter pipeline of an XPSDrv print driver.
2. Description of the Related Art
Recently, Microsoft Corporation has introduced the Microsoft® Windows Vista™ operating system. One of the new features of this operating system is the XPS print path which includes a print architecture that is designed to improve support for printing and document processing.
In particular, print jobs that are processed through the XPS print path are processed by a print driver (referred to as the “XPSDrv” print driver) which includes a filter pipeline (referred to as the “XPSDrv Filter Pipeline”). The XPSDrv print driver and print path processing are described in greater detail in the Microsoft® Windows® whitepaper entitled “The XPSDrv Filter Pipeline”, published Nov. 3, 2005 (see http://wwww.microsoft.com/whdc/)
The creation of a typical XPSDrv filter pipeline will now herein be described in greater detail. A print job 104 is received into the print subsystem module 100 where the print job 104 is spooled by a print spooler and a spool file for the job is created in the XPS spool file 108. After documents have been spooled into an XPS spool file 108 and the job is ready to print, the scheduler 116 signals the filter pipeline manager 122 to begin processing. The filter pipeline manager 122 then reads the filter configuration file 106 and loads the filters that are listed in the configuration file 106. Next, the filter pipeline is initialized.
Thereafter, the filter pipeline manager 122 begins the filter pipeline process wherein the first filter 126 (Filter 1) in the filter pipeline reads the contents of the XPS spool file 108 for the specific job. Here, the first filter 126 reads the document parts and XML PrintTickets (print ticket), and performs processing to the document. Then, the filter 126 sends the processed document parts to the next filter 128 in the pipeline (Filter 2). This process is facilitated by using the interfilter communicator (IFC) 124, which retains intermediate processing results until the next filter in the pipeline is available.
When the next filter 128 in the pipeline is ready, it reads the document parts that the previous filter 126 processed. After the data is processed, the results are written back to the interfilter communicator 124. This process is performed for each filter (1-n) in the filter pipeline. After each filter processing is complete, the output from the last filter 130 (Filter n) is sent to the port 118 defined by the printer driver such that a document may be printed via the printer 110, or the like.
As discussed above, the XPS spool file 108 for the job is fed to the filters (1-n). It is noted that the XPS spool file 108 is defined by a hierarchical set of document parts that describe different aspects of the content of the document. In particular, the XPS spool file typically includes a Fixed Document Sequence object, Fixed Document objects, and Fixed Page objects.
Although the overall performance of the XPSDrv print drivers for the Microsoft® Windows® family of operating systems provides a viable new print architecture that improves support for printers and document processing, it is noted, however, that there is an inherent processing restriction indigenous to the XPSDrv Filter Pipeline environment.
In particular, the filters in the pipeline 126, 128, 130 (1-n) are not recommended to spawn threads, meaning that, within a filter all processing has to performed in a sequential (single threaded) mode. As a result, since the filtering is performed sequentially, the overall processing time for the print job inherently has some undesired latency. That is to say, the filters in the pipeline 126, 128, 130 (1-n), and their order of execution, are statically defined by the XPSDrv print driver's filter configuration file 106, meaning that, filters in the pipeline and their order of execution cannot be dynamically changed based on the print ticket settings. As a result, the XPSDrv print driver's document processing can not be optimized for the print job and processing time for print jobs is increased.
To overcome the aforementioned drawbacks inherent in the current version of Microsoft's XPSDrv Filter Pipeline, an enhancement to the same has been proposed in related U.S. patent application Ser. No. 11/560,715, filed Nov. 16, 2006, entitled “Pseudo-Multithread Framework For XPSDrv Filter Pipeline.
The aforementioned approach provides the addition of a pseudo-multithread architecture/framework for the XPSDrv Filter Pipeline. This infrastructure allows Feature Commands to be executed in “parallel”, without the need to spawn threads. This approach is taken since it is not recommended to spawn threads in the current XPSDrv Filter Pipeline environment). Each Feature Command is given an opportunity to produce one (or more) page(s) before relinquishing the execution to the another Feature Command in the chain. Utilizing this principle, a Dynamic Feature Command Filter executing in the XPSDrv Filter Pipeline is able to produce output pages while the input pages are still being read.
Although the pseudo-multithread framework is certainly a viable approach, one drawback of this solution is that the pseudo-multithread framework implements all the specified operations in a single filter running in one thread. A disadvantage of such an approach is that the pseudo-multithreaded framework configuration mimicking multithreaded operations running in a single thread adds more complexity, and it involves redundant operations, such as an additional task for managing the Feature Command List for maintaining correct processing order.
Therefore, it would be advantageous to enhance the XPSDrv print driver for the Microsoft® Windows Vista™ operating system by adding and/or modifying software features which will help speed up the overall processing time for the print job even though filtering is performed sequentially.
According to an exemplary embodiment of the present invention, a filter pipeline configuration (or framework) is provided as an improvement to the XPSDrv print driver utilized within the Microsoft® Windows® family of operating systems, such as the recently introduced Microsoft® Windows Vista™ operating system.
According to the present invention, filters are arranged in a specific order and tasks are distributed to three different filters running in a separate thread to perform specific scope of operations. Furthermore, operations performed in the filter can be dynamically configured based on the user print intent specified in the print ticket settings.
In particular, the filter pipeline configuration is provided to perform a dynamic set of operations from all the three filters based, and dynamically configured, on the users printing intent. As a result, this configuration allows three filters to run, each in a separate thread, simultaneously processing parts of the document without waiting for a previous filter to complete. That is to say, filters are not assigned based on the printing feature, rather, a filter is assigned based on the scope of operations.
As discussed in the Background Section, with regard to the conventional XPSDrv Filter Pipeline (see
According to the present invention, filters are arranged such a way that operations on least dependent parts are performed first so that next filter can start processing parts of the document without any delay. The configuration allows the print ticket processing to be done at the very beginning of the pipeline in a Logical Page Filter (LPF) which improves the performance of the filter processing because document processing commands will be readily available for remaining filters to process the document without any delay.
According to another aspect of the present invention, a method is provided for configuring the XPSDrv Filter Pipeline based on the scope of the operations, wherein whole document processing is divided based on the scope of the operations, and these operations are performed in each filter simultaneously. I.E., the filters are performed one after another, wherein the first filter gets an opportunity to perform first, then second filter, and so on, etc.
Instead of processing specified operations in a single filter thread, there are three filters running in each thread performing assigned scope based operations which improves the performance of the print job. As a result, this method provides the arrangement of an XPSDrv Filter Pipeline in which the Logical Page Filter performs operations on the least single unit (or part) or least dependent unit (or part) of the document called logical page. Once the required processing on the part is complete, the same processed part will be sent to a Document Level Filter to be further processed further. As soon as the Document Level Filter gets the parts of the job, it starts processing the job.
According to another aspect of the present invention, the method includes processing all the print tickets of a print job from the Logical Page Filter which creates a Command Manager instance which parses the resultant job print ticket from merging of a default print ticket with the job print ticket and generates a Job Level Command List and Physical Page Command List. And upon parsing a resultant document print ticket from merging of resultant job and document print ticket, a Document Level Command List is generated. Also in a similar way, by parsing a resultant page print ticket from the merging of resultant document print ticket with page print ticket, a Logical Page Level Command List is generated. As soon as the resultant page print ticket is parsed, the Logical Page Filter gets the Logical Page Level Command List from the Command Manager and executes commands on this page. Once all the commands are executed, the Logical Page Filter sends out the page to the Document Level Filter.
Another aspect of the present invention is that the same Command Manager instance, created at the time of initialization of the Logical Page Filter, is passed to the Document Level Filter and the Job Level & Physical Page Filter through a property bag. When the Document Level Filter (DLF) gets the first document, the Document Level Command List, which is a list of commands to be performed on the document is available from the Command Manager. The Document Level Filter gets the Document Level Command List from Command Manager using part names and executes the same list on cached parts for each instance. I.E., the Document Level Filter gets a new Fixed Page part until it receives a new Fixed Document part.
And, according to yet another aspect of the present invention, upon receiving a Fixed Document Sequence part, the Job Level Filter calls the Command Manager to get a Job Level Command List and Physical Page Command List. On receiving every fixed page part, the Job & Physical Level Filter caches the incoming Fixed Page and executes all the job commands on cached pages. Moreover, while executing the job commands, if the command meets the condition, i.e., ready to process a Physical Page Command List, the command calls the Job Level & Physical Page Filter to execute the Physical Page Command List on the Fixed Page and sends out the processed Fixed Page to the Inter-Filter Communicator. The aforementioned chain of operations takes place until all three filters receive the final part.
Moreover, another aspect of the present invention includes the definition of commands which include a “pre-condition”, “operation”, and “post-condition”. A pre-condition triggers whether a command can be performed or not. A post-condition triggers performing an additional task after performing the command. For example, apart could be sent out to the next filter or additional physical commands are applied.
According to another aspect of the present invention, a filter pipeline framework is provided for a printer driver including a plurality of filters. The filter pipeline framework includes a logical page filter configured to perform operations on logical pages within a first thread; a document level filter configured to perform document level operations within a second thread; a job level and physical page filter configured perform job level operations and physical page operations within a third thread; and a command managing unit configured to generate and manage commands compiled in command lists for the filters. Here, print ticket processing is performed at the beginning of the filter pipeline in the logical page filter. And further, each filter simultaneously runs within its own thread to perform a specific scope of operations defined for each filter.
And, according to another aspect of the present invention, command lists are generated by the command manager via a request from the logical page filter. The command lists include a logical page command list for commands to be performed on individual logical pages; a document level command list for commands to be performed on fixed pages of an individual document; a job level command list for commands to be performed on a complete job; and a physical page command list for commands to be performed on individual physical pages.
Moreover, according to yet another aspect of the present invention, whole document processing is divided based on the specific scope of operations for each filter. Additionally, operations performed in each filter may be dynamically configured based on user intent specified in print ticket settings. Furthermore, the logical page filter, document level filter and job level and physical page filter are not assigned based solely on printing features.
Still yet, according to another aspect of the present invention, the logical page filter, document level filter and job level and physical page filter may be arranged such that operations on least dependent parts are performed first such that a next filter in the pipeline can start processing parts of a document without delay.
According to yet another aspect of the present invention, the filter pipeline includes a pre-condition command for triggering whether an operation on the command may be executed or not; and a post-condition command for triggering performing an additional task after performing a command.
According to still yet to another aspect of the present invention, the printer driver may be an XPSDrv print driver including an XPSDrv filter pipeline utilized within a Microsoft® Windows® operating system, wherein the Microsoft® Windows® operating system is one of Windows Vista™, Windows XP and Windows Server™ 2003.
Furthermore, according to yet another aspect of the present invention, a method for controlling a filter pipeline for a printer driver including a logical page filter, document level filter, job level and physical page filter, and command manager. The method includes processing print tickets in the logical page filter; then simultaneously, performing operations in the logical page filter on logical pages within a first thread, performing document level operations in the document level filter within a second thread, performing job level operations and physical page operations in the job level and physical page filter within a third thread; and generating and managing commands compiled in command lists for the filters, wherein each filter runs within its own thread to perform a specific scope of operations defined for each filter.
Additionally, according to yet another aspect of the present invention, a computer readable medium is provided containing computer-executable instructions for controlling a filter pipeline for a printer driver including a logical page filter, document level filter, job level and physical page filter, and command manager. Here, the medium includes computer-executable instructions for processing print tickets in the logical page filter; computer-executable instructions for then simultaneously, performing operations in the logical page filter on logical pages within a first thread, performing document level operations in the document level filter within a second thread, performing job level operations and physical page operations in the job level and physical page filter within a third thread; and computer-executable instructions for generating and managing commands compiled in command lists for the filters, wherein each filter runs within its own thread to perform a specific scope of operations defined for each filter.
Further embodiments, features and aspects of the present invention will become apparent from the following detailed description of exemplary embodiments with reference to the attached drawings.
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate various embodiments, features and aspects of the present invention and, together with the description, serve to explain the principles of the invention.
Exemplary embodiments, features and aspects of the present invention will now be herein described in detail below with reference to the drawings.
The aforementioned features and aspects of the first exemplary embodiment will now herein be discussed in greater detail below.
The Logical Page Filter 400 processes the Print Ticket and translates printing features into a list of scope based commands using an object created by a Command Manager (CM) 430. These commands will be performed on each filter. The Command Manager (CM) 430 parses the Print Ticket and generates a scope-based Command List 480 which includes a Logical Page Command List (LPCL) 440, a Document Level Command List (DLCL)450, a Job level Command List (JLCL) 460, and a Physical Page Command List(PPCL) 470.
In addition to parsing the Print Ticket using CM 430, the LPF 400 performs the generated command from the LPCL 440. When the LPF 400 receives a page part, it queries an object generated from the CM 430 object to get the logical page operations for the specific page and the LPF 400 executes these commands on the Fixed Page 160.
In particular, after receiving each part in the start operation, the LPF 400 checks the part type. If the part is a Fixed Document Sequence (FDS) 140, the LPF calls the CM 430 to process the part. Then the CM 430 gets the Print Ticket 142 for the FDS part and merges it with a default print ticket and saves the resulting print ticket (Resultant Job Print Ticket).
Next, the CM 430 parses the Resulting Job Print ticket to generate the Job Level Command List (JLCL) 460 and Physical Page Command List (PPCL) 470. If the part is Fixed Document (FD) 150 part, the LPF 400 calls CM 430 to process the FD 150. Next, the CM 430 gets the Print Ticket from FD 150 and merges it with a previously saved Resultant Job Print Ticket, in which the resulting Print Ticket is called a Resultant Document Print Ticket. Then the CM 430 parses the Resultant Document Print Ticket to generate the Document Level Command List (DLCL) 450.
Whenever the LPF 400 receives the Fixed Page (FP) 160, the LPF 400 calls the CM 430 to process the FP part. Here, the CM 430 gets the Print Ticket from FP and merges it with the previously saved Resultant Document Print Ticket, wherein the resulting print ticket is called a Resultant Page Print Ticket.
Then the CM 430 parses the Resultant Page Print Ticket to get a Logical Page Command List (LPCL) 440 for the page. Thereafter, the LPF 400 gets the LPCL 440 from the CM 430 and executes each command on the current Fixed Page (FP) 160 part. When all the commands are executed, the LPF 400 sends out the FP 160 to the Document Level Filter (DLF) 410, and further keeps processing until all the parts are processed.
The Document Level Filter (DLF) 410 is configured to execute document-scope operations such as caching, moving, merging, inserting, deleting pages, etc. within the document. When the DLF 410 gets a Fixed Document 150 part, the DLF 410 queries the CM 430 for the Document Level Command List of (DLCL) to be performed on the subject Fixed Document 150 part. The CM 430 uses its part name and returns the Document Level Command List (DLCL) that will be performed on the subject document upon receiving each page part. It is noted that returning an empty list means that the DLF 410 will simply pass all the parts of the document to the next filter (Job level & Physical Page Filter) through the Inter-filter Communicator 124 (See
The function of the Job Level & Physical Page Filter 420 (JL&PPF) is similar to the DLF 410, except the JL&PPF 420 performs operations across the document boundary. That is to say, Fixed Pages of the job level operations can belong to any document. For example, the JL&PPF 420 can move a page to a different document or merge pages from different documents, for instance.
The aforementioned filters (LPF 400, DLF 410, and JL&PPF 420) are created and executed by the XPSDrv Filter Pipeline service when the Print Job 104 is spooled by the spooler. After the XPSDrv Filter Pipeline service creates filter objects, it initializes each filter by calling an initialization filter function. For example, in the initialization of the LPF 400 (as described in
After initialization is done, the XPSDrv Filter Pipeline service calls for the start operation of each filter for the document processing as described in
First,
Referring to
If at step S1210 parts are available, the process moves to step S1212 where the XPS Document Parts are obtained from the IXps Document Provider interface. In step S1214, it is determined whether there is an XPS Document Part or not. If yes, then the XPS Document Part is sent to the IFC 124 at step S1216, and then the process returns to step S1210 to determine whether any more XPS parts are available. If there is no XPS Document Part in step S1214, then the process proceeds to step S1218.
Instep S1218, it is determined whether there is a Fixed Document Sequence (FDS) 140 or not. If yes, then the Fixed Document Sequence 140 is processed at step S1220 wherein the function F1-P1 is performed (see
In step S1224, it is determined whether there is a Fixed Document 150 or not. If yes, then the Fixed Document 150 is processed at step S1226 where the function F1-P2 is performed (see
In step S1230, it is determined whether there is a Fixed Page 160 or not. If yes, then the Fixed Page 160 is processed at step S1232 where the function F1-P3 is performed (see FIG. 4E; discussed later in the specification). Next, also in step S1232 a Logical Page Command list (LPCL) 440 is returned to be applied to the Fixed Page 160.
Then the LPF 400 determines whether there are any pending commands to be processed (step S1234). If there are pending commands to be processed, then they are executed on the Fixed Page 160 (step S1236) until all the commands in the LPCL 440 are executed. When there are no more commands to be executed, the Fixed Page 160 is sent to the IFC 124 (step S1238), and the process returns to step S1210. Further, if there are no Fixed Pages 160 in step S1230, then the process returns to step S1210. [0071] Therefore, in review, when a part arrives at the LPF 400, first the type of the part is determined as specified in steps S1214, S1218, S1224 and S1230. If it is a XPS Document Part, in step S1214, the LPF 400 sends this part to the Document Level Filter 410 through IFC 124 as in S1216, or it comes to step S1218 where the LPF 400 checks for a Fixed Document Sequence 140 part, and if it is, then in step S1220, the LPF 400 calls the CM 430 to process the Print Ticket of this part. And similarly, in step S1224 it is determined if the part is a Fixed Document Part 150, and finally, in step S1230, it is determined if the part is a Fixed Page 160 or not.
After the Command Manager 430 finishes processing the Fixed Document Sequence 140, the LPF 400 sends out the Fixed Document Sequence 140 to the Document Level Filter 410 through the IFC 124 (step S1222). Then, if the part is a Fixed Document 150, the LPF 400 requests the CM 430 to perform the F1-P2 function as specified in step S1226, for instance.
Referring to
Once the function (F1-P3) is complete, in step S1234, the LPF 400 executes each command in the LPCL 440 on the subject page. When all the commands are executed, the Fixed Page 160 will be sent to the Document Level Filter (DLF) 410 through the IFC 124 (step 1238).
Referring to
In step S1318, it is determined whether there is a Fixed Document Sequence (FDS) 140 or not. If yes, then the FDS 140 is processed at step S1320 where the function F2-F1 is performed. (see
In step S1322, it is determined whether there is a Fixed Document (FD) 150 or not. If yes, then the FD 150 is processed at step S1324 where the function F2-P2 is performed (see
In step S1326, it is determined whether there is a Fixed Page 160 or not. If yes, the FP 160 is processed at step S1328 (see
If in step S1310, there are no parts available from the XPS Document Provider and a request shutdown has been called, it is determined in step S1311 by the DLF 410 whether the Page Cache is empty or whether a request shutdown has been called. If at step S1311 the Page Cache is found to not be empty, the cached pages are processed in function F2-P4 (step S1329) called by the DLF 410 (see
Therefore, in review, when a part is available, its type is determined, and if it is an XPS Document as in step S1314, the XPS Document is sent to the next filter through IFC 124. In step S1318, if it is determined that the part is a Fixed Document Sequence 140 part, the DLF 410 sends the Fixed Document Sequence 140 to the JLF 420 through the IFC 124. If the part is determined to be a Fixed Document 150 in step S1322, the DLF 410 calls the F2-P2 function as described in
The following paragraphs will now herein described the functions F2-P1, F2-P2, F2-P3 and F2-P4). In
In
In step S1344, the DLF 410 resets the Document Level Command List(DLCL) 450, and gets the Document Level Command List(DLCL) 450 for the Fixed Document 150. Then in step S1346, the Fixed Document 150 is sent to the Job Level & Physical Page Filter 420 through IFC 124.
Now referring back to step S1326 in
Further, in step S1364, while executing a command, the Command itself checks for the post-condition. If the post condition is met in step S1364, the processed page is then sent to the JL&PPF 420 through IFC 124 at step S1366.
When a part is available (YES in step S1410), its type is determined in steps S1412 through S1430. In step S1412, the JL&PPF 420 gets the XPS part from Ixps Document Provider. Next, it is determined whether the XPS part type is determined is an XPS Document part (step S1414). If yes, then the XPS Document is sent out through the IFC 124 (step S1416). Then the flow returns to step S1410.
In step S1414, if it is determined that the part type is not an XPS Document part, then it is next determined whether the part is a Fixed Document Sequence (FDS) 140 (step S1418). If yes, the F3-P1 function (see
Otherwise, if in step S1418, it is determined that the part type is not a FDS 140, then, in step S1422, it is determined whether the part is a FixedDocument (FD) 150. If yes, the F3-P2 function (see
If in step S1422, it is determined that the part type is not a FD 150, then in step S1426, it is determined whether the part is a Fixed Page (FP) 160. If in step S1422 the part is a FP 160, the F3-P3 function (see
Referring to step S1410, if no parts are available from the Ixps Document Provider and a request is called, then in step S1430, the JL&PPF 420 again checks the Page Cache to determine whether it is empty. If yes in step S1430, the process ends. Otherwise, if no in step S1430, the JL&PPF calls function F3-P4 in step S1432 (see
Further, in step S1464, while executing a command, Command itself checks for the post-condition. For example, after successful execution, and after merging two pages successfully, the merged pages are sent to further processing for physical page commands. In most of the cases, post-condition can be true of false. A false post-condition means the resulting page will be inserted back into the Page Cache itself. A true post-condition means that after successful completion, the resulting page will be further processed. If the post condition is met in step S1464, the processed page is then further processed by calling the function F3-P5 (see
While the present invention has been described with reference to exemplary embodiments, it is to be understood that the invention is not limited to the disclosed exemplary embodiments. The scope of the following claims is to be accorded the broadest interpretation so as to encompass all modifications, equivalent structures, and functions.
The embodiments described above current describes using Microsoft's Ixps Document Provider and Ixps Document Consumer as input and output interfaces respectively. However, Microsoft also provides IPrintReadStream and IPrintWriteStream as input and output interfaces for the filters. Nevertheless, the present invention also applies for the usage IPrintReadStream and IPrintWriteStream without any change to the core flow described above.
The functions described above can be implemented by a host computer according to a program installed from outside. In that case, the present invention is applicable to a case where information including programs is supplied from a storage media, such as a CD-ROM, a flash memory, and an FD, or from an external storage medium through the network.
A storage medium storing program code of software that executes the functions of the above-described embodiments can be supplied to a system or an apparatus. Then, an aspect of the present invention can be achieved by reading and executing the program code stored on the storage medium by a computer (alternatively, a CPU or an MPU) of the system or apparatus.
In this case, the program code itself read from the storage medium can achieve the functions of the above-described embodiments, and the storage medium storing the program code configures the present invention. Accordingly, any form of program can be used as long as it has a program function, such as object code, a program executed by an interpreter, and script data supplied to an OS.
The storage medium for supplying a program includes, for instance, a flexible disk, a hard disk, an optical disk, a magnet-optical disk, an MO, a CD-ROM, a CD-R, a CD-W, a magnetic tape, a nonvolatile memory card, a ROM, and a DVD.
Besides, as a method of supplying the program, a browser of a client computer can be used to connect to a web page on the Internet. A computer program according to the present invention can be supplied from the web page. Alternatively, the computer program can be supplied from a compressed file including an automatic installation function downloaded into a storage medium such as a hard disk.
Moreover, program code that constitutes a program according to the present invention can be divided into a plurality of files, and each file can be downloaded from different web pages. In other words, a WWW Server or an FTP server allowing a plurality of users to download the program file for achieving the functional processes of the embodiments in a computer is included in the scope of the present invention.
Moreover, the program according to the present invention can be encrypted and stored on a storage medium such as a CD-ROM to be distributed to users. Then, a user who meets a predetermined condition is allowed to download key information for decryption from a web page via the Internet. The user can install and execute the encrypted program using the key information.
Moreover, with program code read and executed by a computer, not only the functions of the embodiments are achieved but also an OS operating on the computer can perform all of or part of the actual processing based on the instruction of the program code. The functions of the embodiments are achieved by the processes described above.
In addition to that, program code read from a storage medium is written to a memory provided in a function extension board inserted in a computer or a function extension unit connected to a computer. Then, a CPU provided in the function extension board or the function extension unit performs all of or part of the actual processing based on the instruction of the program code. The functions of the embodiments are achieved by the above-described processes.
It is further noted that with regard to the LPF 400, DLF 410 and the JL&PPF 420, the order of checking the XPS part type can be changed, and is not necessarily limited to the order illustrated in
The present application is related to U.S. patent application Ser. No. 11/560,715, filed Nov. 16, 2006, entitled “Pseudo-Multithread Framework For XPSDrv Filter Pipeline, the content of which is expressly incorporated by reference herein in its entirety.
