Imposition process and apparatus for variable imaging system6332149Abstract The present invention comprises an apparatus and method for reproducing master and variable information on a display device, such as a computer network or a demand printer. The present invention develops first and second sets of template data representing associated first and second template pages, respectively, wherein each set of template data includes master data representing fixed information to be printed and area data representing an area of a page in which variable information is to be printed. A database is developed having a number of entries, each of which represents variable printed information and the display device is responsive to the sets of template data and the database to display the first and second template pages with selected variable information. The fixed and variable pages may be converted to TIFF format and imposed according to an instruction set. Alternatively, the fixed and variable pages may be "imposed-on-the-fly" as they are processed by a RIP. Claims What is claimed is: Description TECHNICAL FIELD
Version Addressline1 Addressline2 Addressline3 Addressline4 Addressline5
Price1 Image1 Price2 Copies Barcode Townsort
01 William Doe 123 Elm Chicago Illinois 606248923
$22.95 Shoes $21.95 1 !606248923!
03 Hugh 56 Maple Chicago Illinois 606248923
$21.95 Shirt $20.95 1 !606248923!
Jorgensen
02 Jay P. 1313 Park Chicago Illinois 606248924
$24.95 Pants $22.95 1 !606248924! .box-solid.
Morgan
02 Joe Louis 819 Elm LaGrange Illinois 605251093
$19.95 Pants $18.95 1 !605251093!
03 John Smith 926 Cossit LaGrange Illinois 605251093
$19.95 Shoes $15.25 1 !605251093!
01 Len Johnson 882 Monroe LaGrange Illinois 605251093
$19.95 Shoes $17.25 1 !605251093!
02 Janet Cizmar 916 Monroe LaGrange Illinois 605251094
$24.95 Pants $21.95 1 !605251094! .box-solid.
03 Jay Schroeder 88 W. 77th Brookfield Illinois 605241391
$21.95 Shirt $19.95 1 !605241391!
03 Danielle 129 Madison Brookfield Illinois 605241391
$22.95 Shirt $19.95 1 !605241391! .box-solid.
Johnston
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:
name: [file path.backslash.name]
psx: [dimension]
psy: [dimension]
ssx: [dimension]
ssy: [dimension]
posx: [dimension]
posy: [dimension]
duplex: [zero or one]
orientation: [zero or one]
output: [filename]
copies: [number]
Where "psx" and "psy" refer to finished page sizes in x and y directions, "ssx" and "ssy" refer to cut sheet size in x and y directions, "posx" and "posy" refer to offsets in x and y directions specifying placement of each page on a cut sheet, "duplex" refers to single or two-sided printing, "orientation" refers to portrait or landscape printing, "output" refers to the name of the output file and "copies" refers to the number of copies to be printed. A sample INI file which specifies parameters for printing of a file called MYJOB.PS is as follows:
Name: C:.backslash.jobs.backslash.myjob.ps
psx: 8000
psy: 11000
ssx: 11500
ssy: 9000
posx: 150
posy: 150
duplex: 1
orientation: 1
output: myjob.ps
copies: 1
In the foregoing example, one copy of the file MYJOB.PS is to be printed in duplex and portrait formats at an offset of 0.15.times.0.15 inches from a corner of a finished sheet of paper 8.times.11 inches cut from a sheet originally having dimensions of 9.times.11.5 inches. 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 in-line 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:
1 7
8 43
9 44
10 45
11 46
11 47
13 50
14 52
15 50
15 51
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.RTM. 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 text box or object, 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.RTM. 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): ;RECORD1 ;:WILLIAM DOE:606248923 ;ENDRECORD ;RECORD2 ;:HUGH JORGENSEN:606248923 ;END RECORD ;RECORD3 ;:JAY P. MORGAN:606248924 ;END RECORD 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: ;RECORD1 ;:WILLIAM DOE:606248923 ;SECTION 1 ;ENDSECTION ;ENDRECORD ;RECORD2 ;:HUGH JORGENSEN:6062488923 ;SECTION 1 ;ENDSECTION ;END RECORD ;RECORD3 ;:JAY P. MORGAN:606248924 ;SECTION 1 ;END SECTION ;END RECORD 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: BOOK A ;RECORD1 ;:WILLIAM DOE:606248923 ;SECTION 1 "file.m"1@"file.v1"1.vertline."file.m"2 "file.m"3.vertline."file.m"4@"file.v4"1 ;ENDSECTION ;ENDRECORD ;RECORD2 ;:HUGH JORGENSEN:606248923 ;SECTION 1 "file.m"1@"file.v1"2.vertline."file.m"2 "file.m"3.vertline."file.m"4@"file.v4"2 ;ENDSECTION ;ENDRECORD ;RECORD3 ;:JAY P. MORGAN:606248924 ;SECTION 1 "file.m"1@"file.v1"3.vertline."file.m"2 "file.m"3.vertline."file.m"4@"file.v4"3 ;ENDSECTION ;ENDRECORD ENDBOOK PRINTRUN R BOOK A ENDPRINTRUN 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.RTM. 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 filler page(s) that may or may not be printed and assembled at the end of 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: 1) A Master Page--contains the same information and is included in every book; 2) An Always Variable Page--may contain variable information and is included in every book; or 3) A Selectively Variable Page--contains variable information and is selectively included in certain books. 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.RTM. 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.RTM. 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 PostScripts.RTM. instruction set. The Postscript.RTM. 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:
Sheet No. Side No. Left Side Right Side
1 1 Page 12 Page 1
1 2 Page 2 Page 11
2 1 Page 10 Page 3
2 2 Page 4 Page 9
3 1 Page 8 Page 5
3 2 Page 6 Page 7
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.RTM. 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.RTM. 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.times.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 PS or TranverterPro) process pages represented in a page description language format to TIFF format. The Xerox DocuPrint RIP recognizes an artificial PostScript.RTM. operator called "GetTIFF" 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 overlayed 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.RTM. 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:
<<
/PageSize [1224 792] % set sheet size
>> setpagedevice % (11 .times. 17)
(VERON12.V01_dir/ % get left page
VERON12.V01.00000002.tiff) GetTIFF
612 0 translate % move to right
(VERON01.V01_dir/ % get right page
VERON01.V01.00000002.tiff) GetTIFF
showpage
(VERON02.M_dir/ % get left page
VERON02.M.00000002.tiff) GetTIFF
612 0 translate % move to right
(VERON11.V01_dir/ % get right page
VERON11.V01.00000002.tiff) GetTIFF
showpage
.
.
.
(VERON06.M_dir/ % get left page
VERON06.M.00000004.tiff) GetTiff
612 0 translate % move to right
(VERON07.V03_dir/ % get right page
VERON07.V03.00000003.tiff) GetTiff
showpage % reset to left
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.RTM. "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.RTM. 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 left hand 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.RTM. code before the showpage operator in the instruction set shown above:
/C39P24Dm 24 selectfont % add bar code info
30 4.5 sub 18 translate 90 rotate % position on
0 0 moveto % side of sheet
(1.12) show % indicates sheet 1 of 12
%
/Helvetica 12 selectfont % add page numbers
320 780 moveto % center in middle of left page
(12) show % print page "12"
-320 780 moveto % center in middle of right page
(1) show % print page "1"
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 overlayed. 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.RTM. 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.RTM. PDL language. (PostScript.RTM. is a registered trademark of Adobe Systems, Inc.) The PostScript.RTM. language is fully described in the PostScript.RTM. 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.RTM. 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.RTM. 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 overlayed.) PostScript.RTM. Background In order to facilitate the explanation of imposition-on-the-fly procedures of the present invention, some background regarding the PostScript.RTM. language is provided. Further background details may be found in the PostScript.RTM. 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.RTM. 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.RTM. 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.RTM. language is device independent such that the page descriptions contained in the merged PostScript.RTM. 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.RTM. 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.RTM. 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: ##EQU1## where a, b, c, and d determine the extent of scaling and rotation and where t.sub.x and t.sub.y 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.RTM. 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.RTM. 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.RTM. 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.RTM. 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.RTM. file 450, each description of a page to be rendered includes a PostScript.RTM. 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.RTM. file 450. In level 2 PostScript.RTM. 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.RTM. 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.RTM. 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.RTM. 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.RTM. pseudo code:
/showpage {
/reason 0 def % reason = 0 for
% showpage
pagecount reason EndPage % call EndPage
% procedure
{ transmit contents of % .backslash. do these lines
raster memory to % .backslash. only
demand printer % / if Endpage
erasepage } if % / returns true
initgraphics % set default graphics
% state
/pagecount pagecount 1 add def % increment
% pagecount
pagecount BeginPage % call BeginPage
% procedure
} def
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.RTM. 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.RTM. page were imaged on a distinct, but identical, physical page. Thus, when imposing and rendering a selected page from the merged Postscript.RTM. 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.RTM. 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 PostScripte 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.RTM. file 450 of the page to be rendered on the flat 456. The merged PostScript.RTM. 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: i) the scaling, translation and rotation factors which will be used to generate a "virtual [CTM]" which will properly position the selected page on the flat 456. These factors are listed as follows: [scale_x scale_y translate_x translate_y rotate]; ii) the user space coordinates of the lower-left and upper-right corners of the actual rendering area of the next page to be rendered on the flat 456. These corner coordinates will be used to generate a clipping path around the border of the page in the raster memory 452. The corner coordinates are listed as follows: [ClipllX ClipllY ClipurX ClipurY]; and iii) the size (width and length) of the page to be rendered on the flat. The page size is listed as follows: [PageX PageY]. (The page size is not necessarily equivalent to the clipping path defining the rendering area of the page, as many demand printers are unable to place marks at the extreme edges of the page). 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.RTM. 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.RTM. 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.RTM. 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 repositions the current merged PostScript.RTM. file 450 to that offset position. Thus, the PostScript.RTM. instruction set format for imposition-on-the-fly imposition of the present invention is as follows:
[ (FileName)
[ { user procedure 1 }
page# { operands to setvirtualdevice }
{ FileObject offset setfileposition }
]
[ { user procedure 1 }
page# { operands to setvirtualdevice }
{ user procedure 2 - barcodes, watermarks, etc. }
]
]
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.RTM. 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.RTM. 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.RTM. 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.RTM. 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.RTM. implementations, PageCount is stored and incremented internally by the RIP 82 through the showpage operator. However, in level 1 PostScript.RTM. 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 1/2" (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.RTM. 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.RTM. code, which creates the impositiondict dictionary and initializes the variables:
/impositiondict 200 dict det % create dictionary
% impositiondict begin
/Identity matrix def % used as input to setmatrix
/Matrix matrix def % dummy matrix for temp storage
/Matrix2 matrix def % dummy matrix for temp storage
/Matrix3 matrix def % dummy matrix for temp storage
/Matrix4 matrix def % dummy matrix for temp storage
/DefaultPageX 612 def % default page width (X) and
/DefaultPageY 792 def % page lenqth (Y) (8 1/2" .times.
% 11")
/DefaultPortrait true def % assume page orient =
% portrait
/PageOffset -1 def % first file - no previous
% pages
/CurrentPage 0 def % initial value of page to
% impose
/CurrentIndex 0 def % initial value of page to
% impose
/LastPage 2147483647 def % initial value is highest
% number
/PageCount 0 def % used in level 1 only
/DefaultMatrix matrix % the "default" matrix for the
currentmatrix def % current virtual device
/VirtualDeviceEnabled false def % allow normal
% operation
/ImageDone false def % not done with current media
% Set initial job defaults
/Portrait DefaultPortrait def % default to portrait
% mode
/PageX DefaultPageX def % initial page size
/PageY DefaultPageY def %
/Clip11X 0 def % initial lower left
/Clip11Y 0 def % and upper right
/ClipurX DefaultPageX def % corners of
/ClipurY DefaultPageY def % clipping path
The Redefined PostScript.RTM. Operators Also, before executing the imposition-on-the-fly procedures of the present invention, several PostScript.RTM. operators must be redefined for compatibility with the EnableVirtualDevice and setvirtualdevice procedures, which will be described in detail below. The virtual device, in effect, "shields" the PostScript.RTM. program and RIP from where the pages are being painted into the raster memory 452 through the [CTM]. Thus, in general, the PostScript.RTM. operators that affect the [CTM] must be redefined to also "shield" the PostScript.RTM. program and RIP from the final mapping of the page description from user space to device space coordinates. The PostScript.RTM. operators which must be redefined include:
initmatrix transform
initclip itransform
setmatrix dtransform
currentmatrix idtransform
erasepage nulldevice
initgraphics copypage
The standard operation of these, and all other Postscript.RTM. operators, is fully described in the PostScript.RTM. Language Reference Manual, Second Edition (1990), from Adobe Systems, Inc., which was previously incorporated by reference. The first step in redefining the above-listed PostScript.RTM. operators is to rename the standard operator, for example, "systemdict_operator," because its definition is stored in the systemdict dictionary. This may be implemented by the following code: /systemdict_initmatrix systemdict /initmatrix get def /systemdict_initclip systemdict /initclip get def /systemdict_setmatrix systemdict /setmatrix get def /systemdict_erasepage systemdict /erasepage get def /systemdict_initgraphics systemdict /initgraphics get def /systemdict_currentmatrix systemdict /currentmatrix get def /systemdict_transform systemdict /transform get def /systemdict_itransform systemdict /itransform get def /systemdict_dtransform systemdict /dtransform get def /systemdict_idtransform systemdict /idtransform get def As explained below, the standard nulldevice and copypage operators are not renamed because their standard operation will never be used in connection with the present invention. The new definitions of the operators, described below, are then loaded into the userdict dictionary. The Redefined Initmatrix Operator The standard PostScript.RTM. initmatrix operator sets the [CTM] to the system default matrix for the current device. The initmatrix operator is redefined to set the [CTM] equal to the virtual [CTM] which defines the virtual device. The virtual [CTM] may be stored in the variable DefaultMatrix. The PostScript.RTM. initmatrix operator may be redefined by the following code:
/initmatrix {
impositiondict begin
DefaultMatrix
systemdict_setmatrix
end
} bind def
The Redefined Initclip Operator The default clipping path corresponds to the boundary of the maximum imageable area for the current output device (the demand printer 84). The standard PostScripts initclip operator replaces the current clipping path in the graphics state with the default clipping path for the current demand printer. The initclip operator is redefined to replace the current clipping path in the graphics state with a clipping path defining the border of the virtual device page. The flowchart of FIG. 21 illustrates the program steps implemented by the redefined initclip operator. A decision-making block 520 determines whether a current path exists by checking for the existence of a currentpoint. If no currentpoint is defined, a block 522 stores an empty path in a variable called, for example, "p1." Alternatively, if a currentpoint is defined, a block 524 invokes a previously defined utility routine called, for example, "MakePath," that creates a path description from the current path. The block 524 then saves the current path description in the variable p1. The MakePath procedure, which may be stored in the impositiondict dictionary, is similar to the level 2 PostScript.RTM. upath operator and may be implemented by the following code:
/Makepath {
[ {/moveto cvx} {/lineto cvx} {/curveto cvx}
{/closepath cvx} pathforall ] cvx
} bind def
Next, a block 526 saves the current [CTM] and a block 528 sets the [CTM] to the virtual [CTM]. A block 530 then creates a clipping path between the corners of the virtual device, which were specified by the values of the ClipllX, ClipllY, ClipurX and ClipurY variables provided as operands to the setvirtualdevice procedure. A block 532 then restores the [CTM] which was saved by the block 526 and the current path saved in the variable p1. The PostScript.RTM. initclip operator may be redefined by the following code:
/initclip
impositiondict begin
{ currentpoint } stopped
{ /p1 { } def } % p1 = empty path
{ pop pop /p1 MakePath def } % p1 = current
% path
ifelse
matrix systemdict_currentmatrix
initmatrix
systemdict_initclip
newpath
ClipllX ClipllY moveto % create clippath
ClipurX ClipllY lineto
ClipurX ClipurY lineto
ClipllX ClipurY lineto
closepath
clip
newpath
systemdict_setmatrix
p1 % restore current
end % path
} bind def
The Redefined Setmatrix Operator The standard PostScript.RTM. setmatrix operator replaces the current [CTM] in the graphics state with a matrix that is supplied on the Operands stack. The matrix supplied on the Operands stack ("the operand matrix") can be considered the result of the concatenation of the system default matrix with an operations matrix. The setmatrix operator is redefined to calculate the operations matrix by concatenating the operand matrix with the inverse of the system default matrix. Thus, [operand matrix]=[operations matrix] [system default matrix], and [operations matrix]=[operand matrix] [system default matrix].sup.-1. Once the operations matrix is calculated, it is concatenated with the virtual [CTM] (stored in DefaultMatrix) and saved as the new [CTM]. Thus, new [CTM]=[operations matrix] [virtual CTM]. The Postscript.RTM. setmatrix operator may be redefined by the following code:
/setmatrix {
impositiondict begin
Matrix defaultmatrix
Matrix2 invertmatrix
Matrix3 concatmatrix
DefaultMatrix
Matrix4 concatmatrix
systemdict_setmatrix
end
} bind def
The Redefined Currentmatrix Operator The standard currentmatrix operator replaces the matrix supplied on the Operands stack with the current [CTM] in the graphics state. The current [CTM] can be considered the result of concatenating the virtual [CTM] (saved in DefaultMatrix) with an operations matrix. The redefined currentmatrix operator calculates the operations matrix by concatenating the current [CTM] with the inverse of the virtual [CTM] as set forth below: [current CTM]=[operations matrix] [virtual CTM], and [operations matrix]=[current CTM] [virtual CTM].sup.-1. The [operations matrix] is then concatenated with the system default matrix and the resultant matrix is stored in the matrix on the Operands stack. The PostScript.RTM. currentmatrix operator may be redefined by the following code:
/currentmatrix {
impositiondict begin
Matrix systemdict_currentmatrix
DefaultMatrix
Matrix2 invertmatrix
Matrix3 concatmatrix
Matrix4 defaultmatrix
3 -1 roll
concatmatrix
end
} bind def
The Redefined Erasepage Operator The standard erasepage operator erases the entire current page stored in raster memory by painting the page white. The erasepage operator is redefined to erase only the virtual device page, which is the area defined by the next page to be rendered on the current flat. The erasepage operator is redefined by calling the redefined initclip operator, described above, which establishes a clipping path around the border of the virtual device page. The area inside the clipping path is then painted white. The standard PostScript.RTM. gsave operator (described in detail in connection with the optional imposition-on-the-fly procedures of the invention) is called immediately before the redefined initclip operator to save the current graphics state, including the current clipping path, gray level, etc. Also, after the virtual device page has been painted white, the standard PostScript.RTM. grestore operator (also described in detail in connection with the optional procedures) is called to restore the current graphics state. The PostScript.RTM. erasepage operator may be redefined by the following code:
/erasepage {
impositiondict begin
gsave % systemdict_gsave for optional procs
initclip
clippath 1 setgray fill
grestore % systemdict_grestore for optional
% procs
end
} bind def
(In the optional imposition-on-the-fly procedures, the standard PostScript.RTM. gsave and grestore operators are redefined. Thus, in the optional procedures, the erasepage operator is redefined by calling the systemdict_gsave and systemdict_grestore operators, as specified above.) The Redefined Initgraphics Operator The standard Postscript.RTM. initgraphics operator resets several values in the graphics state, including the [CTM], the current path and the clipping path, to their default values. The standard initgraphics operator is equivalent to the following Postscript.RTM. language sequence: initmatrix newpath initclip 1 setlinewidth 0 setlinecap 0 setlinejoin [] 0 setdash 0 setgray 10 setmiterlimit The initgraphics operator is redefined to perform the above listed sequence. However, the redefined initgraphics calls the redefined initmatrix and initclip operators, which were described above. Thus, the redefined initgraphics operator resets the [CTM] and the clipping path to their default values for the virtual device. The PostScript.RTM. initgraphics operator may be redefined by the following code:
/initgraphics {
initmatrix newpath initclip
1 setlinewidth 0 setlinecap 0 setlinejoin
[] 0 setdash 0 setgray 10 setmiterlimit
} bind def
The Redefined "transform" Operators The standard PostScript.RTM. transform operator transforms a supplied user space coordinate (x,y) to the corresponding device space coordinate (x',y') as specified by the [CTM]. Since the [CTM] is altered during the imposition process, the transform operator is redefined to perform the transformation a | ||||||