Method of reproducing variable graphics in a variable imaging system6205452Abstract The present invention comprises an apparatus and method for reproducing master and variable information, including variable graphics information, on a display device, such as a computer network or a demand printer. Variable graphics information is stored in a database. A user is prompted to specify graph parameters (i.e. graph type, size, labels, etc.) or default values are used. Template page files containing fixed information and placeholders for variable information are generated. Image boxes are used as placeholders for variable graphics information and an executable graph file is placed in the image boxes. A text box containing the specified graph parameters and variable graphics information from the database is layered over the image box and "tagged" to specify that it contains variable graphics information. During interpretation of the page file, an interpreter (RIP) determines if a text box is "tagged" and, if so, executes the graph file to generate a graph using the specified graph parameters and variable graphics information from the database. Claims What is claimed is: Description TECHNICAL FIELD
1996 1997 1998 Town
Version Address1 Address2 Address3 Address4 Address5 Price1
Image1 Price2 Barcode Sales Sales Proj sort
01 William 123 Elm Chicago Illinois 606248923 $22.95 Shoes
$21.95 !606248923! 50 75
Doe
03 Hugh 56 Maple Chicago Illinois 606248923 $21.95 Shirt
$20.95 !606248923! 35 95 100
Jorgensen
02 Jay P. 1313 Park Chicago Illinois 606248924 $24.95 Pants
$22.95 !606248924! 45 45 50 .box-solid.
Morgan
02 Joe Louis 819 Elm LaGrange Illinois 605251093 $19.95 Pants
$18.95 !605251093! 75 100 100
03 John Smith 926 LaGrange Illinois 605251093 $19.95 Shoes
$15.25 !605251093! 25 35 45
Cossit
01 Len 882 LaGrange Illinois 605251093 $19.95 Shoes
$17.25 !605251093! 65 75 100
Johnson Monroe
02 Janet 916 LaGrange Illinois 605251094 $24.95 Pants
$21.95 !605251094! 95 75 85 .box-solid.
Cizmar Monroe
03 Jay 88 W. Brookfield Illinois 605241391 $21.95
Shirt $19.95 !605241391! 15 25 35
Schroeder 77th
03 Danielle 129 Brookfield Illinois 605241391 $22.95
Shirt $19.95 !605241391! 35 65 75 .box-solid.
Johnston Madison
In the example of FIGS. 6a and 6b, the field names ADDRESS1 through ADDRESS5, 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 database may also contain a "COPIES" field (not shown) which may be used as a control code to select the number of book copies to be produced. FIG. 9 illustrates a flow chart of programming executed by the personal computer 54 for creating the template file(s) 106 of FIG. 5. The programming may be written as an extension of QuarkXPress.RTM., a page make-up program distributed by Quark, Inc. of Denver, Colo. The QuarkXPress.RTM. program may be adapted for operation on the Apple.RTM. Macintosh.RTM. operating system or any other operating system, such as the Microsoft Windows.RTM. operating system. Alternatively, a different page make-up program may be used, if desired. During the make-up process for a document consisting of one or more pages, a template file is created for each book version to be produced, or, where a book is to include two or more parts (referred to as "sections" hereinafter) a template file may be created for each section. At a block 150, a user creates pages containing all the static or master elements to be included. A block 151 then prompts a user to identify the database fields in the variable database 108 which will be used for variable text, image and graph information. A block 152 then determines whether the user wishes to include a variable text element in a page. If yes, a block 153 places the name or an indication of the appropriate field in the database 108 into the template file at the insertion point defined by the current cursor position. Thus, the variable text contained in the database field will be inserted on the page at the designated insertion point. After the block 153 inserts the database field name for the variable text element or, alternatively, if the block 152 determined that no variable text element was to be added, a block 154 then determines whether a variable image element should be added to the page. If yes, a block 155 prompts a user to define a box to contain an image at a desired location on a selected page. The block 155 then inserts a dummy picture file and an indication of the proper database field name in the template file for the page at the location indicated by the current cursor position. The user will thereafter see the dummy picture file at the insertion point on the display of the computer 54 when the page is viewed. The dummy picture file will display an indication of which database field will be used for insertion on the respective pages. Following the block 155, a block 156 prompts the user to enter an indication of whether the image object is to be displayed in one of several display formats. If the image is to be displayed in other than the original size thereof, a subname is defined for the image to "fit," indicating that the image is to be scaled to fit the box. If the image is to be displayed in the original size thereof, the user is prompted to select a position for the image at a particular location in the box defined therefor, such as the upper left-hand corner, the lower right-hand corner, or the like. If the user does not select a position, the image is placed in the upper left corner of the image box. Following the block 156 or, alternatively, if the block 154 determines that no variable image element is to be added, a block 157 then determines whether any variable graph elements are to be included. If yes, a block 158 creates an image box at the position on the page where the graph will be inserted. A block 159 then prompts a user to select any attributes, such as the graph type and parameters (i.e. bar graph or pie chart, size, labels, colors, etc.), as described in greater detail below. Next, a block 160 identifies the controlling database field names (in the database 108) for the variable information to be included on the graph. The database fields may contain both variable graph values as well as variable graph parameters. Thus, a first version may include a small bar graph while a second version may include a larger pie chart. A block 161 then creates a text box one layer above the image box generated by block 158 and a block 162 saves the graph parameters (which were input by the user at the block 159 or obtained from the database 108) as data pairs in the text box. The layering of the text box above the image box assures that the graph parameters will be read before the EPS graph file. The block 162 also saves the graph values as data pairs in the text box. The graph values are obtained from the database fields specified by the block 160. As described in detail below, the graph parameter and value data pairs in the text box will be converted into PostScript.RTM. variables and used to generate the desired graph during interpretation of the page files. A block 163 then "marks" or "tags" the text box so that the interpreter will recognize that the text box will be used to generate a graph. The text box may be tagged in a number a ways, such as assigning the text box an unusual attribute, such as an unusual color or font. The text box could also be tagged by placing text delimiters in the text box. For example, a unique text string (such as "%#?!BeginVariableGraphData") could be placed at the beginning of the text box and another unique string (such as "%#?!EndVariableGraphData") could be placed at the end of the text box. A sample text box tagged using text delimiters and including graph parameters data pairs to create a pie chart with labels is set forth below: %#?!BeginVariableGraphData sChartType Pie bShowLabels True bShowPercents True nXExtent 400 nYExtent 200 aXD1 xRBIpc XRunspc XOutspc xLeftpc aXLbls RBIs Runs Scored Out Hits Without Score %#?!EndVariableGraphData Next, a block 164 places an Encapsulated PostScript.RTM. (EPS) graph file into the image box created by the block 158. As described in detail below, the EPS graph file will be executed by the interpreter to generate the graph. The block 164 also designates the EPS graph file as variable data. Although the EPS graph file is actually static (it does not change), it must be designated as variable because it will be used with the variable graph parameters and values. Control then passes to a block 165 which determines whether any additional variable elements should be added to the template file. If yes, control returns to the block 152 and the loop of blocks 152-165 is repeated until all variable elements (text, image and graphs) have been added. Control then passes to a block 166 which saves the template file 106 (FIG. 5). The programming of FIG. 9 is repeated until all template files have been created. The resulting page template files(s) are stored on a storage medium, such as an optical disc or other storage device, and/or the files(s) are downloaded together with the database to the control unit 52. At any point during the page make-up process, other functional aspects of the QuarkXPress.RTM. program may be invoked to both master and variable aspects as necessary to produce finished pages. The Graph Parameters As set forth above, the block 159 prompts a user to select the graph type and parameters and the block 162 inserts this information into the text box (in the template file) as data pairs, along with the graph value data pairs. First, the user must select the type of graph, such as a bar chart, pie chart, line graph, scatter diagram, or any other type of graph. If a user does not specify an option for any parameter, a default option will be used. Also, the graph type and parameters may be included as fields in the variable database 108 such that the graph parameters, as well as graph values, may vary. If the user selects a bar chart, for example, the block 159 will then prompt a user to select the parameters listed below. 1) Two-dimensional or Three-dimensional--If the user chooses a 3D bar chart, the user may also specify the amount of increase or decrease of shading applied to the side of the bar as compared to the face of the bar. 2) Orientation--Horizontal or vertical. 3) Size--The size (i.e length) of the x- and y-axes. Size may be specified in either inches or points, but preferably the size provided to the EPS graph file will be converted to inches. The user may also select "autosize," wherein the axes sizes will be determined by the EPS graph file based on the total size of the graph. 4) Bar Width--May be fixed or variable. The user may specify the bar width or it may be automatically determined by the EPS graph file. 5) Number of Bars Per Group per x-value--The number of bars at each point on the x-axis. The default value is 1 but a user may select to have 2 or more bars adjacent to each other (for example, as a comparison between two years). 6) Color--The user may choose color or black and white (grayscale). If color, the user may choose one unique color per category from a list of any number (for example, 10) default colors (such as red, blue, green, yellow, orange, black, etc.). Preferably, the colors are converted to CMYK equivalents but other color schemes may be implemented. Alternatively, the user may specify any number of customized colors (also converted to CMYK equivalents). If the user chooses black and white for the bar graph, the user may also select one unique grayscale for each category from a list of any number of default alternating grayscales or the user may custom specify grayscales. 7) Vignette Shading--The default setting is for no vignette shading such that the bars will be printed in a solid color. The user may specify vignette shading by choosing a starting and ending color and the EPS graph file will automatically shade the bar accordingly. 8) Y-Axis Bar Scaling--The y-axis may to scaled to automatically fit the maximum data point (both positive and negative) specified in the database or by the user. The user may also specify that the y-axis be scaled with a broken axis (such as when there is a wide numerical range of data) and may further specify where the axis should be broken and/or how far up on the axis the break should occur. 9) Y-Axis Divisions--The user may specify the number of divisions on the y-axis or may choose for automatic divisions (with intelligent rounding applied) based on the size and scaling of the y-axis. 10) X-Axis Bar Scaling--As a default, the space between bars in separate groups is equal to the width of the bars and the space between bars in the same group is none (i.e. the bars are adjacent). The user may also specify the spacing between bars, preferably as a percentage of bar width. The user may also select a leading space (before the first bar) and/or a trailing space (after the last bar). 11) Line Color--The user may specify the color for the axes and other lines, such as division markers. Generally, the default is black but the user may select any CMYK equivalent color or specify no color. 12) Numeric Callouts--Numeric callouts are labels that may be placed at the top or inside of each bar which specify the value that the bar represents. The default setting is for no numeric callouts but, if desired, the user may specify where they should be placed and the format (i.e., numeric or percent of maximum value). 13) Field Name Callouts--Field name callouts are labels that are placed along the x-axis at the base of each bar. The default setting is for no field name callouts but the user may specify that field names be placed inline (parallel) with the base of each bar or perpendicular to the base of each bar. 14) X-Axis and Y-Axis Labels--The user may specify text labels for the x- and y-axes, as well as the font, size, color, position and orientation of such text. 15) Legend--The user may also specify that a legend be placed at the lower right corner of the chart (or other location) with a key to the color-coding on the chart. For example, the legend may print a small blue bar followed by "1996" and a small red bar followed by "1997" to indicate that different colored bars represent different years. 16) Graphics Object--In the default setting, the bars on the graph will be drawn as standard rectangles. The user, however, may wish to use graphics in place of the rectangular bar. For example, a transportation company may wish to use bars in the shape of trucks or a soft drink manufacturer may wish to use bars in the shape of bottles. If so, the user must specify the desired graphics object (for each category, if more than one) and the name of the file (such as an EPS file) containing the graphics object at 100% of its size. The user may then select either a scale mode, wherein the graphics object will be scaled (i.e. stretched or shrunk) according to the numeric value it represents or a clip mode, wherein the graphics object will be cut-off or clipped in accordance with a numeric value. If the user selects a graph type different than a bar chart, similar parameters must be selected, depending on the graph type. For example, if the user selects a pie chart, the following parameters will be selected: 1) Two-dimensional or Three-dimensional--With desired shading modification if 3D, as described above. 2) Color--Select CMYK or grayscale color for each category (i.e. pie segment), as described above. 3) Line Color--May select default (black), CMYK color or no color for lines surrounding pie chart and separating pie segments. The user may also select the line width (default=1 point). 4) Radius--Size of pie chart (specified in inches or points but preferably provided to EPS graph file in inches). 5) Numeric Callouts--Labels placed inside or next to a pie segment indicating its numeric value. The default setting is for no numeric callouts but the user may specify that numeric callouts be centered (at radius/2) within the pie segment or next to the pie segment with a line (from radius/2 to 3*radius/2) between the number and the pie segment. Alternatively, numeric callouts may be placed within the pie segment if the segment is large (i.e. >30.degree.) or next to the segment if the segment is small (i.e. <30.degree.). 6) Field Name Callouts--Labels that may be placed inside or next to pie segments indicating what the segment represents. The default setting is for no field name callouts but the user may specify that they be positioned like the numeric callouts above. 7) Text--The user may specify the font, size, color, etc. of any text used in the pie chart. 8) Exploding Option--As a default, all pie segments will be enclosed within a circle. The user may specify, however, that selected segments be "exploded" or set off radially from the rest of the circle. 9) Legend--The user may specify a legend (such as a color code index) positioned, for example, in the lower right corner of the chart or other location. 10) "Other" Category Creation--When using pie charts, sometimes the data for the chart does not add up to exactly 100%. If this is the case, the user may specify an "other" category to be automatically included for the remaining percentage of the pie chart. For the default setting, an "other" category would not be automatically created. The above-described parameters for bar charts or pie charts exemplify the type of parameters that the user may be prompted to enter by the block 159 (FIG. 9) or that may be included as fields in the variable database 108. All parameters should have default settings such that graphs can be generated without the user specifying each parameter. As will be evident to those skilled in the art, other types of graphs (line graphs, scatter diagrams, etc.) that may be generated in accordance with the present invention may include slightly different parameters (i.e. dot size, line width, etc.). Also, the present invention provides unlimited flexibility to use other parameters to specify any type of graph. The block 162 (FIG. 9) saves the graph parameters specified by the user (or in the database) as data pairs in the text box, with the parameter data preceding the parameter name. These data pairs will be converted into Postscript.RTM. variables and used by the EPS graph file which generates the desired graphs. The EPS Graph File Referring back to FIG. 9, the block 164 places the Encapsulated Postscript.RTM. (EPS) Graph file into the image box created in the template file. The EPS graph file contains Postscript.RTM. code that is executed as the pages are interpreted to generate the graph. (Alternatively, the graph file could be written in a different page description language than PostScript.RTM.). FIGS. 9A-1, 9A-2, 9A-3 and 9A-4 are flowcharts illustrating the programming of the EPS graph file which is executed by the interpreter. Referring first to FIG. 9A-1, the program begins at a block 920 which determines whether the graph type is a bar chart. (The graph parameters were either specified by the user at block 159 of FIG. 9 or contained in the database 108). If no, control passes to a block 976 (FIG. 9A-3) which determines whether the graph type is a pie chart. Alternatively, if the block 920 determines that the graph is a bar chart, a block 922 sets a scale transformation based on the size of the x- and y-axes. Next, a block 924 determines whether the user specified that the x-axis or y-axis should incorporate a broken scale. If yes, and the user did not specify where the axis should be broken, a block 926 then analyzes the data for "bunching" to determine where to break the axis. For example, if the graph values are all between 100 and 105, the block 926 will take the maximum and minimun values (105 and 100) and spread them over 80% of the axis. The remaining 20% of the axis will include a broken line to indicate the values between 0 and 100. If the block 924 determines that there is no broken axis, the programming skips block 926 and control passes to a block 928 which draws the x- and y-axes according to the specified parameters, such as color, width, orientation and (if specified) breaks. Next, a block 930 places the appropriate labels on the axes in accordance with the specified text style. (If no axes labels were specified, the block 930 is skipped). A block 932 then determines the number of graph value data pairs that were saved in the text box by the block 162 (FIG. 9) from the specified fields in the variable database 108. These data pairs from the text box will later be converted to Postscript.RTM. global variables. (See block 1114, FIG. 11). Next, a block 934 determines whether the width of the bars are fixed or variable. If variable, a block 936 calculates the width of the bars based on the amount of space that the user specified should be between the bars. If no space was specified, the block 936 calculates the width of the bars based on the default that the space between the bars should be equal to the width of the bars. After the block 936 calculates the bar width or, alternatively, if the block 934 determines that the bar width is fixed, a block 938 retrieves the first graph value data pair. A block 940 then determines whether the bars will be drawn as standard rectangles or whether a graphic object (i.e. truck, bottle, etc.) has been specified. If a graphic object has been specified, a block 942 determines whether the graphic object should be scaled or clipped. If the graphic object should be scaled (i.e. stretched or shrunk to correspond to the numeric value), a block 944 calculates the correct scale ratio. The block 944 assumes that the graphic object supplied by the user is at 100% size corresponding to the middle value on the y-axis. Thus, if the y-axis is scaled from 0 to 10 (middle value=5) and the data pair has a y-value of 8, the block 944 calculates the scale ratio as 8/5 or 1600%. A block 946 then retrieves the graphic object (from the file specified by the user), scales the graphic object by the calculated scale ratio and positions the scaled graphic object at the appropriate position on the x-axis. Alternatively, if the block 942 determines that the graphic object should be clipped, a block 948 draws a clipping box corresponding to the y-value from the data pair. The block 948 assumes that the user supplied graphic object is at 100% size corresponding to the maximum value on the y-axis. Thus, if the y-axis is scaled from 0 to 10 and the data pair has a y-value of 8, the block 948 draws a clipping box that extends from 0 to 8. A block 950 then retrieves the graphic object and positions it on the x-axis inside of the clipping box. Any portion of the graphic object outside of the clipping box will be deleted. Thus, the portion of the graphic object that would fall between 8 and 10 on the y-axis will be cut-off or clipped. If the user has specified that the y-axis is broken, the program determines where the break on the axis occurs and assumes that the minimum value on the graph corresponds to zero in order to determine how the bar (or image) should be scaled or clipped. If the block 940 determines that the chart will include only standard rectangular bars, a block 952 calculates the bar height based on the y-value from the data pair. A block 954 then determines whether the user specified two-dimensional (2D) or three-dimensional (3D) bars. If 2D, a block 956 draws the bar according to the previously determined height and width. The block 956 may also fill the bar with the specified or default color (including vignette shading, if specified). If 3D, a block 958 draws the "shadow" of 3D portion of the bar, including coloring or shading, if specified. A block 960 then draws the 2D (or front) portion of bar, with a modified (narrowed) bar width in order to accomodate for the 3D. The block 960 also colors and shades the portion as necessary. After the appropriate graphics object or bar has been drawn by the blocks 946, 950, 956 or 960, control passes to a block 962 (FIG. 9A-2) which determines whether any field name callouts have been specified. The field name callouts are the labels which may be placed at the base of the bars along the x-axis. If yes, a block 964 positions the field name at the specified location (inline or perpendicular with the bar). Otherwise, control skips to a block 966 which determines whether any numeric callouts have been specified. Numeric callouts are numeric values placed inside or on top of the bars to indicate their value. If yes, a block 968 positions the numeric callout at the specified location. After the block 968 or, alternatively, if the block 966 determines that no numeric callouts were specified, a block 970 determines whether any additional elements should be included on the graph. The block 970 may determine this by subtracting the number of data pairs processed from the total number of graph value data pairs (determined by block 932). If more data pairs should be included, a block 972 gets the next data pair and control returns to the block 940 (FIG. 9A-1). The loop of blocks 940-972 is repeated until all data pairs have been incorporated in the graph. After the block 970 determines that all data pairs have been processed, a block 974 then resets all of the Postscripts global variables in preparation for the next graph. If the block 920 (FIG. 9A-1) determines that the graph is not a bar graph, control skips to a block 976 (FIG. 9A-3) which determines whether the graph type is a pie chart. If yes, a block 978 sets a scale transformation and starting angle (based on user specified size or defaults) to begin drawing the pie chart. A block 980 then retrieves the first graph value data pair and sets a variable (called, for example, "TOTAL") equal to zero. The TOTAL variable will be used to keep track of the total combined values of the pie segments. A block 982 then determines whether the pie segment will be an "exploding" segment, which is set off from the circle. If yes, a block 984 calculates a radial offset position to determine where to place the segment. Alternatively, if the block 982 determines that the segment is not "exploding," control skips to a block 986 which determines whether the pie segment is two-dimensional (2D) or three-dimensional (3D). If the block 986 determines the segment if 3D, a block 988 draws/strokes the side (or 3D portion) of the pie segment and also colors/shades it appropriately. If the segment is 2D, or after the block 988 draws the 3D portion of the segment, a block 990 draws/strokes the 2D portion of the pie segment corresponding to the value retrieved by the block 980. The block 990 also fills the pie segment with the specified color, pattern and/or shading. The program then skips to a block a block 992 which determines whether numeric callouts are specified. Numeric callouts are the numeric labels placed inside or next to the pie segments which indicate their value. If the block 992 determines that numeric callouts were specified, a block 994 calculates the radial position of the numeric callout and a block 996 places the numeric value in the appropriate font, color, etc. at the radial position calculated by block 994. Alternatively, if the block 992 determines that no numeric callouts were specified, control skips to a block 998, which determines whether any field name callouts were specified. Field name callouts are labels placed inside or next to the pie segments that indicate what the segment represents. If field name callouts are specified, a block 1000 places the field name above the numeric callout, if a numeric callout was generated by the block 996. If no numeric callout was generated, the block 1000 calculates a radial position for the field name and places that field name in the appropriate font, color, etc. at the calculated position. Control then passes to a block 1002 which determines whether a radial line should be placed between the numeric/field name callout(s) and the pie segment. If yes, a block 1004 draws a line from inside the segment (radius/2) to the numeric/field name callout radial position. If the block 1002 determines that no radial line should be drawn, control skips to a block 1006 which resets that radial offset position (which was set by the block 984 in accordance with the graph value from the first data pair) and a block 1008 increments the starting angle. A block 1010 then adds the data value (from the data pair) to the variable "TOTAL," which keeps track of the cumulative value of the segments and a block 1012 determines whether any additional elements (i.e. graph values from data pairs) should be included in the pie chart. If yes, a block 1014 gets the next data pair and control returns to the block 982. The loop of blocks 982-1014 is repeated until all data pairs have been processed. After the block 1012 determines that all data pairs have been processed, a block 1016 determines whether an "other" category should be included in the pie chart. (The "other" category is the remainder if the pie segments do not add up to 100%). If yes, a block 1018 calculates the value of the "other" category by subtracting the value of the variable TOTAL from 100%. A block 1019 then determines whether the value of TOTAL is equal to 100%. If no, a block 1020 creates an additional data pair with the value of the "other" category and control returns to the block 982 to draw the "other" segment. Alternatively, if TOTAL is equal to 100% (indicating the "other" data pair has already been created) or if no "other" category is needed in the pie chart, a block 1022 resets all of the Postscript.RTM. variables (which specified the graph parameters and values) in preparation for generating the next graph. If the block 976 determines that the graph is not a pie chart, the program may skip to a block 1024 (FIG. 9A-3), which determines that the graph is of another type (such as a line graph, scatter diagram etc.) and the program may continue with processing to generate that graph, as indicated by block 1026. Based on the programming illustrated for generating bar graphs and pie charts set forth above, one skilled in the art would be able to generate programming to implement another type of graph. 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 box. 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 156 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 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 tile. 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"31.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. Some book runs may also include pages which contain static information but are only included in certain books. For example, assume you are creating 6 page books wherein the first two pages are master pages and the second two pages are always variable. The last two pages of each book are selected from a group of 100 different static pages. If these pages are treated as variable, they would be RIPped each time they were included in a book. In order to avoid RIPping these same 100 pages repeatedly, the 100 pages are RIPped (one time) as master pages and stored in an EPS (encapsulated PostScript.RTM.) file. The press command file then retrieves the desired pages (from the group of 100 pages stored in EPS files) based on the entry in the database. This technique greatly reduces processes time. FIG. 11 is a flowchart illustrating the programming implemented by the RIP 82 (FIG. 4) to process the variable graphics information. As described above in connection with FIG. 9, the EPS graph file (FIGS. 9A-1 through 9A-4) was placed in an image box and a text box including the graph parameters and values was layered over the image box. The text box was then "tagged" to indicate that it contained variable graph information. Referring again to FIG. 11, a block 1100 begins the RIP (or interpretation) process of the PDL master page files 122 and PDL variable page files 137, 138 (FIG. 5). Preferably the PDL files are PostScript.RTM. and the RIP 82 is a PostScript.RTM. RIP. However, the invention may be implemented with other page description languages. A block 1101 then redefines the PostScript.RTM. "show" operator or command. The standard PostScript.RTM. show operator "paints" characters identified in a string onto the current page. The Postscript.RTM. page files will include a "show" command after each text box on the page. A block 1102 sets all the graph parameters (size, colors, labels, etc.) to their default values and saves the parameters as Postscript.RTM. (PS) global variables. This step allows graphs to be generated even if the user did not specify any graph parameters. A block 1104 then interprets the first Postscript.RTM. element on the page. As described in detail below, the redefined show operator will be used to process the EPS graph file. A block 1106 then determines whether the PostScript.RTM. element is the "show" operator. If the PS element is not a show command, a block 1108 RIPs the element as normal and a block 1110 retrieve the next PS element and control returns to the block 1106. If the block 1106 determines that the PS element is a show command, a block 1112 then determines whether the text box immediately preceding the show command was "tagged" as containing graphics information. As described above, the graphics information text box was "tagged," for example, by using text delimiters or by specifying an unusual color or font (FIG. 9, block 163). Thus, the block 1112 checks for the text delimiter or the unusual color or font. If the block 1112 determines that the text box is "tagged" (contains variable graphics information), a block 1114 invokes the redefined "show" operator (defined by block 1101). The redefined "show" operator does not "paint" the text box as usual. Instead, the redefined "show" operator parses the graph parameters and graph value data pairs in the text box and saves them as PostScript.RTM. global variables. If the user specified graph parameters, these would override the default values saved by the block 1102. The PostScript.RTM. global variables will be used by the EPS graph file (FIGS. 9A-1 through 9A-4) to generate the graph. Alternatively, if the block 1112 determines that the text box was not "tagged," a block 1116 invokes the standard Postscript.RTM. "show" operator to paint the text box as normal. After the blocks 1114 and 1116, a block 1118 determines if there are more PostScript.RTM. elements to process. If yes, a block 1110 retrieves the next element and control returns to the block 1106. After the block 1114 invokes the redefined "show" operator to save the graph parameters and values as global variables, one of the next elements retrieved by the block 1110 will be the EPS graph file, which will be executed by the block 1108 to generate a graph. The loop of blocks 1106-1118 is repeated until all PostScript.RTM. elements have been processed. After all elements have been processed, the programming ends at a block 1120 which determines that the processing of the Postscript.RTM. file is complete. The programming of FIG. 11, including the redefinition of the PostScript.RTM. "show" operator, may be implemented by the following exemplary code. The exemplary code assumes that text delimiters were used to "tag" the text boxes with variable graph information and, as is conventional with QuarkXPress.RTM., the "show" operator is represented by "d". Also, in the exemplary code, the section beginning with the line "dup doss ss . . . " is the QuarkXPress.RTM. for the standard "show" operator.
%Variable Graphing Enabled
/zOnPage 0 def
/zBeginVar 0 def
/initializepage {
/zOnPage zOnPage 1 add def
QuarkXpress_3.32 begin
/Param 1 def
/d % redefine show operator
{dup (%#?!EndVariableGraphData) eq
{/zBeginVar 0 def pop pop pop pop}
{dup (%#?!BeginVariableGraphData) eq
{/zBeginVar 1 def pop pop pop pop}
{zBeginVar 1 eq
{
zOnPage 1 gt{
Param 9 gt{/Str1 (Param)def}
{/Str1 (Param)def}ifelse
/Str2 Param dup 9 gt
{( )}{( )}ifelse cvs def
/Str1 5 Str2 putinterval
Str1 cvn exch def
Param 1 add /Param exch def
} if
pop pop pop pop
}
{
%Quark code for standard show operator
dup doss ss and{sym fmtx makefont/xpfs X
0 0 3 -1 roll{s1 0 3 -1 roll put
s1 chkch{g xpfs setfont w G}
{w}ifelse 3 -1 roll add 3 1 roll add exch}
forall}
{w}ifelse pop 3 -1 roll sub 3 -1 roll div
3 -1 roll exch sub 0 32 3 -1 roll 0 5 -1 roll
doss ss and{xpash P3}{Q}ifelse
}ifelse
}ifelse
}ifelse
}def
end/pm save store mT concat}bd
Alternative Methods for Generating Variable Graphs Several alternative methods may be used to create graphs containing variable information. The first alternative method is preferable because, as explained in detail below, it results in faster processing time by reducing the size of the EPS file. Alternative #1--Graph Design EPS File The first alternative method provides an additional software package (called, for example, "Graphics Designer") to the user/customer who creates the database containing the variable information. The Graphics Designer program allows the user to interactively create graphs, using real or dummy data points. Thus, the user can experiment and preview what the graphs will look like after they are printed. For example, the Graphics Designer program allows the user to change any attributes, such as graph type, size, colors, line widths, etc. Once the user is satisfied with the preview of the graph, those graph attributes are saved. Thus, the Graphics Designer program allows the user to select graph attributes through creating preview graphs, rather than by just specifying attributes, as set forth above. The Graph Designer program also prompts the user to specify the fields in the database that will be used to generate the variable graphs. The specified database fields may contain graph data points and/or graph attributes. The output of the Graph Designer program is an EPS file ("the graph design EPS file") that specifies the graph size and attributes selected by the user and also references the fields in the database that will be used to generate the graph. The graph design EPS file also references an external EPS file, that will be used to draw the graph. The external EPS file may be, for example, the EPS Graph file described above in connection with FIGS. 9A-1 through 9A-4, or any other type of graph engine file for generating graphs. Also, the external graph engine file could be a series of separate files, where each file generates a different graph type (e.g. one graph file for bar charts, another graph file for pie charts, etc.) A sample graph design EPS file is as follows:
%!PS-Adobe
%GraphName Identifier
%BoundingBox 0 0 221 410 % graph size
%Data: aD1 aD2 aD3 aD4 % database fields
%XAxisName
% . . .
%end Data
/cD1[0 0 0 1]def % attributes to
/cD2[0 1 0 0]def % override default
/sYAxisName (Widgets required) def
. . .
EngineLoaded not { % call external graph file
(BarGraphEngine.ps) run
/EngineLoaded true def}if
Referring to the sample graph design EPS file above, the comment lines (beginning with "%") indicate a graph name selected by the user and the graph size, which is specified by defining the four corner points of a bounding box. The remaining comment lines are the database fields that will be used to generate the graph. For example, D1, D2, D3 and D4 are field names that contain the data points for the graph. "XAxisName" is the name of a database field that controls a variable graph attribute (the x-axis label). It is understood that the graph design EPS file can contain any number of comment lines specifying database fields. Following the comment lines, the graph design EPS file contains graph attributes that were specified by the user and will be used to override the default values. For example, the y-axis label is specified as "Widgets Required." Again, the graph design EPS file may contain any number of lines to specify the selected graph attributes. The graph design EPS file ends with a call to the external EPS graph file that will be used to draw the graph. In our example, the file is called "BarGraphEngine." The external EPS graph file is preferably stored in a file system associated with the RIP. The graph design EPS file first loads the external EPS graph file into memory. Once the external EPS graph file is loaded, it can be repeatedly executed, resulting in faster processing time. When implementing the first alternative embodiment with the EPS graph design file, the process of creating the template files is simplified. Referring back to FIG. 9, the blocks 159-163 are eliminated. Thus, after the block 157 determines that a variable graph element should be added, the block 158 creates an image box at the selected location and then the block 164 places the EPS graph design file (rather than the FIG. 9A-1-4 EPS graph file) into the image box. The blocks 159-163 are eliminated because the graph attributes and database fields are specified in the EPS graph design file. The EPS graph design file is also much shorter and simpler than the EPS graph file, resulting in faster processing time. Also, because use of the graph design EPS file eliminates the need to "tag" text boxes and the graph parameters are specified in the graph design EPS file, the processing of FIG. 11 is also eliminated. The graph design EPS file method does not need to redefine the "show" operator. As set forth above, the graph design EPS file is placed in an image box. During the normal RIP (interpretation) process, as the image box is processed, the graph design EPS file is executed, which also runs the graph file to generate the graph. The other alternative methods (alternative #s 2-4) provide less flexibility, particularly in creating complex graphs. However, the alternative method #s 2-4 eliminate the need for the EPS graph file (FIGS. 9A-1 through 9A-4) and the need to redefine the Postscript.RTM. "show" operator to process the EPS graph, which reduces complexity, cost and processing time in the system. Alternative #2--Named Image Boxes The second alternative method is useful when printing simple bar graphs. Generally, the method creates a bar chart with each bar at 100% of the value. Image boxes filled with the background attributes are sized according to the values in the database, and placed over the 100% bars such that only the correct data value shows. The "Named Image Box" method is illustrated in FIGS. 11A-1 through 11A-2. For example, assume a document is to contain a bar graph illustrating the 1996 sales, 1997 sales and 1998 projected sales for the entries in the sample database set forth above. The maximum value in the database is 100 and the first entry contains the following values: 1996 Sales: 25 1997 Sales: 50 1998 Proj.: 75 Referring to FIG. 11A-1, the first step is place a bar chart at the desired place in the document which contains three bars (representing 1996 sales, 1997 sales and 1998 projecting sales). Each bar may be a different color (red, green and blue) drawn on a background and each bar is drawn extending up to the maximum or 100% value (100). The next step is to place a named image box over the bars to cover a certain percentage of the bars (i.e. cover 50% of the bars). Each named image box should have the attributes of the graph background (e.g. colored white) and should be borderless (except if the bars are to be outlined in black, the bottom border of the named image box should also be black). The name on the image boxes should correspond to the field names in the database corresponding to the data value for that bar. Thus, in our example, the image boxes will be named "1996Sales," "1997Sales," and "1998Proj." and are represented by dashed lines on FIG. 11A-1. The first two steps of creating the 100% graph and placing the named image boxes replaces the blocks 158-164 (FIG. 9) when creating the template files in, for example, QuarkXPress.RTM.. The final step is to use the data contained in the specified database fields to adjust the size of the named image boxes to correctly size the bars. This step would occur during processing of the image boxes on the template files to create the PDL master and variable files (FIG. 10c, blocks 262-268). The program first retrieves the data value for the first entry in the database corresponding to the name of the image box. The program then adjusts the bottom of the box to the correct value. In our example, the correct value for the first bar is 25--therefore, 75% of the bar should be covered by the image box. This is calculated by the following equation: ##EQU1## The named image box was originally positioned to cover only 50% of the bar--therefore, the bottom of the named image box must be extended to cover an additional 25% of the bar. The second data value in our example is 50--thus 50% of the bar should be covered. Because the image box was originally positioned to cover 50% of the bar, no adjustment is need. The third data value is 75--only 25% of the bar should be covered. The image box must therefore be reduced. The adjusted named image boxes are represented by dashed lines in FIG. 11A-2. The same method may be used to place named image boxes to cover the correct percentage of graphic objects (such as bottles or trucks) which are used in place of standard rectangular bars. Alternative #3--Anamorphic Scaling This method is similar to the previous image box method and is particularly suited to create bar charts using graphic objects which can be anamorphically scaled to the correct data value. Like in the previous Named Image Box method, a graph is placed at the desired position on, for example, a QuarkXPress.RTM. document in the template file. A named image box containing a maximum (100% scaled) graphic object (such as a bottle or truck) is placed at each bar position such that the top of the graphic object/image box corresponds to the maximum data value. As before, the image boxes are named to correspond to fields in the database containing the data values. Next, during the processing of the image boxes during creation of the master and variable files, the data value is retrieved from the database field and the box is scaled (i.e. shrunk) corresponding to the data value. The graphic object is thus anamorphically scaled to fit inside the image box. The same method could also be used with standard rectangular bars. Alternative #4--Spreadsheet Graphs The fourth alternative method takes advantage of the graphing capabilities of a standard spreadsheet program (such as Microsoft.RTM. Excel.RTM.). Thus, it may be used to draw any type of graph that is supported by the spreadsheet program. Excel.RTM. graphing capabilities are described in the Microsoft.RTM. Excels User's Guide (Version 5.0), published by Microsoft.RTM. Corporation (1993-1994), particularly Part 3 (Chapters 15-19, "Creating Charts from Worksheet Data") and Part 9 (Chapters 41-42, "Exchanging Data with Other Applications"), which is incorporated by reference herein. The first step of the method is to place an image box corresponding to the size and position of the graph on, for example, the QuarkXPress.RTM. document in the template file. Next, graph data from the database 108 is retrieved and supplied into cells in an Excel.RTM. worksheet. The data can be supplied to Excel.RTM. using AppleScript (for Macintosh) or Object Linking and Embedding (OLE)(for Windows/PC). A counter is used to keep track of the graph data from the database that is supplied to the Excel.RTM. worksheet. Excel.RTM. is then instructed to create a graph from the data in the worksheet, according to the user specified graph parameters. The Excel.RTM. graph may be saved to an external file, which is then placed in the image box or can be linked back to the QuarkXPress.RTM. image box using conventional OLE techniques. Referring to FIG. 9, the above-described steps replace the blocks 160-164. The Spreadsheet Graphing method is illustrated by the following pseudo-code: Place image box on Quark document
Begin Loop
Start counter = 1
For each piece of data to be graphed
Get data from database
Put data into cell A[counter] of
| ||||||