Book assembly process and apparatus for variable imaging system6952801Abstract The present invention is useful for assembling a book. The inventive method includes the steps of specifying pagination information including an indication of whether a page is to be selectively included in the book, determining whether the page is to be assembled into the book based on the pagination information, and generating page description language instructions for production of the book in accordance with the pagination information. Claims 1. A method of assembling first and second different books, the method comprising the steps of: Description TECHNICAL FIELD
In the example of FIGS. 6a and 6b, the field names ADDRESSLINE1 through ADDRESSLINE5, BARCODE and TOWNSORT may appear in the area 112 and one or more of the field names PRICE1, IMAGE1 AND PRICE2 may appear in the area 110. The COPIES field may be used as a control code to select the number of book copies to be produced. Once the template file(s) 106 and the database 108 are assembled, the programming of FIGS. 10a-10f may be executed by the control unit 52 to create the master page file 122, the final variable page files 137 and 138, and the press command file 140. Referring first to FIG. 10a, a block 170 prompts a user to select a template file 106 and a block 172 opens the database 108. A block 174 then reads and stores in a list the database field names for later reference and a block 176 prompts a user to enter information indicating a section number and whether pages are to be printed in simplex (i.e., single-sided) or duplex (i.e., double-sided) format. The section number identifies the order in which multiple sections are to be processed for a particular book. The user may also be prompted to enter a selective processing code identifying a particular book version to process if multiple versions are to be produced during a single press run. Following the block 176, a block 177 begins the process of stripping variable information from the template file opened by the block 170 to obtain the stripped master file 120 of FIG. 5. The block 177 selects a first page for processing and a block 178 checks to determine whether there are any images in the template file and, if images are located, a block 180 selects a first image. A block 182 identifies the file name for the image and a block 184 checks the field list to determine whether the file name is included therein. If the file name for the image is included in the field list, then the image comprises variable information and a block 186 deletes the image block. A block 187 then identifies and saves the image box location on the page, the characteristics of the image box, such as the size, skew, background color and subname and the like and further saves the field name of the image from the database 108. Also, a counter in the memory 53 which tracks the number of variable image boxes on the page is incremented. Otherwise, if the block 184 determines that the file name is not in the field list, then the image contains only master information. A block 188 then also saves the image box location on the page and the characteristics of the image box. Also, a counter in the memory 53 which tracks the number of master image boxes on the page is incremented. A block 189 then checks to determine whether all images have been processed. If not, a block 190 selects a next image and control returns to the blocks 182-189. Control remains with such blocks until the block 189 determines that all images have been processed and control then passes to a block 192. Control also passes to the block 192 from the block 178 should the latter determine that there are no images in the template file. The block 192 determines whether any text boxes are present in the open template file. If at least one text box is present, a block 194 selects and parses a first text box and a block 196 (FIG. 10b) checks to determine whether the text box includes at least one of the field names of the database 108. If so, then it has been determined that the text box includes variable information and a block 198 deletes the text box. A block 199 then stores the text box location, the insertion points in the text box at which variable information is to be printed and the characteristics of the text box and the field names of the database 108 identified in such text box in the memory 53. In addition, a variable text box counter is incremented representing the number of variable text boxes appearing on each page. Otherwise, if the block 196 determines that the text box does not include any field names from the database, then the text box contains only master information. A block 200 stores the text box location in the memory 53. In addition, a master text box counter is incremented representing the number of master text boxes appearing on each page. Control then passes to a block 202, which checks to determine whether all text boxes in the template file have been processed. If not, a block 204 selects and parses the next text box in the template file and control returns to the blocks 196-202. Control remains with such blocks until all text boxes have been processed, whereupon a block 206 determines whether all pages have been processed. If not, a block 208 selects a next page and control returns to the block 178 (FIG. 10a). Otherwise, a block 210 saves the resulting file as the stripped master file. Alternatively, if a page contains a lot of formatting information (i.e. tabs, fonts, etc.), a rich text file (which includes such formatting information) may be created offline from the database. The text box may then open the rich text file and read the information from the file. The use of the rich text file speeds up the processing time. Also, once a placeholder on a page has been "filled in" with information from the database field, the program may mark the corresponding text or image box as "touched." Thus, if the text or image box is "untouched," the program can skip processing of that text or image box, also speeding up the total processing time. Control also bypasses the blocks 194-202 and proceeds directly from the block 192 to the block 206 if the block 192 determines that there are no text boxes in the open template file. Following the block 210, a block 212 converts the stripped master file into the PDL master page file 122 of FIG. 5. At the same time, an initialization (or INI) file may be created. The format and existence of the INI file depends on the type of demand printer utilized. For example, the DocuPrint demand printer does not require the use of an INI file. However, the Barco RIP requires the use of an INI file. The INI file (in ASCII code) for the Barco RIP is created according to the following format:
For the DocuPrint (or any other demand printer which does not use an INI file), a queue is created which contains the same parameters (and potentially additional parameters which may invoke the functionality of an inline finisher, or other apparatus) as the INI file. Following the block 212, a block 214 then reopens the same template file originally opened by the block 170 and deletes all the master image and text boxes. A block 216 than saves the resulting file as the stripped variable file 126 of FIG. 5. A block 218 then creates a temporary file containing a table of the current page number and a number representing the name of the database field placed by the block 154 at the insertion point. The file is called, for example, *.VARS (where * is a user-selected file name). The *.VARS file thus contains pairs of page numbers and database column numbers that indicate where in the database variable information for the page comes from. For example, the *.VARS file may contain the following information:
In the example above, page 1 contains variable data from column 7 of the database, page 8 contains variable data from column 43 and page 11 contains variable data from column 46 and 47. Further, the *.VARS file may contain separate pairings for images and text. Control then passes to block 242 (FIG. 10c) which creates a working copy of the stripped variable file 126. A first page having variable data thereon is selected and data representing the remaining pages in the file are deleted by a block 244. In the example of FIGS. 6a and 6b, the block 244 creates a file defining the front cover of a book with all fixed information deleted therefrom and an area reserved for variable information. Following the block 244, a block 246 selects a first record in the database 108 and a block 248 reads the record. An optional block 250 checks to determine whether a selective processing code has been entered by the user indicating that the page is to undergo selective page processing. As noted above, the apparatus and method of the present invention may be utilized to produce not only books of a single version (i.e., where corresponding pages differ only in terms of the variable information stored in the database) but also books of different versions. In the latter case, the books of different versions have different fixed and variable information. The fixed and/or variable information may vary in terms of content or appearance (i.e., style, location, rotation, position, etc.) or both in different versions. If the block 250 determines that selective page processing is to be undertaken, then a block 252 checks to determine whether the database record read by the block 248 is to be utilized on the page currently under consideration. The block 252 accomplishes this by checking the version identification field in the database to determine if that version is being used. If this is not the case, a block 253 checks to determine whether the record currently under consideration is the last in the database. If so, control passes to a block 294 of FIG. 10e. Otherwise, a block 254 selects a next record in the database 108 and control returns to the block 248 where the next database record is read. If the block 250 determines that selective page processing is not to be undertaken, or if the block 252 determines that the record read by the block 248 is to be used in the page currently under consideration, a block 256 duplicates the data representing the page remaining after execution by the block 244 to initiate development of one of the files 130 or 132. In the first pass through the program of FIG. 10c, and in connection with the example of FIGS. 6a and 6b, the block 256 creates the file 130 and develops page data representing a first version of the page P1-a and adds further variable information to such page data during immediately succeeding passes through the program. Thereafter, data representing the remaining pages P1-b, P1-c and P4-a through P4-c are created and variable information is added to such pages serially during subsequent passes. A block 258 checks to determine whether there are any image boxes on the page and, if so, a block 260 selects a first image box. A block 262 then inserts the image identified by the database field into the image box. A block 264, FIG. 10d, checks the subname to determine whether the block 162 of FIG. 9 has indicated that the image should be sized to fit the image box. If this is true, a block 266 performs the scaling. Otherwise, a block 268 positions the image in the image box at the position specified by the user and a block 270 checks to determine whether all image boxes have been processed. Control also passes from the block 266 directly to the block 270, thereby skipping the block 268. If not all image boxes have been processed, a block 272 selects a next image box on the page and control returns to the blocks 262-270 so that remaining image boxes are serially processed. Once the block 270 determines that all image boxes have been processed, or immediately following the block 258 of FIG. 10c if no image boxes are found on the page, a block 274 checks to determine whether there are any text boxes on the page and, if so, a pair of blocks 276, 278 select a first text box and a first insertion point in such box. Blocks 280, 282 and 284 serially insert text data stored in the database 108 at the appropriate insertion points in the text box. Once all of the variable text data have been inserted into the text box, a block 286 recomposes all text in the text box so that the text obtains a neat finished appearance. The recomposition process is automatically undertaken by the QuarkXPress® program once the variable information is inserted into each text box. The recomposition process is responsive to the user commands as applied to the template file page, such as left, right, center, or full justification, hyphenation and the like. Following the block 286, a block 288, FIG. 10e, checks to determine whether there are remaining text boxes to be processed on the page and, if so, a block 290 selects the next text box on the page and control returns to the blocks 278-288 to insert text information into such text boxes. Once the block 288 determines that all text boxes for the page have been processed, the programming required to produce one of the pages of the file 134 of FIG. 5 having variable information only thereon is complete. A block 292 then determines whether all records in the database have been considered for inclusion in additional variable pages of the file 134 to be produced. If not all records have been considered, control returns to the block 254, FIG. 10c, where the next database record is identified and read. On the other hand, if all pages of the file 134 have been produced by considering all records in the database 108, a block 294 converts the file data into Postscript® or another PDL format to create the variable page file 137 of FIG. 5. Also, an INI file is created as before, except that the "duplex" or "twinplex" parameter is set to command simplex printing only. If necessary or desirable, should the press run length exceed a certain limit, the programming may be modified to create more than one variable page file for each variable page of the template file. Following the block 294, a block 296 checks to determine whether there are other variable pages in the stripped variable page file to be processed. If this is true, a block 298 retrieves a copy of the stripped variable file, selects the next variable page therein and deletes remaining pages therefrom. Control then returns to the block 246 of FIG. 10c. In the example of FIGS. 6a and 6b, the back cover P4 and the corresponding pages of the remaining books are now selected for processing. In the fashion noted above, a file representing the variable portions of such pages is produced by developing the file representing the pages P4-a through P4-c and inserting the database information into such file to obtain the variable page file 136 and the PDL version 138. Following generation of the variable page files 134, 136, and 137, 138 control passes to a block 300 which checks to determine whether a press command file has already been created. If not, a file is created by a block 302 having placeholder comments indicating where in the press command file individual press commands are to be placed for each book to be produced. The press command file may also include data from one or more fields of the database 108 identifying an intended recipient of each book to be produced to assist in reproducing books found to be defective or to produce sample books. At this point, the press command file for the example of FIGS. 6a and 6b may be as follows (using data from the sample database set out above):
Following the block 300 (if the press command file already exists) or the block 302 a block 304 selects the first database record and a corresponding first record in the press command file. A block 306 then checks to determine whether the template file currently being processed includes the selected database record. If not, a block 308 determines whether all pages have been processed, and if this is not the case, the next record in the database 108 and a corresponding record in the press command file are selected. Control then returns to the block 306. If the block 306 ascertains that the template file includes the selected record, a block 312 inserts an indication of the section number in the press command file at an appropriate point if the section number is not already present. If the section number is present already, the press command identified by the section number entered by the user at the block 176 is identified to be overwritten at a later point. The press command file now appears as follows for the example of FIGS. 6a and 6b:
Following the block 312, a block 314, FIG. 10f, selects a first page of the section and a block 316 checks the state of a flag stored in the memory 53 to determine whether a simplex or duplex job has been requested. If a simplex job has been requested, the file name and page number of the master page file and, if variable information is to appear on the page, the file name and page number of the variable page file for the selected page are stored as a single set pair in the memory 53 by a block 318. The determination of whether variable information is to appear on the selected page is accomplished by summing the contents of the variable image box counter and the variable text box counter as incremented by the blocks 220 and 234 of FIG. 10b. A block 320 checks to determine whether all pages have been processed and, if not, the next page is selected by a block 322 and control returns to the block 316 for processing of such page. If all pages have been processed, control passes to a block 324 which determines whether all database and press command records have been processed. Control also passes to the block 324 if the block 308 determines that all pages have been processed. If not all records have been processed at this point, control returns to the block 310 where the next records in the database and press command file are selected. If the block 324 determines that all records for the current section have been processed, a block 326 determines whether another section is to be processed and, if so, control returns to the block 170 of FIG. 10a. If there is not another section to be processed, the press command file has been fully assembled, and hence the process terminates. If the block 316 determines that a duplex job is to be effected, control passes to a block 328 which stores in the memory 53 a command identifying the file names and page numbers of the master page file (as well as corresponding information relative to variable page files, if variable information is to appear) as two-set pairs. Control from the block 328 then passes to the block 320 described above. The result of the programming of FIGS. 10a-10f is a press command file having a sequence of press commands which cause printing of pages in a desired order. In order to print the sample pages of FIGS. 6a and 6b, the press command file would read as follows:
In the foregoing example, "file.m" is a file name identifying the master page file 122 and "file.v1" and "file.v4" are file names identifying the variable page files 137 and 138, respectively. The number following each file name designates a particular page of the file identified by the file name. Thus, for example, "file.m"1 designates the first page of the master file "file.m" and "file.v1"2 designates the second page of the variable page file "file.v1." The @ sign means to associate the pages of the files linked by such sign (i.e. overlay the variable pages on the master pages). The vertical line in the commands indicates that the page(s) on the left side of the vertical line are to be printed on the front side of a piece of paper whereas the page(s) on the right side of the vertical line are to be printed on the reverse side of the piece of paper. In an example of simplex printing, no file name would appear to the right of the vertical line in each command. FIG. 11 illustrates the programming implemented by the control unit 52 to generate a page description language instruction set specifying which pages should be printed and how the pages should be positioned (or imposed) for printing. The page description language instruction set may be incorporated into the press command file 140 or may be provided as a separate file to the print system 79. For purposes of illustration, the page description language instruction set is written in Postscript® in the format dictated by the Xerox DocuPrint printer. Further, the instruction set is directed to books printed in "saddle stitch" imposition format (i.e. 2 pages on each side of sheet) as explained in connection with FIGS. 6-8. It is understood, however, that the invention could easily be modified for use with a different demand printer (i.e. the Xeikon Barco printer) and/or imposition format (i.e. 4 pages on each side of sheet). Referring to FIG. 11, the programming begins at a block 340 which prompts a user to specify certain information to be used to paginate the book. A variable ("MAXPGS") representing the maximum number of supplied pages that may or may not be assembled into a single book during the job is specified together with the identification of a filler page that may or may not be printed and assembled in a book either on a left-hand or a right-hand portion thereof. Also, the user is prompted to specify for each page whether such page will be forced to be on the left side of a book, the right side of a book or will not be forced to a particular book side. In the event a page is to be forced to a side, the user is prompted to specify the page file name and page number for a filler page to precede the forced page. Still further, the user is prompted to specify for each page whether such page is:
In so specifying the foregoing, the user creates a pagination file (called, for example, *.PAG, where * indicates a file name selected by the user). A sample window generated by the block 340 to prompt a user for the information needed to create the pagination file is shown in FIG. 12. Referring again to FIG. 11, following the block 340, a block 342 opens the press command file 140 and a block 344 selects the appropriate database files, including the variable information file (*.vars), the pagination file (*.pag), and (optionally) a barcode file. As set forth above, the *.vars file is a temporary file of pairs of page numbers and database column numbers that indicate where in the database variable information for the page comes from. The barcode file is a page description language file (for example, a PostScript® file) which contains instructions for printing the sequential page numbers and/or a tracking bar code on the pages of the completed book. The barcode file will be explained in detail below. The programming then proceeds to the loop containing blocks 346, 348, 350, 352 and 354. The block 346 takes each record (or book) in the press command file 140 in sequential order. For each record, the block 348 determines which pages should be printed to generate that particular book. Next, the block 350 determines whether the pages to be printed should be forced to the right hand or left hand side of the book and the block 352 "pads" the pages to be printed to be a multiples of the number of pages to be printed on a sheet (in our example, 4) by adding appropriate filler pages. Next, the block 354 generates the PostScript® instruction set and the programming returns to the block 346 to retrieve the next record in the press command file 140. The loop repeats for each record in the press command file 140. FIG. 13 illustrates in detail the programming steps implemented by the block 348 of FIG. 11, which determines which pages should be printed for a particular record in the press command file 140. A block 360 first retrieves the first page in the record. A decision-making block 362 then determines whether the page is from a new file that is to be "imposed-on-the-fly with offsets." (Imposition-on-the-fly with offsets is one of the imposition formats of the present invention, which will be explained in detail below). If yes, a block 364 calculates and saves the offsets for all the pages in the file. After the block 364 calculates and saves the offsets or if the block 362 is false, a decision-making block 366 then determines whether the page is a master page (i.e. does not include any variable information placeholders). If the page is a master page, the page should always be printed and a block 368 "marks" the page to be printed. The block 368 may "mark" the page by adding it to a page print array. The page print array contains the page number and a marker to indicate the disposition of the page. For example, pages that should not be printed are designated with a "0"; master pages (always printed) are designated with a "1"; and variable pages to be printed are designated with a "2". If the block 366 determines that the page is not a master page (i.e. it's a variable page), a decision-making block 370 determines whether the variable page should be printed at all times. (This was designated by the user at the block 340 in FIG. 11 during creation of the pagination file). If yes, the block 368 marks the page to be printed. If no, a decision-making block 372 determines whether the page has any variable placeholders with valid data. In other words, the block 372 determines whether there is any variable information from the database to be printed on the page. If yes, the block 368 marks the page for printing. The program then returns to the block 360 to retrieve the next page from the record until all the appropriate pages have been marked for printing. FIG. 14 illustrates in detail the programming steps implemented by the block 350 of FIG. 11 to determine whether the pages should be forced to the left or right hand side of the book. A block 380 first initializes a left/right (L/R) counter variable to its default value of right because it is assumed that the first page of the book will be one the right side. Next, a block 382 retrieves the first page from the record that is marked "should print" and a block 384 determines whether the user has specified whether the page should be forced to the left or right side. (This was designated by the user during creation of the pagination file at block 340 of FIG. 11). If the user has not specified that the page should be forced, a block 386 flip-flops the L/R counter such that if it was set to right it is changed to left and if it was set to left, it is changed to right and the program returns to the block 382 to retrieve the next "should print" page in the record. Alternatively, if the block 384 determines that the user has specified that the page should be forced left or right, a block 388 determines whether the user specification matches the orientation of the page (i.e. is it the same as the L/R counter). If yes, the block 386 flip-flops the L/R counter and returns to the block 382 to retrieve the next "should print" page in the record. Otherwise, a block 390 marks an appropriate filler page (which was identified by the user during creation of the pagination file) to be printed and the program returns to the block 382 to retrieve the next "should print" page in the record. FIG. 15 illustrates in detail the programming steps implemented by the block 352 of FIG. 11 to "pad" the pages into a multiple of the number of pages to be printed on a sheet. In our example, using "saddle stitch" imposition, four pages are printed on a sheet (2 pages per side). Therefore, filler pages may need to be added to ensure that the total number of pages in the book is a multiple of 4. A block 392 first counts the number of pages in the record that have been marked to print. This includes all the master and variable pages that were marked by the block 368 of FIG. 13 as well as any filler pages that were marked by the block 390 of FIG. 14. Next, a block 394 determines whether the total number of pages is a multiple of 4. If not, a block 396 adds the appropriate number of filler pages to make the total number of pages a multiple of 4. For example, if the block 392 determines that 18 pages are marked to print, the block 396 will add 2 filler pages to make the total number of pages in the book equal to 20 (a multiple of four). The program then returns to the block 354 of FIG. 11 which generates the PostScript® instruction set. The PostScript® instruction set specifies how the pages marked to print should be positioned (or imposed) for printing. In our example, for a "saddle-stitch" imposition format, and assuming a 12 page book, the block 354 generates an instruction specifying that the pages should be positioned as shown in the following table:
It is understood that a different instruction set could be generated (by an imposition program) to impose and print the pages in a different format (i.e. four pages per side) or alternatively, a different number of total pages. After the block 354 generates the imposition instruction set, the pages are imposed and printed according to an imposition procedure of the present invention. The first imposition procedure of the present invention utilizes an artificial PostScript® operator called "GetTIFF", which is recognized by the Xerox DocuPrint RIP, wherein page files are preprocessed to TIFF ("tagged image file format") format before being provided to the RIP. The second imposition procedure of the present invention (referred to as "imposition-on-the-fly") involves downloading imposition programs to the RIP which redefine various PostScript® operators to automatically position pages while each page is being interpreted. A user is prompted to specify various information needed for imposition and printing, including the sheet size (i.e. 11×17), imposition style (imposition-on-the-fly or GetTIFF), finishing style (online or offline), the output device (i.e. Xerox DocuPrint or Barco Xeikon) and the name of the directory where the master and variable page files are stored. A sample window to prompt a user to provide this information is shown in FIG. 16. GetTIFF Imposition A TIFF (tagged image file format) file is a bitmap representation of a page in the same screen format as the print engine. Several commercially available RIPs (such as Image Alchemy or TranverterPro) process pages represented in a page description language format to TIFF format. The Xerox DocuPrint RIP recognizes an artificial Postscript® operator called "GetTIFFII" which retrieves a specified TIFF file and quickly processes the file for rendering by the DocuPrint demand printer. (Other demand printer RIPs, including the Barco Xeikon, may also be modified to recognize a GetTIFF-type operator). In a preferred embodiment of the present invention, the master page PDL files 122 and the variable page PDL files 137, 138 are preprocessed to TIFF format. Because the Xerox DocuPrint system allows for only one input data stream (as opposed to the Barco Xeikon system which allows two data streams—master and variable), the master page PDL files 122 and the variable page PDL files 137, 138 may be premerged. This may be accomplished by forcing all of the master data onto the variable template files. After the master and variable pages are merged, the instruction set and GetTIFF operator are used to quickly impose and process the pages for printing. Alternatively, the master and variable data streams may be overlaid by first processing the master pages and then overlaying the variable pages onto the master pages. FIG. 17 illustrates programming which may be executed to facilitate conversion of the page files into TIFF format. The programming begins at a block 397 which opens the press command file stored in the memory 53. A block 398 then prompts a user to specify options which are available. The options include the ability to convert only master page files, only variable page files or both master and variable page files into bitmap format. A block 399 then selects the first line in the press command file having at least one file name therein. Thereafter, a block 400 selects a first file name and a block 401 checks a file list stored in the memory 53 to see if the file name has been previously placed in the list. If this is not the case, then this is the first time the file name has been encountered in the programming of FIG. 17. Thus, a block 402 adds the file name to the file list and a block 403 checks the user-specified options set by the block 398 to determine whether the file should be converted into TIFF format. If so, a RIP list stored in the memory 53 is updated by adding the file name thereto (block 404) and control passes to a block 405. Control also passes to the block 405 from the block 403 (bypassing the block 404) if the file is not to be converted into TIFF format, and from the block 401 if the file name currently under consideration is already in the file list. The block 405 checks to determine whether the end of the current line in the press command file has been reached. If not, a block 406 selects the next file name in the line and control returns to the block 401. If the block 405 determines that the end of the current line in the press command file has been reached, a block 407 checks to determine whether the end of the press command file has been reached. If not, a block 408 selects the next line in the press command file having at least one file name and control returns to the block 400. On the other hand, if the end of the file has been reached, a block 409 causes the RIP 82 (or another RIP) to convert the files identified in the RIP list into TIFF format. The programming of FIG. 17 thus facilitates conversion of files to TIFF format as required by the print system 79. Referring to FIG. 18, if the user specified GetTIFF imposition and after the page files have been RIPped to TIFF format by the programming of FIG. 17, a block 410 retrieves the first page pairing from the instruction set (in our example, page 12 as the left hand page and page 1 as the right hand page). A block 412 then retrieves a reference to the page description of the left hand page in TIFF format from the page file and provides it to the RIP 82. Assuming the default offset is positioned at the left side of the sheet, the left hand page is positioned on the left side of the sheet. A block 414 then moves the offset to position the next page onto the right side of the sheet. A block 416 retrieves the reference to the page description in TIFF format of the right hand page from the page file and provides it to the RIP 82. Next, a block 418 may add page numbers and/or a bar tracking code to the sheet, as explained below. The program then returns to the block 410 to retrieve the next page pair from the instruction set and the program repeats until all pages and all books have been processed. After all pages have been processed, they are RIPped and printed by the demand printer 84 in accordance with the initialization (INI) file, which was created by the block 212 (FIG. 10b). If, for example, the demand printer is a DocuPrint (i.e., no INI file was created), the pages are submitted to the queue (which contains the same parameters as the INI file) for RIPping and printing. A partial Postscript® instruction set for printing the 12-twelve page brochure in accordance with the table above implementing the GetTIFF imposition according to FIG. 18 is set forth below:
In the instruction set, the "VERON*.*_dir/VERON*.*" indicates the directory and filename where the page descriptions are located. The suffix ".M" indicates a master page and the suffix ".V_" indicates a variable page (with the version number of the variable page to be printed). The suffix "_.tiff" is the file name created by the RIP which converted the page files to TIFF files and indicates that the files are in TIFF format. The artificial Postscript® "GetTIFF" operator interprets the TIFF files. The "612 0 translate" command moves the offset to the right hand side of the sheet (block 414) and the PostScript® showpage operator transmits the page to the demand printer 84 for rendering, prepares for interpreting the next page description and resets the offset to the lefthand side. Optionally, the block 418 may print page numbers and/or a bar tracking code onto the sheets printed by the demand printer 84. This may be accomplished by adding the following additional PostScript® code before the showpage operator in the instruction set shown above:
The first section of code provides the command for printing a bar code (indicating for example, the page number and the total number of pages in the book). The second section of the code prints page numbers centered at the bottom of each page. A similar technique could be used to do any "post page" modifications, such as watermarking samples or QC books, adding variable printers marks or the like. Imposition-on-the-Fly The user may also specify that the pages be imposed and printed using the imposition-on-the-fly technique of the present invention. This technique positions the pages while the pages are being interpreted by the RIP. FIG. 19 is a more detailed block diagram of the print system 79 shown in FIG. 4. The PDL master page files 122 and the PDL variable page files 137, 138 may be combined into merged PDL files (such as merged PostScript file(s) 450), which are then provided to the print system 79, comprised of RIP 82, collator 81, press controller 80 and demand printer 84. The press command file 140, which includes the instruction set for specifying how pages should be imposed, is also provided to the print system 79. Alternatively, as described above, the master page files 122 and the variable page files 137, 138 may be provided separately to the print system 79 and overlaid. The print system 79 may also include a raster memory 452 associated with the RIP 82 and the demand printer 84. The RIP 82 generates a raster description of the "current page" being interpreted, which may be stored in the raster memory 452 or provided to the demand printer 84 for rendering. The demand printer 84 physically renders pages 454 from the merged PostScript® file 450 onto a "flat" (or other medium) 456. For purposes of illustration, it is assumed that the RIP 82 interprets the widely used PostScript® PDL language. (PostScript® is a registered trademark of Adobe Systems, Inc.) The PostScript® language is fully described in the PostScript® Language Reference Manual, Second Edition (1990), from Adobe Systems, Inc., which is incorporated herein by reference. Certain imposition-on-the-fly procedures 454 according to the present invention are downloaded to the RIP 82. (The procedures 454 include, for example, ImposeJob, ImposeFile and various redefined PostScript® operators which are described in detail below). The imposition-on-the-fly procedures 454 will be used by the RIP 82 to process the instruction set and the page descriptions contained in the merged PostScript® files 450 to efficiently transmit pages for rendering by the demand printer 84. (For ease in illustration, it is assumed the master and variable page files were premerged into merged file 450. It is understood, however, that the master and variable page files could also be overlaid.) PostScript® Background In order to facilitate the explanation of imposition-on-the-fly procedures of the present invention, some background regarding the PostScript® language is provided. Further background details may be found in the PostScript® Language Reference Manual, Second Edition (1990), from Adobe Systems, Inc., which was previously incorporated by reference. The RIP 82 manages four different stacks, which are "-last-in-first-out" (LIFO) data structures. These stacks include: (1) an Operands Stack which holds (i) the input operands to various PostScript® operators, and (ii) the results of the operations; (2) an Execution Stack which is controlled by the RIP 82 and which holds executable objects (i.e. procedures and files) that are in stages of execution; (3) a Dictionary Stack which includes (i) a read only dictionary ("systemdict") which defines the implementation of the various PostScript® operators, (ii) a writable dictionary ("userdict") which stores all other definitions, and (iii) specialized dictionaries created by the user (e.g., an imposition dictionary); and (4) a Graphics State Stack which is used to store graphics information, such as the parameters of the demand printer 84. The PostScript® language is device independent such that the page descriptions contained in the merged PostScript® file 450 are specified in a coordinate system (called "user space") that is independent of the particular demand printer 84. The coordinate system (called "device space") used by the demand printer 84 varies depending on the particular demand printer 84 (the "current device") which is specified for rendering the current page. In order to render the pages described in the merged Postscript® file 450, the page descriptions (specified in user space) may be transformed to the current device space by a Current Transformation Matrix ([CTM]). The PostScript® language uses the Current Transformation Matrix ([CTM]) to describe scaling, rotation, and translation of the page from user space to device space. For mapping the point (x, y) in user space to the point (x′, y′) in device space:
where a, b, c, and d determine the extent of scaling and rotation and where tx and ty determine the extent of translation. The RIP 82 also maintains a data structure, called the "graphics state," that holds various graphics control parameters, including the [CTM]. The graphics state also includes (i) a clipping path, which defines the rendering area in the raster memory 452 for the current page; (ii) font and line definitions; (iii) a color space (such as DeviceGray, RGB, CMYK or CIE); and (iv) other graphics control parameters. The PostScript® language includes several operators for setting up the current demand printer 84 to fulfill the processing requirements of the page descriptions contained in the merged PostScript® file 450. The current device setup includes establishing the Current Transformation Matrix ([CTM]) for the current demand printer 84. The default transformation from user space to device space for the current device is specified by a "system default matrix." The system default matrix may be generated by the PostScript® language, for example, by a defaultmatrix operator. The [CTM] may be considered an alteration of the system default matrix. Once the current demand printer 84 has been set up, the RIP 82 can begin to interpret the page descriptions in the merged PostScript® file 450. For each page in turn, everything that is to appear on that page (including text, graphics, and images) is "painted" into the raster memory 452 and stored and/or rendered by the demand printer 84. In the merged PostScript® file 450, each description of a page to be rendered includes a PostScript® showpage operator. The showpage operator, which is generally included at the end of each page description, is used to transmit the raster description of the current page (saved in the raster memory 452) to the demand printer 84 for physical rendering of the current page. In general, the showpage operator transmits the contents of the raster memory 452 to the demand printer 84, then erases the current page from the raster memory 452 and partially resets the graphics state in preparation for interpreting the next page description in the merged Postscript® file 450. In level 2 PostScript® implementations, the function of the showpage operator is controlled by an EndPage procedure and a BeginPage procedure that are defined according to the current demand printer 84. In general, the EndPage procedure specifies the disposition of the current page in the raster memory 452 and the BeginPage procedure sets up and marks the beginning of the next page description to be interpreted. These procedures may be defined, for example, by a level 2 setpagedevice operator which sets up the graphics state for the current demand printer 84 (the "current graphics state"). During normal operation, the level 2 showpage operator provides two operands to the EndPage procedure: a reason code and Pagecount. The reason code operand specifies whether the EndPage procedure is being called by the showpage operator, by a copypage operator, or during a device deactivation. When the EndPage procedure is called by the showpage operator, the reason operand is set to 0. The Pagecount operand is the number of executions of the showpage operator that have occurred since the current device was activated, not including the present execution. Thus, Pagecount is equal to the number of pages that have been rendered prior to the current page. After the EndPage procedure is executed, Pagecount is incremented by one and is provided as an operand to the BeginPage procedure. The operation of the level 2 showpage operator is illustrated in the flowchart of FIG. 20. A block 500 first sets the reason code operand equal to zero to specify that the EndPage procedure is being called by the showpage operator. A block 502 then calls the EndPage procedure, which consumes the reason code and PageCount operands and returns a boolean result that specifies the disposition of the current page in the raster memory 452. During normal operation, the EndPage procedure returns true during execution of the showpage or copypage operators (causing a physical page to be produced) and returns false during device deactivation. A decision-making block 504 determines whether the result returned from the EndPage procedure is true or false. If the EndPage procedure returns "true", a block 506 transmits the contents of the raster memory 452 to the demand printer 84 for rendering. A block 508 then clears the raster memory 452 by executing a procedure similar to a Postscript® erasepage operator. Under normal operation, the EndPage procedure returns true if it is called by the showpage or copypage operator. Thus, the showpage and copypage operators cause the contents of the raster memory 452 to be transmitted to the demand printer 84 for rendering. If the EndPage procedure returns a "false", the showpage operator does not perform either of the functions of the blocks 506 and 508 (i.e., no page is rendered), but skips to a block 510. The block 510 executes a procedure similar to a PostScript® initgraphics operator which resets the [CTM], the clipping path, and other graphics parameters to the default values for the current demand printer 84, thus setting up the graphics state for composing the next page. The clipping path defines the rendering area for the current page stored in the raster memory 452. A block 512 then increments the Pagecount operand by one and a block 514 calls the BeginPage procedure with Pagecount as an operand. The BeginPage procedure marks the beginning of the next page in the merged PostScript® file 450 to be interpreted by the RIP 82. The standard operation of the level 2 showpage operator illustrated in FIG. 20 may be represented by the following PostScript® pseudo code:
The Imposition-On-The-Fly Procedures The imposition-on-the-fly procedures of the present invention create a layer on top of the demand printer, called a "virtual device." The desired position (scale, orientation and size) of a page to be printed by the demand printer is specified by a procedure (called "setvirtualdevice") which establishes the virtual device for that page. Thus, from the standpoint of the Postscript® program, the [CTM] is the same as the system default matrix and every page begins with a [CTM] mapping user space coordinates to the lower left corner of the output device. The [CTM] can be explicitly manipulated as if each Postscript® page were imaged on a distinct, but identical, physical page. Thus, when imposing and rendering a selected page from the merged PostScript® file 450, the current output device (i.e. the demand printer 84) is defined as the virtual device. In general, the virtual device for a selected page is the same size as the page and is positioned at the place on the flat 456 where the page is to be rendered. The virtual device is established by setting the current transformation matrix ([CTM]) to properly position the page. A clipping path, which defines the rendering area in the raster memory 452, is then created around the border of the page. Thus, the RIP 82 "sees" the position where the page is to be rendered as the current output device. For pages in the merged PostScript® file 450 that will not be rendered on the current flat 456 (i.e. are not included in the current book), the current output device (the demand printer 84) is defined as a scaled-down virtual device for the next page to be imposed and rendered on the flat. The scaled-down virtual device allows any intervening pages not to be imposed on the flat to be quickly interpreted by the RIP 82. The imposition-on-the fly procedures include the setvirtualdevice procedure, which establishes the virtual device for the next page to rendered on the flat 456 and an EnableVirtualDevice procedure which sets up the showpage operator to support virtual devices. The EndPage and BeginPage procedures that are invoked by the showpage operator are also redefined. These procedures will be described in detail below. The Imposition-on-the-Fly Instruction Set: Preferably, the instruction set for implementing imposition-on-the-fly by creating the virtual device for pages to be rendered on the flat are input to the RIP 82 in the below-described format. However, the present invention may be modified to properly impose different instruction set formats. The imposition-on-the-fly instruction set contains the name(s) of the merged PostScript® file(s) 450 that will be interpreted by the RIP 82 and rendered by the demand printer 84. These file names are associated with entry lists (stored in arrays) containing one or more entries, wherein each entry contains the following information: 1) A first user procedure—The user procedure may contain various instructions, including comments, printer's marks (such as barcodes or watermarks) or other information. (The user procedure may also be null and is not essential to the imposition-on-the-fly procedures of the present invention). 2) A page number—The page number is the sequential number of the page description in the merged Postscript® file 450 of the page to be rendered on the flat 456. The merged PostScript® file 450 is assumed to contain page descriptions in sequential order, wherein the first page description is page "0." 3) Operands to the setvirtualdevice procedure—As explained in detail below, the setvirtualdevice procedure establishes the appropriate virtual device as the current output device for a particular page. The setvirtualdevice procedure requires the following three operands, which are included in each entry in the entry list:
4) A second user procedure ("offsets"): Like the first user procedure, the second user procedure may contain comments, printer's marks (barcodes, watermarks, etc.) or other information or may be null. In a preferred embodiment, however, for the first page on the flat, the second user procedure is used to "offset" the program to the next page to be rendered on the flat. For example, the merged Postscript® file generally contains many, many pages because it includes separate page descriptions for each variable page. Assume a simple four page book with three master pages and only one variable page. The book may be sent to 1,000 different people, with different variable information for each person. Thus, the merged Postscript® file contains 1,003 page descriptions—3 master pages and 1,000 variable pages. Imposition-on-the-fly with offsets allows for quick printing of the books because it "skips over" (i.e. does not RIP) the 999 variable pages that will not be included in each book. For imposition-on-the-fly with offsets, the second user procedure for the first entry in the instruction set contains a file object, an offset position and the PostScript® setfileposition operator. The offset position points to the next page description in the file that is to be included on the flat. (The offset positions were calculated and saved by the block 364 of FIG. 13.) The setfileposition operator reopens the current merged PostScript® file 450 to that offset position. Thus, the PostScript® instruction set format for imposition-on-the-fly imposition of the present invention is as follows:
A sample imposition-on-the-fly with offsets instruction set is attached as Appendix I. The Appendix I instruction set also includes code in certain second user procedures to print a barcode. Explanation of Variables: The variables used by the imposition-on-the-fly procedures may be conveniently defined and stored in a user dictionary (called, for example, "impositiondict"). These variables include: 1) PageOffset—the cumulative number of pages from any previous Postscript® files that have been interpreted in accordance with the imposition-on-the-fly procedures of the present invention. Initially, PageOffset is set to -1 (no previous files (or pages) have been interpreted). 2) CurrentPage—the number of the next page in the current merged PostScript® file 450 that is to be rendered on the current flat 456. CurrentPage is initially set to 0. 3) LastPage—the number of the last page in the current merged PostScript® file 450 that is to be rendered on the current flat, which is equal to the page number in the last entry of the entry list. LastPage is initially set to 1 and is used to determine how many page descriptions in the merged Postscript® file must be interpreted in order to properly render all of the selected pages on the current flat. 4) PageCount—the number of times that the showpage operator has been executed (initially 0). In level 2 PostScript® implementations, PageCount is stored and incremented internally by the RIP 82 through the showpage operator. However, in level 1 PostScript® implementations, the PageCount variable must be explicitly defined and incremented to emulate the operation of the level 2 showpage operator. 5) PageList—the list of entries (page numbers and imposition procedures) contained in the entry list. 6) CurrentIndex—an index into the PageList. 7) LastIndex—the number of entries in the entry list. 8) DefaultMatrix—used to store the value of the [CTM] describing the virtual device (the "virtual [CTM]"). The scaling, translation and rotation components of the virtual [CTM] are supplied as operands to the setvirtualdevice procedure. 9) PageX and PageY—the width and height respectively of the page to be rendered on the flat 456. The values of PageX and PageY are provided in each entry of the entry list as operands to the setvirtualdevice procedure. 10) DefaultPageX and DefaultPageY—the default values of the page width and height, respectively. Their values are initially set to 8½" (612) and 11" (792), respectively. 11) ClipllX, ClipllY, ClipurX and ClipurY—the user space coordinates of the lower-left and upper-right corners, respectively, of the clipping path defining the border of the virtual device. The values of these variables are also included as operands to the setvirtualdevice procedure. 12) Portrait—a boolean variable used to describe the page orientation of the current page. If Portrait is true, the current page has a portrait orientation (page width<page height). If Portrait is false, the current page has a landscape orientation (page width>page height). 13) DefaultPortrait—the default value for the page orientation, which is initially set to true (portrait orientation). 14) VirtualDeviceEnabled—a boolean variable used to determine whether a procedure called, for example, "EnableVirtualDevice," has been executed. As explained in detail below, the EnableVirtualDevice procedure sets up the standard Postscript® showpage operator to support virtual devices. 15) ImageDone—a boolean variable used to specify when the current flat 456 has been completed. ImageDone is initially and normally set to false, indicating that the current flat 456 has not been completed. A further description of the variables used is included in the following PostScript® code, which creates the impositiondict dictionary and initializes the variables:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||