The present invention relates to methods/systems for creating mailpieces, and, more particularly, to a method and system which integrates mailpiece content printing with mailpiece creation to prevent processing errors such as document jamming and/or print feed errors.
A mail insertion system or a “mailpiece inserter” is commonly employed for producing mailpieces intended for mass mail communications. Such mailpiece inserters are typically used by organizations such as banks, insurance companies and utility companies for producing a large volume of specific mail communications where the contents of each mailpiece are directed to a particular addressee. Also, other organizations, such as direct mailers, use mailpiece inserters for producing mass mailings where the contents of each mailpiece are substantially identical with respect to each addressee.
In many respects, a typical inserter system resembles a manufacturing assembly line. Sheets and other raw materials (i.e., a web of paper stock, enclosures, and envelopes) enter the inserter system as inputs. Various modules or workstations in the inserter system work cooperatively to process the sheets until a finished mail piece is produced. Typically, inserter systems prepare mail pieces by arranging preprinted sheets of material into a collation, i.e., the content material of the mail piece, on a transport deck. The collation of preprinted sheets may continue to a chassis module where additional sheets or inserts may be added based upon predefined criteria, e.g., an insert being sent to addressees in a particular geographic region. Subsequently, the collation may be folded and placed into envelopes. Once filled, the envelopes are closed, sealed, weighed, and sorted. A postage meter may then be used to apply postage indicia based upon the weight and/or size of the mail piece.
The capacity, configuration and features of each inserter system depend upon the needs of each customer and/or installation. Until recently, mailpiece inserters were limited to two basic configurations, i.e., low-volume inserters capable of producing between about 5K -10K mailpieces monthly, and high-volume inserters capable of producing in excess of 100K mailpieces daily. To contrast the differences in greater detail, low volume inserters may occupy the space of a conventional office copier and generally will cost less than about twenty-thousand dollars ($20,000). High-volume inserters may extent over 100 feet in length and cost in excess of five million dollars ($5,000,000). Only recently have manufacturers introduced models having an intermediate capacity, i.e., producing between 50K-100K mailpieces monthly. Exemplary models fulfilling these specifications are the DI 900 and DI 950 Model inserters produced by Pitney Bowes Inc., located in Stamford, Conn., USA.
These inserters, whether in the low, intermediate or high-volume classes, typically require the use of “preprinted” sheets which are presented to the various downstream devices by a feed module for subsequent processing. While it has long been desirable to print mailpiece content material “on-demand”, or “just in time”, difficulties associated with matching the throughput, i.e., of the printer and downstream devices, have essentially prohibited printer integration. For example, when the print rate exceeds the processing rate of the downstream inserter devices, e.g., the speed that the machine inserts mailpiece content into an envelope, the sheets of content material either jam or are out-sorted. When the print rate lags behind the throughput rate of such devices, the productivity of the overall inserter degrades or diminishes. Even relatively small deviations in the rate of throughput can result in the aforementioned difficulties. Moreover, the print rate of standard printers, driven by commercially available application software, is essentially fixed. That is, there is no ability to vary the rate of printing for the purpose of synchronizing or matching the print rate to the rate of mailpiece creation.
A need therefore exists for a method and system for throttling the print rate of mailpiece content material to optimize throughput of a mailpiece inserter.
A system and method is provided for processing mailpiece content material in a mailpiece inserter. The system comprises a printer integrated with the mailpiece creation system for receiving/printing print stream data from a software application. The system further includes at least one device disposed downstream of the printer for issuing a signal indicative of the rate that content material is being processed by the inserter. A system controller monitors the throughput rate of the at least one downstream device and issues a command signal indicative thereof. The system and method of the present invention employs a page-based language monitor to throttle the print stream data received by the printer to vary the printing rate of mailpiece content material. Accordingly, the system and method drives the rate of printing to closely match the throughput rate that mailpiece content material is processed/generated by the inserter by the at least one downstream device. Consequently, the throughput of the mailpiece inserter is optimized.
a depicts various elements of the User PC including a virtual driver for converting print stream data of an application into object oriented data for subsequent processing by various system plug-ins/modules.
b depicts a stack of mailpiece content material having an assembly or scan code incorporated in the document for providing instructions in connection with the assembly of the mailpiece by the mailpiece inserter.
The inventive method and systems for printing and producing mailpieces is described in the context of a mailpiece inserter system. Further, the invention is described in the context of DI 900 and DI 950 Model Mailpiece Inserters, i.e., mailpiece creation systems produced by Pitney Bowes Inc., located in Stamford, State of Connecticut, USA, though, the inventive subject matter may be employed in any mailpiece inserter and/or in print manager software algorithms used in the printing/creation of mailpieces such as PBFirst®) (“PBFirst” is a registered trademark of Pitney Bowes Inc), a software product for printing mailpieces processed by a mailpiece inserter system.
Before discussing the invention in greater detail, it will be useful to understand the system architecture of the inserter including the cooperation of the various components and system elements. In
The system elements 10, 12, and 14 may function in a closed- or open-loop operating mode. The principle difference in the operating modes relates to whether the system elements communicate in real-time over a network line NL, or autonomously based upon predetermined algorithms. In a closed-loop operating mode the various system elements communicate to convey, monitor, and record information concerning the fabrication of each mailpiece. That is, the system elements 10, 12, and 14 share and store critical information which will be used to correctly assemble, detect errors/deficiencies in, and reprint, mailpieces. More specifically, the User PC runs prior to processing in the closed loop mode to produce the mailpiece documents and mail run data file while the mailpiece inserter 10 and system server 12 communicate in real-time. In an open loop operating mode, the server 12 is not required hence, the inserter 10 operates autonomously/independently and relies upon preprogrammed information internal to the mailpiece inserter 10 to provide the necessary mailpiece assembly instructions.
Whether operating in a closed- or open-loop configuration, the system architecture 20 employs an assembly instruction code AC (i.e., either a mailpiece or scan code) to communicate information concerning the fabrication of a mailpiece from the user processor 14 to the mailpiece inserter 10. In the context used herein, an “assembly or instruction code AC” (see
The significance of converting the electronic file of the mailpiece content material into to an object-oriented data file and the use of the Mail Creation Print Manager 24 will be discussed in an introductory section entitled “System Architecture & Print Stream Modification”. This introductory section provides a fundamental understanding of the Sebring system architecture along with certain features which enable its efficient/unique operation. Further, the introduction provides a basic framework within which the invention(s) may operate, though invention(s) may be adapted to other system architectures and/or a various printer programs.
Thereafter, the discussion comprises a first section entitled “Printer Integration & Throttling” and a second section entitled “Regeneration of Mailpiece Content Material”. The first section describes a method and system for selectively throttling and storing printed pages for “on-demand” printing and mail creation while the second section describes a method for automatically regenerating mailpiece content material which may have been out-sorted due to an error identified in the mailpiece content.
In the Sebring mailpiece inserter, mailpiece content material is produced from an electronic application file indicative of a logical document. The method for producing the content material comprises the steps of: (i) producing an electronic file of content material from the specific software application (ii) generating print stream of data from the electronic file in a renderable format, (iii) converting the print stream into object-oriented data having defined objects, the objects defined or indexed by an object dictionary, (iv) parsing or segmenting the object-oriented data into a plurality of data sets, each data set comprising at least one data packet, (v) attaching the object dictionary to each data set, (vi) processing the data sets to create at least one logical document and (vii) printing the logical document for use in combination with a mailpiece inserter system.
Referring to
In step B, the operator inputs a print command which causes the application to generate a print stream of renderable data. That is, a Graphics Device Interface (GDI) applicable to a Windows-based Operating System (OS) is used by the application to appropriately render the text and graphics of the mailpiece content material. The GDI functions can be used to draw text, create paths, and generate bitmap & graphic images (e.g., lines, curves, closed figures, etc.). Furthermore, the application software can use the GDI functions to set operating modes and make current selections for an output device, e.g., a printer or video display. The operating modes may include: (a) the text and background colors, (b) the mixing mode which specifies how colors combine with colors already existing on the display surface, and (c) the mapping mode which dictates how coordinates used by the application software are mapped relative to the coordinate system of the output device. The current selections may identify which drawing objects (e.g., pens, brushes and fonts) are to be used. Inasmuch as the code/algorithms to generate such attributes are generally known to those skilled in the art, such program code is not discussed in greater detail herein. It is suffice to say that the attributes are defined using such devices as a GDI (or similar program code) for rendering the print stream data.
In step C, the Print Stream Data (PSD) rendered by the GDI (see
Returning to our discussion of Step C, the print stream data PSD is intercepted and manipulated by a Mail Creation Print Manager and associated Plug-in modules in preparation for printing by a conventional printer driver 30. More specifically, in
The print stream data PSD is then parsed or segmented into a plurality of data sets which may each comprise one or more data packets. The number and size of the data sets are generally determined by the size of an individual page of the original document though the data packets may be smaller and contain multiple packets (e.g., two or more) for comprising a data set. In step D, the dictionary is attached/coupled to each data set, hence resulting in multiple data sets each having a shared object dictionary. The object dictionary may be common to many of the data sets, or may be individually modified or configured to index/identify the objects of a specific data set/packet. Hence, by attaching a configurable dictionary to each data set/packet the individual data sets/packets may be specifically, modified and manipulated.
By segmenting the print steam data into a plurality of data sets (each having an attached/coupled dictionary), throughput of the mailpiece inserter is significantly enhanced. That is, by segmenting the PSD into smaller units, the printer driver can begin incrementally printing of the segmented data. Accordingly, printing can begin before the entire electronic file and dictionary contents are completely processed (the dictionary is typically appended to the end of the electronic file). Furthermore. conversion of the print stream data into Object-Oriented Data OOD provides a unique opportunity to enable and perform manipulation of the print stream data PSD from the application software. For example, the OOD enables the user/system operator to define regions within the document, read from identified regions, extract information from select regions, perform operations on information contained in a specific region, insert new information (e.g., insert scan codes), re-order pages of the mailpiece contents, change its pagination, add and/or delete pages from the mailpiece contents, etc. Consequently, the object-oriented data provides significantly greater flexibility and capability to modify, manipulate, insert and/or extract information in connection with content material production/mailpiece fabrication than has been heretofore been directly available to the user/system operator. Furthermore, in the context of a mailpiece inserter, such capability was only available through the combined efforts of the OEM, skilled in the programming language used to operate the mailpiece inserter, and the customer having knowledge concerning the unique requirements and purpose of the mailpiece run data file.
A server application 24SA is then employed to reconstitute the object oriented data and dictionary OOD into individual pages, i.e., the predetermined smallest building block of the mail run data file. Next, the Plug-in Manager 24 PI divides and tracks the data as pages, documents, or mailpieces depending upon the optimization and timing requirements. Such PI managers are well-known in the art for optimizing and timing the throughput of data, hence no further discussion of the optimization algorithms are provided nor such details warranted.
Additionally, various modules or Plug-Ins 24XX are adapted to modify, manipulate and print the data pursuant to the requirements of a logical document. A logical document is any compilation of data arranged in accordance with the commands and controls implemented by the various plug-ins. Finally, the OOD is converted back into renderable data recognizable by the specific printer driver 30 which converts the OOD into the necessary printer control language PCL for being printed using conventional printer hardware.
In Step E, an assembly/scan code AC is defined indicative of the instructions for each of the mailpieces 28. To develop and execute the assembly code AC, the plug in manager 24 (see
To produce an assembly/scan code AC, the Mailpiece Print/Plug-in Manager 24 includes an Assembly/Scan Code Generator plug-in 24CG which converts various user/system operator commands into a symbolic representation (e.g., a numeric identifier, OMR marks or Barcode Symbology). These symbolic markings are recognizable by the mailpiece inserter 10 for performing various assembly instructions. More specifically, the Mailpiece Print/Plug-in Manager 24 processes input commands by calling upon the appropriate plug-in(s) capable of processing specific input commands. Examples of input commands may be represented by an assembly/scan code, or a portion thereof, include, (i) document breaks, i.e., where a document begins and ends using a Document Break plug-in, (ii) document printing, e.g., whether the document is printed on a single side or is double-sided by employing a Duplex Printing plug-in, (iii) document combinations, e.g., documents having identical addresses may be combined into a single envelope using a Document Selection plug-in, and (iv) document rules, e.g., documents having an invoice total exceeding a threshold value may receive an insert as determined by the mailpiece creation plug-in using the Rules Engine. The Mailpiece Print/Plug-in Manager 24 then produces/selects an assembly/scan code configuration which symbolically represents the various input commands. The assembly/scan codes AC may take a variety of forms including a series of long and short bars (OMR marks) disposed at a predetermined location or region of the PDF document. Typically such marks SC will appear in the right- or left-hand margin of a document (see
In step F, the object-oriented data file, including the scan code data (produced in by the Mail Creation Print Manager & Plug-ins 24 shown in
For thoroughness of discussion, the Plug-in Manager 24PI may receive object oriented data from one of two paths. The path described in the preceding paragraphs relates to the “print interception path” (i.e., the steps A-E above). Therein, a print command is executed or input to the application 22, the print stream data is intercepted, segmented/manipulated into a plurality of object-oriented data sets, and provided to the plug-in manager for subsequent processing, i.e., processing by the various plug-ins. As mentioned before, this path enhances throughput and flexibility to manipulate data. Alternatively, object oriented data, e.g., a PDF file FB (see
While mailpiece content material 28 can be printed, stacked and fed to the mailpiece creation system or mailpiece inserter 10IP via a plurality of input trays 36a, 36b, 38a, 38b, an equally viable system includes an integrated printer. When integrating a printer with a mailpiece creation system, several requirements/objectives should be met or obtained. First, to ensure maximum throughput, the system should minimize time gaps between a request for printing and the generation of printed content material. Second, inasmuch as the printer for such devices is commonly a costly, high-output device, it is desirable for the system to include a means for the printer to operate independently or in conjunction with the mailpiece inserter. Thirdly, to the extent that various application software may be employed to generate print jobs, it is desirable to affect integration of the printer without modifying or corrupting the print driver code. Finally, pages should be self-contained, i.e., containing all necessary data and information necessary to print an individual page of a mailpiece document. With respect to the latter, such requirement is necessary (as will be more clearly understood when discussing page regeneration) to reprint an individual page (e.g., missing, mis-fed, or damaged content material) automatically or “on-the-fly” without the requirement to reprint the document or entire print job. These requirements/objectives are discussed and met in the subsequent description.
In
The inventive system for processing mailpiece content material, or otherwise referred to as a print integration system, includes an inserter control system or controller 12IP operative to monitor the throughput rate of the at least one downstream devices. In
The rate of change of the position signals 52 issued by the page buffer 46 may be used by the controller 12IP to determine the throughput rate that content material being processed. Generally, it is the objective of the system controller 12IP to drive the printer 44 to generate material content at a rate consistent or commensurate with the rate of processing by other downstream devices of the mailpiece creation system 10. While, in the described embodiment, the downstream device is a page buffer 46 for issuing position signals 52 to generate a rate of throughput, it should be appreciated that any downstream device may be adapted to issue a throughput signal indicative of the rate that content material or mailpieces are processed by the inserter 10IP. In
The system controller 12IP monitors the throughput rate data and issues command signals 62 indicative of the number of pages to be printed by the integrated printer 44. More specifically, the command signals 62 are indicative of a specific page number to begin printing along with the number of pages to follow. For example, the controller 12IP may issue command signals requesting the printer to generate page number thirty (Page # 30) plus five (5) additional pages of data. Before this request is issued to the printer (in the more conventional sense), the controller 12IP issues the command through a page-based language monitor 64. In the preferred embodiment, the system controller 12IP generally issues a command signal to print between three (3) to seven (7) pages with each request, though several command signals may be generated within a very short period of time.
In the described embodiment, the mailpiece inserter includes a User Interface Module (UIM) 66 interposing the mechanical page buffer 46 and the system controller 12IP. The UIM 66 is responsive to the position signals 52 of the mechanical page buffer 46 for determining when additional content material 28 can be accepted by the page buffer 46. Furthermore, the UIM 66 is operative to issue a request signal 68 to the system controller 12IP which request signal 68 is indicative of the number of mailpiece content pages 28 to the printed. Hence, conversion of the position signals 52 to a command signal 62 may be performed by either the system controller 12IP or the UIM 66, depending upon where the program logic or intelligence therefore is located. It should be further appreciated that while a request may be made by the UIM 66, the controller 12IP may have received a message that the print job, i.e., determined at the User PC 14IP, is complete. Consequently, in this instance, the controller 12IP will not forward a command signal 62 to the language monitor 64 for issuance to the printer 44.
The page based-language monitor 64 (hereinafter the “language monitor” or “LM”) receives print stream data from a page-based print processor 70 and is interposed between the system controller 12IP and the dedicated printer 44. In the broadest sense, the language monitor 64 is the gate-keeper of data communicated to the printer 44 from the controller 12IP. More specifically, the language monitor 64 retains material content data, including an object-data dictionary, for each page of material content and triggers the printer 44 to generate a particular page along with N number of additional pages. While this request to print is made by the controller 12IP, the language monitor 64 contains the active program code which intercepts the print stream data, i.e., the print control language (PCL) data, from the printer driver to throttle the rate that content material is generated.
More specifically, the page-based language monitor 64 is operative to vary the flow of print stream data to the printer 44 vary the production rate of mailpiece content material. More specifically, the language monitor 64 includes a buffer file capable of storing 300 MB (300,000,000 bytes) of data. The buffer file is capable of storing multiple pages of data, including duplex pages. Hence, in the context used herein, a “page” of data includes all data which may be found on a two-sided sheet of paper.
The language monitor 64 is not tied to any print driver. As such, the language monitor 64 can operate without impacting the function of any print driver which may be employed. As will be appreciated in the subsequent section concerning page regeneration, the language monitor 64 also functions to move and/or erase data from the buffer to assist in regeneration. In the preferred embodiment, the page-based language monitor 64 communicates with the printer 44 across a USB line.
In operation, the application software 22IP produces an electronic version of the mailpiece content material 28IP and includes print program code for generating print stream data indicative of the mailpiece content material 22IP. In the context used herein, “print stream data” is any stream of data originated by the application software and sent to the integrated printer 44. Hence, print stream data includes data issued to the spooler, sent from the spooler to the print driver (sometimes referred to as spool data), transmitted from the print driver to the print processor (sometimes referred to as PCL data), or from the print processor to the integrated printer 44. Generally, the data is transmitted to a spooler 72 having a spool file (not shown in
The principle function of the print processor 70 is to segment the print stream into data packets indicative of a self-contained page of mailpiece content material. In the context used herein, a “self-contained page of data” is a data set/packet of all data contained in a single page of content material including an object-data dictionary associated with the page of content material. Accordingly, the page has all of the necessary components/elements, including a dictionary of the page objects (e.g., font, size, spacing, margin information, formatting, etc.) required for printing. Furthermore, the print processor 70 parses the print stream so as to create a new print job for each page. In this way, the application software 22 and/or print spooler PS automatically attaches an object-data dictionary to each page of data. As an aside, each “self-contained page” is analogous to the “logical document” defined in the previous section entitled “System Architecture and Print Stream Modification”.
The operation of parsing the print stream into stand alone pages is well-within the ability of a skilled artisan, though, it may be simply implemented by introducing a “StartDocPort” command to indicate that a new print job has started, a “WritePort” command to spool a new page, and an “EndDocPort” command to end the print job. A new buffer file is created in the language monitor 64 with each new page/print job created or each time the spooler 72 calls the “StartDocPort”, “WritePort”, and “EndDocPort” commands. To prevent the spooler 72 from closing the print job after the last page has been sent to the language monitor 70 a “Wait” command is introduced by the language monitor during the processing of the EndDocPort Command. As such, the page data will remain in the buffer file as the print stream/printed pages are throttled by the language monitor 64. As a result, the application software will complete processing. though the operating system will continue to waits for the EndDocPort command to complete processing. The buffers files containing the page files and object-data dictionary remains intact, i.e., for subsequent manipulation such as throttling and/or page regeneration. It also provides the ability to determine when the spool file is deleted based upon the external commands of the system controller.
A limitation to data transmission speed along a USB cable relates to the total amount of data being sent in a print job. That is, a USB cable is generally limited to data transmission in data sets or packets of about 4 kB. Inasmuch as a self-contained page having an attached data dictionary a far greater amount of data, e.g., 15 KB wherein 5 kB may be associated with the data dictionary, the controller or processor must break the data into manageable packets or data sets, e.g., four data sets each containing 3.25 kB to transmit a single. It will therefore be appreciated that a transmission requiring hundreds, or perhaps thousands of pages, can significantly degrade transmission performance.
While the print processor 70 of the present invention breaks the print stream into self-contained pages, the method of the present invention sends the data dictionary once. That is, for each print job, the language monitor 64 transmits the page data for the entire job, but sends the data dictionary only once, i.e., with the first printed page of a job run. Comparing the amount of data associated with this method of data transmission to one which may require thousands of pages each having a dedicated data dictionary, the throughput along the USB cable can be increased by as much as twenty percent (20%).
Once the system controller 12IP communicates that a page has been successfully printed and/or processed, the language monitor 64 saves data associated with a self-contained page, one containing the page data and associated data dictionary, to a storage device such as a hard disk. Thereafter, when the controller communicates that printing has been unsuccessful or that a page, or several pages, has been damaged or otherwise mishandled (i.e., processed unsuccessfully), the language monitor 64 retrieves the self-contained pages, for the purpose of regeneration. While the transmission of these pages will each contain a data dictionary, it can be presumed that the number of pages to be printed, and the amount of additional data to be carried, is sufficiently small such that any degradation (i.e., speed reduction) in data transmission speed can be tolerated.
The method for regenerating pages is best understood by reference to
In step DR, the page-based language monitor 64 stores the newly created print jobs into an electronic buffer. As mentioned earlier, the size of the electronic buffer is about 300,000,000 MB, though the buffer may be any size and depends upon the spooler page limit. In step ER, the language monitor 64 truncates or deletes the object data dictionary from all but one print job or the first printed page. As such, data transmission across or through the USB cable to the printer is optimized, i.e., by minimizing the data being sent. After the data is prepared, in step FR, the language monitor 64 sends the print stream/print page signal 74 to the printer for printing the content material during a first data transmission. Once the page has been successfully printed, in step GR, the language monitor 64 moves the data from the buffer file to a storage device such as a hard disk. As such, this step eliminates the requirement to track when pages have or have not yet been printed. That is, it eliminates the requirement for tracking logic or other program code to perform this task. It also clears the buffer to accept more print stream data for subsequent processing.
In step HR, the system controller 12IP determines whether the printed pages have been successfully processed. If the pages have been successfully processed, no further action is required, however, if certain pages have not been successfully processed system controller 12IP will determine which pages may have been effected, e.g., by a pager jam. The system controller 12IP will then, in step, JR, search the buffer and/or storage device for the self-contained page data associated with the unsuccessfully processed pages. Assuming the operator has selected an “automatic page regeneration” option, (i.e., this option is typically made via the User Interface Module 66, a second data transmission is issued to the integrated printer, in step KR, to regenerate the unsuccessfully processed pages.
During development, another design difficulty was uncovered relating to the manner in which software developers, such as the Microsoft Corporation, envision the way customers desire to print material. That is, most operating systems, such as the MS Windows OS, design application software to print material on a “document” basis. Furthermore, the documents envisioned are of a certain size, i.e., generally less than about 200 pages per document. Moreover, such developers assume that when a print request is made, the operator desires to print an entire document, rather than specific pages of the document (although some accommodation is made to print specific pages of a document).
On the other hand, customers in the mailstream industry, produce thousands of pages of mailpiece content material. Hence, a document for such operators includes an entire job run comprising each of these mailpiece pages. Furthermore, such operators may require that individual pages of a mailpiece be printed. Moreover, these operators may require that such pages be printed automatically when pages are misprinted, damaged or otherwise mishandled.
The MS Windows OS sends software application print stream data to a spooler having a spool file. Generally, this spool file is capable of rendering about 2 GB (2,000,000,000 bytes) of data which is the total available data space for a document, or when printing mailpieces, a print job. Generally, the entire document of the application software is processed, sent to the spool file, and then to the printer. Inasmuch as the data resides in the spool file, the application software can be used to produce yet other documents. Furthermore, the printer continues to print even after the application software has received a “print job completed” message.
While this method is adequate for printing conventional, relatively small documents, it is poorly-suited for mailpiece print jobs, i.e., jobs containing thousands of pages wherein individual pages thereof may require regeneration. For example, if an operator wishes to reprint an individual page using conventional operating system architecture, the operator must either reprint the entire document or send additional data to the spool file associated with the individual pages to be regenerated. This is required inasmuch as once the program code message “print job completed”, or “EndDocPort”, is received, the page data and data dictionary associated with that page is erased. It should be appreciated that the data dictionary for page is generally located at the beginning or header of a document and is associated with the “entire” document, rather than “individual pages” of the document. Hence, even if the data associated with an individual page were retrievable, the data dictionary would generally be lost (i.e., being located at the beginning of the data stream).
Accordingly, the inventors of the present invention introduced or, more accurately, substituted, the aforementioned page-based language monitor 64 and page-based print processor 70 for a conventional language monitor and print processor to enable page-based printing for both throttling and page regeneration. That is, without a page-based print processor and language monitor 64, it would not be possible to request that individual pages (e.g., pages five through nine) be throttled for printing to match the inserter throughput rate. Furthermore, without the same elements, it would not be feasible to automatically or immediately regenerate individual pages, as may be required when pages are damaged.
In summary, the inventive system and method intercepts and throttles the print stream to optimize the throughput of a mailpiece creation system. Furthermore, the invention facilitates the creation, modification and printing of mailpieces produced by a mailpiece inserter. Print stream throttling is enabled by a page-based language monitor 64 and page-based print processor 70 to facilitate the storage and printing of individual pages irrespective the initial print stream data produced by the application software. Furthermore, the self-contained pages can be printed “on the fly” without the requirement for multiple manual operations such as selecting the reprint items/pages, printing on and external printer and rerunning the print job. It will therefore be appreciated that the throughput of mailpiece content material is substantially enhanced by the system and method of the present invention
It is to be understood that the present invention is not to be considered as limited to the specific embodiments described above and shown in the accompanying drawings. The illustrations merely show the best mode presently contemplated for carrying out the invention, and which is susceptible to such changes as may be obvious to one skilled in the art. The invention is intended to cover all such variations, modifications and equivalents thereof as may be deemed to be within the scope of the claims appended hereto.
This patent application relates to commonly-owned, co-pending application Ser. No. ______ (Docket No. G-308) entitled “METHOD FOR REGENERATING MAILPIECE CONTENT MATERIAL IN A MAILPIECE CREATION SYSTEM”.