Apparatus, methods, programming for automatically laying out documents

[0002] The present invention relates to apparatuses, methods, and programming for automatically laying out documents. Many of the invention's aspects relate to such automatic document layout in the context of variable data publishing.

[0003] Programs have been created in the prior art for laying out documents, such as the pages of books, magazines, brochures, or even individual pages created in a word processor document. Most such programs are also capable of laying out an image of a page, interactively, on a computer screen. Some such programs define a document as a collection of text and shape elements. Such text elements each have text attributes, such as font, size, indentation, etc. Such shape elements include image elements, graphic shapes, and text containers, and can have shape attributes, such as position, size, color, border characteristics, fill color, etc. In many such systems, a user can define a template which includes various text and shape elements, such as the template of a newsletter, a set of related brochures, or a given type of letter, and then users can insert individual content into all, or some of, the template's elements as desired. When the system lays out the document, each element will be displayed with its associated attributes.

[0004] In such systems, as the content placed into various elements of a template changes, those elements often change in size. Such size changes can make the template look inappropriate. In systems where the user is entering the variable content manually with a mouse or keyboard, or in which a user has time to review each document for proper layout, it is often acceptable to have a user change the layout to account for such size changes. Nevertheless, even in such applications it would be desirable to have a layout system which can more appropriately automatically adjust to changes in the size of content placed into template elements.

[0005] Furthermore, there are many automatic layout applications in which it is quite impractical to have a user individually change the layout of each document. This is particularly true in variable data publishing, in which many different versions of a document are created automatically in response to different data records. FIG. 1 provides graphic representation of variable data publishing. In its highly simplified example, a document 2 is created from a document template 3. The template has variable elements 4, 5, 6, and 7 into which variable values 8, 9, 10, and 11 can be automatically mapped, depending upon the individual record 12 in the Profile Data Source 14 for which the document 2 is being produced. In the example of FIG. 1, the variable values 8, 9, and 10 are simple text (i.e., character string) values taken directly from the values of fields 15, 16, and 17 of a record 12A in the profile data source 14. The variable value 11 is an image contained in an image file 18 selected as a function of the “Sport” field 17 in the profile data source.

[0006] Because variable data publishing often maps values which differ in size into variable elements, the appearance of a variable document can vary greatly. Furthermore, for some records, data may be missing for certain variable elements. But since variable data publishing often creates hundreds, or thousands, of different versions of a given document, it would be very costly to have each version's layout individually reviewed and adjusted by a person to compensate for changes in the size of its variable values.

[0007] Also, although the relatively simple form of variable data illustrated in FIG. 1 can be very useful, it would be desirable to create a variable data publishing system which provides much greater flexibility in terms of possible content, and yet still tends to do a good job of automatically laying out the resulting documents in a way which is attractive to the eye. For example, it would be desirable to allow a given template to be used to communicate about a greater number of topics, using a greater range of possible variable content, and still have a high likelihood that the automatic layout of the document will look appropriate.

[0008] A few prior art systems have allowed the variable values which can be mapped into a template to be comprised of a sub-tree of text and/or shape elements. This greatly increases the flexibility of individual templates, but, if such sub-templates are allowed to vary in size, their use can increase the difficulty of achieving desirable layout. Similarly, it would be desirable to have a system which allows content data, including variable sub-templates, to be used in different templates and still look appropriate given the different size and shape available for it in such different locations.

[0009] Another issue in variable data publishing is that it often takes a lot of effort to define the rules used for mapping variable content into the variable elements of a template. In many prior art systems, defining rules to map variable values into a template often requires knowledge of data bases, programming scripts, and data base query languages. These are often different skill sets than those had by many of the graphic artists who are best at designing document templates.

[0010] Also it would be desirable in layout systems, including variable data publishing ones, to be able to have a system which makes it easier to create shape elements Which have a matching or coordinated appearance.

[0011] It is an object of the present invention to provide a system for laying out documents that can automatically adjust the layout process in a flexible and often appropriate manner to changes in the size of the contents placed inside document shape elements.

[0012] It is another object of the invention to provide such a system for laying out documents which makes it easy to create flexible document templates for use with such a system.

[0013] It is yet another object of the present invention to provide a variable data publishing system which provides flexible automatic adjustment in response to changes in the availability, nature, and/or size of variable data which is placed into variable elements of a document template.

[0014] It is still another object of the present invention to provide a variable data publishing system which allows more than just the contents of a variable element in a document template to change in response to the mapping of different variable values into those variable elements.

[0015] It is yet another object of the present invention to provide greater flexibility in the way in which a variable data publishing system allows document templates and content-mapping rules to be used together.

[0016] It is still another object of the present invention to provide greater flexibility in the way in which variable data can be selected for use in variable data publishing.

[0017] It is yet another object of the present invention to provide a layout system which allows greater ease and uniformity in the way in which the attributes of both text and shape elements can be defined.

[0018] The invention is most accurately described in the claims at the end of this specification, and those claims should be considered part of this Summary Of The Invention. However, to prevent lengthy repetition, the wording of the claims has not been repeated nor closely paraphrased in this section. Instead the following brief summary has been provided here to give a quick overview of the major different aspects of the invention and some of their uses. Since it is impossible to make such a brief overview as accurate as the detailed description contained in the claims, the following summary should not be used to limit the claims in any way. Furthermore, in the interest of brevity, many significant aspects of the invention recited in the claims are not mentioned in this summary, and the failure to mention such aspects here should not in any way be construed as an indication of their lack of importance. Finally, the brief description of the use of each aspect of the invention provided in this section is not, in any way, meant to provide a complete description of that aspect's use, but instead is intended to give the reader a quick indication that each such aspect of the invention has a useful purpose.

[0019] According to one aspect of the present invention, a computerized system can lay out a document containing a combination of text and/or shape elements located within a sequence box, such as a vertical group box or a horizontal group box. A user interface enables a user to define such a sequence box, and one or more shape elements in it, including shapes having a minimize and/or maximize property in at least one dimension. The system automatically lays out elements of the document. This includes: a) arranging shape elements placed within the sequence box along the sequence box's sequencing axis; b) minimizing the size given to any shape element which has the minimize property in a given dimension by tending to make the element as small as its contents, if any, will allow in the given dimension; and c) maximizing the size given to any shape element which has the maximize property in a given dimension by tending to make the element expand to encompass space available within the sequence box in the given dimension. This ability to automatically arrange shape elements which can both expand and contract within in a sequence box provides a useful tool for automatically arranging and sizing document elements in response to changes in variable data, particularly which such sequence boxes are nested.

[0020] According to another aspect of the invention, a computerized system can lay out a document template represented as a tree-shaped data structure having nodes corresponding to text and/or shape elements, some of which are variable elements. Content-mapping rules map user defined variable values into individual variable elements. The variable values can be sub-trees of text and/or shape element nodes. The user can give a shape element in such a sub-tree a maximize property in one or more dimensions. When a sub-tree value is mapped into a variable element, the root node of the sub-tree is grafted onto the variable element's node in the template's tree structure. The system lays out elements of the tree formed by the combination of the template's tree and sub-trees which have been grafted onto it. If a shape element in such a sub-tree has the maximize attribute in a given dimension, the layout tends to make the given shape element expand to encompass space available in the given dimension, in the location in the document into which the given sub-tree has been mapped. This allows sub-template variable values mapped into locations with differing available space to automatically adjust all, or part of their size, so as to more appropriately fit into such space.

[0021] According to a similar aspect of the invention, the user can define a sub-tree variable value to include a given shape into which a variable value can be mapped by content mapping rules, and can select that this given shape have a minimize property in at least one dimension. This will cause the layout of the document to tend to make the given shape element as small as the variable value, if any, mapped into the given shape value will allow in the given dimension. This allows the size of all, or a part of, a sub-template to automatically adjust to the size of its variable content.

[0022] According to another aspect of the invention, a computerized system can lay out a document template represented as a tree-shaped data structure comprised of text and/or shape nodes, in which the user can define a node of the tree to be a variable shape element having the maximize or minimize property in one or more dimensions. The layout of such document templates minimizes the size given to variable shape elements that have the minimize property and maximizes the size given to variable shape elements that have the maximize property. This ability to cause a variable shape element's size to be defined either by the space around it or by the size of its own contents increases the ability of a template to make appropriate use of space as the size of its variable contents change.

[0023] According to still another aspect of the invention, a computerized system enables a user to select, as an anchor point, one of a plurality of locations on a given shape element within a document, and to vary the size of the contents of the given shape element. When the system lays out the document it can cause the size of the given shape element to be as small as the variable content will allow in one or more dimensions, while holding the given shape element's anchor point fixed, so that other portions of the given shape element expand or contract in response to the varying size of the shape's content relative to the fixed anchor point. This ability to control the direction in which shapes with variable contents expand and contract increases the ability of a template to maintain desired spatial relationships despite such size changes.

[0024] According to yet another aspect of the invention, a computerized system can lay out a document including variable image elements into which two dimensional images can be mapped. The system lets a user select a size attribute for a given variable image element in a first dimensions. When the system lays out the document, it gives the variable image element a size in the first dimension specified by the selected size attribute value and can automatically give the image a size in a second dimension which maintain the image's aspect ratio. This allows images mapped into a variable document to be automatically scaled to a desired size without being distorted.

[0025] According to still another aspect of the invention, a computerized system, which lays out different custom versions of a variable document in response to data contained in different data sets, can automatically suppress the layout of variable shape elements into which content-mapping rules have failed to map variable shape values for a given data set. This can prevent unwanted space gaps from appearing in the layout of variable documents.

[0026] According to another aspect of the invention, the variable elements used in a variable data publishing system each have an associated content type and an associated set of attribute-value pairs. A variable element's content type defines the type of variable value which can be mapped into the variable element. Such content types can include text, image, or template sub-tree. The variable element's attribute-value pairs are used to define the properties of the variable element. In the case of text elements such attributes can include font, size, and color. In the case of shape elements, they can include size, position, and color. The variable values which can be mapped into a variable element of a given content type may include both content of the given content type and values for individual attributes of the variable element. The layout causes the appearance given to a variable element to vary as a function of both the content and attribute values, if any, of the variable value that has been mapped into the variable element. This increases the flexibility of a variable data publishing system by enabling variable values to not only change the content of variable elements, but also their attributes.

[0027] According to still another aspect of the invention, a computerized system lays out a variable document, represented as a template of layout elements, some of which are variable elements. The system allows a user to select, from among a plurality of stored content-mapping rule sets, a selected set of such rules which are used to map variable values into the variable elements of the template for a given layout. This provides much greater flexibility in the use of a given template, since it allows a template to be used with different rule sets, such as, for example, rule sets which obtain data from different data bases or rule sets which use different selection criteria.

[0028] According to yet another aspect of the invention, a computerized system lays out different custom versions of different variable documents in response to data contained in different data sets. The system stores a plurality of document templates, each including a corresponding set of one or more variable elements, and it stores a set of content-mapping rules for mapping variable values into the corresponding set of variable elements. The system enables a user to select a template from the plurality of stored templates, then uses the content-mapping rule set to map variable values into the variable elements in the selected template, and then lays out the selected template with the variable values that have been mapped into it. This allows the effort which has gone into creating a rule set to be used with multiple templates, such as, for example, templates for different forms of a given document or templates for different documents in a given transaction.

[0029] The ability to store templates and rule sets separately indicated in these last two aspects of the invention makes it easier for people will skills in graphic arts to design templates and those with skills in data base technology to create rule sets.

[0030] According to still another aspect of the invention, a computerized system lays out different versions of a variable document template for different data sets that include corresponding fields. The content-mapping rules stored by the system include variable-query content-mapping rules, each of which defines a data-base query that varies as a function of the value of one or more data set fields. When the system generates a given version of the variable document for a give data set, it generates an instance of the variable query defined by each variable-query content-mapping rule as a function of the value of one or more fields in the given data set. It then sends each such variable query to a corresponding data base. It maps the variable value fetched by the data base in response to each variable query into the one or more variable elements corresponding to the individual variable-query content-mapping rule which defined that query. Then it lays out the variable document with such variable values. Such variable-query content-mapping rules increase the flexibility with which variable values can be mapped into a variable document, since such queries allow variable values to be selected as a more complex function of the data set, or record, for which each variable document is being produced.

[0031] According to yet another aspect of the invention, a computerized system produces a visual representation of a document having text and shape elements. The system stores user-defined models which can include both text and geometric models. Each text model defines attributes values for any text element defined by reference to it. Such text attributes can include, for example, font, size, and color. Each geometric model defines attribute values for any shape element defined by reference to it. Such shape attributes can include, for example, size, position, border-type, and color. The system represents the document as a tree of text and shape elements in which each text or shape element can have attributes values associated with it by referencing one of the user-defined text or geometric models, respectively. The system lays out each element of the document with an appearance, position, and size determined as a function of attribute values associated with the element, including attribute values, if any, associated with an element by reference to one of the user-defined models. This allows users to define shape styles in a manner similar to that which other layout programs have allowed users to define text styles, and, thus, increases the ease with which a template designer can create shape elements which share a common look.

[0032] The computer systems described in the summary above can be claimed in the form of computer apparatus, in the form of computer programming stored in a computer readable memory, and in the form of computerized methods. It should also be understood, that other aspects of the invention include combining individual aspects of the invention described above.

[0033] These and other aspects of the present invention will become more evident upon reading the following description of the preferred embodiment in conjunction with the accompanying drawings, in which:

[0034] FIG. 1 is a schematic representation of variable data publishing, a technique that has been known in the prior art;

[0035] FIG. 2 is a schematic block diagram of a system for performing variable data publishing that embodies many aspects of the present invention;

[0036] FIG. 3 is a graphical user interface window produced by the designer program shown in FIG. 2;

[0037] FIG. 4 is the partial representation of the XML contained within one template file of the type shown in FIG. 2;

[0038] FIG. 5 is a partial representation of one TSL file of the type shown in FIG. 2;

[0039] FIG. 6 is a graphical user interface window produced by the producer program shown in FIG. 2;

[0040] FIG. 7 is a partial representation of the XML contained in one area template file of the type shown in FIG. 2;

[0041] FIG. 8 shows a graphical user interface window of the designer program, similar to that shown in FIG. 3, after an area template corresponding to that partially shown in FIG. 7 is mapped into the template displayed by such designer window;

[0042] FIGS. 9 and 10 display the form and flex tabs, respectively, of the Properties Editor dialog box of the designer program's graphical user interface window;

[0043] FIGS. 11 and 12 display how a user can set the value of the flex-height-behavior attribute value by using a drop-down list box;

[0044] FIGS. 13 and 14 are graphical user interface windows of the designer program that show how changing the flex-height-behavior attribute of a vertical box from a minimized to a maximized value can change the layout of a template;

[0045] FIG. 15 illustrates how various flex height and flex-width-behavior attribute values affect the appearance of image elements;

[0046] FIGS. 16 and 17 are screen shots of the designer program's graphical user interface window that show how the ingestion of differently sized image values into a variable image element within a vertical box having a minimized height and width affects the appearance of a page's layout;

[0047] FIG. 18 shows the Anchor Point selection dialog box of the designer program;

[0048] FIGS. 19 through 30 illustrate the effect of selecting different anchor points upon the layout of flexible shape elements.

[0049] FIG. 31 shows the designer program's Character Properties dialog box;

[0050] FIGS. 32 through 34 show three tabs of the designer program's Paragraph Properties dialog box;

[0051] FIG. 35 shows the Define Styles dialog box of the designer program;

[0052] FIG. 36 shows the Variable List window of the designer program, which is virtually identical to the Variable List window of the producer program;

[0053] FIGS. 37 through 41 illustrate the producer program's Variable Editor dialog box, showing the different “Definition” areas of that dialog box which result from the selection of different types of content-mapping rules for variables defined in the Variable Editor dialog box;

[0054] FIGS. 42 and 43 illustrate the SQL query generated in response to the Variable Editor dialog box shown in FIG. 41, with FIG. 42 showing the SQL query in a variable form, and with FIG. 43 showing the same variable query once it has been instantiated with data from a profile record;

[0055] FIG. 44 illustrates the Job Setup dialog box of the producer program, which is used to define a job that will map variable values into a given template and cause the resulting layout to be output in a desired output format;

[0056] FIG. 45 shows a job set-up dialog box of the type shown in FIG. 45, illustrating how the dialog box enables the user to select with which of a plurality of possible templates a given job is used;

[0057] FIG. 46 is a partial version of a pf_data file, which represents all of the variable values that are mapped into a given template for a given document when a given job is run;

[0058] FIGS. 47 and 48 illustrate how a variable text value can have its contents and attribute values grafted into a variable text element, and how the language_id attribute value can be used to select which hyphenation dictionaries are used in the layout of text elements;

[0059] FIG. 49 illustrates how the system shown in FIG. 2 allows different sets of content-mapping rules to be used with a given template, and how it allows a different template to be used with a given set of content-mapping rules;

[0060] FIG. 50 illustrates how aspects of the present invention can be used to enable a given set of content-mapping rules to be used with different templates, some of which can be used to create HTML pages for distribution over the world wide web and some of which can be used to create TDF files that can be downloaded over the web for viewing or printing;

[0061] FIG. 51 illustrates a portion of a template tree as it has been instantiated by the ingestion of an area template variable value;

[0062] FIG. 52 provides a graphical representation of the layout elements shown in FIG. 51, illustrating the margins, bumpers, and flex attribute values that affect the layout of those elements;

[0063] FIGS. 53 through 56 show how the portion of the template tree shown in FIGS. 51 and 52 look when different data values are ingested into them;

[0064] FIGS. 57 and 58 illustrate how a given area template variable value can be ingested into different templates and, because of flex attribute values, can have considerably different appearance when being ingested into those different templates;

[0065] FIG. 59 provides a highly simplified pseudo-code description of some of the main control functions of the designer program shown in FIG. 2;

[0066] FIG. 60 shows a highly simplified pseudo-code description of the fileNew sub-routine called in FIG. 59;

[0067] FIG. 61 shows a highly simplified pseudo-code description of the fileSave sub-routine called in FIG. 59;

[0068] FIG. 62 shows a highly simplified pseudo-code description of the fileOpen sub-routine called in FIG. 59;

[0069] FIG. 63 shows a highly simplified pseudo-code description of the createShape-Element sub-routine called in FIG. 59;

[0070] FIG. 64 shows a highly simplified pseudo-code description of the selectShape sub-routine called in FIGS. 59 and 63;

[0071] FIG. 65 shows a highly simplified pseudo-code description of the resizeShape sub-routine called in FIG. 59;

[0072] FIG. 66 shows a highly simplified pseudo-code description of the properties-Editor sub-routine called in FIG. 59;

[0073] FIG. 67 shows a highly simplified pseudo-code description of the insertimageFile sub-routine called in FIG. 59;

[0074] FIG. 68 shows a highly simplified pseudo-code description of the addElement-ToAreaTemplate sub-routine called in FIG. 59;

[0075] FIG. 69 shows a highly simplified pseudo-code description of the remove-ElementFromAreaTemplate sub-routine called in FIG. 59;

[0076] FIG. 70 shows a highly simplified pseudo-code description of the createGroup-Box sub-routine called in FIG. 59;

[0077] FIG. 71 shows a highly simplified pseudo-code description of the createVBox sub-routine called in FIG. 59;

[0078] FIG. 72 shows a highly simplified description of the createHbox sub-routine called in FIG. 59;

[0079] FIG. 73 shows a highly simplified pseudo-code description of the insertShape-InText sub-routine called in FIG. 59;

[0080] FIG. 74 shows a highly simplified pseudo-code description of the selectText sub-routine called in FIG. 59;

[0081] FIG. 75 shows a highly simplified pseudo-code description of the character-Properties sub-routine called in FIG. 59;

[0082] FIG. 76 is a highly simplified pseudo-code description of the paragraphProperties sub-routine called in FIG. 59;

[0083] FIG. 77 shows a highly simplified pseudo-code description of the textstyle sub-routine called in FIG. 59;

[0084] FIG. 78 shows a highly simplified pseudo-code description of the shapeStyle sub-routine called in FIG. 59;

[0085] FIG. 79 shows a highly simplified pseudo-code description of the variableList sub-routine called in FIG. 59;

[0086] FIG. 80 shows a highly simplified pseudo-code description of the export sub-routine called in FIG. 59;

[0087] FIG. 81 shows a highly simplified pseudo-code description of the import sub-routine called in FIG. 59;

[0088] FIG. 82 shows a highly simplified pseudo-code description of the selectProject sub-routine called FIG. 59;

[0089] FIG. 83 provides a highly simplified pseudo-code description of some of the main control functions of the producer program shown in FIG. 2;

[0090] FIG. 84 shows a highly simplified description of the variableEditor sub-routine called in FIG. 83;

[0091] FIG. 85 shows a highly simplified pseudo-code description of the jobSetup sub-routine called in FIG. 83;

[0092] FIG. 86 is a highly simplified pseudo-code description of the jobPreview sub-routine called in FIG. 85;

[0093] FIG. 87 shows a highly simplified pseudo-code description of the createVariable-ValueTree sub-routine called from FIGS. 86 and 90;

[0094] FIG. 88 shows the map sub-routine called by the createVariableValueTree sub-routine shown in FIG. 87;

[0095] FIG. 89 shows the mapVariableValuesIntoVariableElements sub-routine called from FIGS. 87 and 90;

[0096] FIG. 90 shows the runJob sub-routine called from FIG. 85;

[0097] FIG. 91 shows the generateHTMLPage sub-routine, which is called by the runJob sub-routine of FIG. 90 to produce an HTML layout for a page;

[0098] FIG. 92 shows the printPage sub-routine, which is called by the runJob sub-routine of FIG. 90 to create a layout for a printed page;

[0099] FIG. 93 shows the updateScreen sub-routine, which is called by both the designer and producer program shown in FIG. 2 to interactively update screen images of the layout of a given template or job in response to changes or selections made by a user;

[0100] FIG. 94 is a highly simplified pseudo-code description of the main layout sub-routine, which is called for individual page elements within a template and for all shape elements contained within a page;

[0101] FIG. 95 is a highly simplified pseudo-code description of the layoutEmptyShape sub-routine, which is called by the layout routine of FIG. 94 to lay out empty shapes;

[0102] FIG. 96 is a highly simplified pseudo-code description of the layoutlmageElement sub-routine, which is called by the sub-routine in FIG. 94 to lay out image shapes;

[0103] FIG. 97 is a highly simplified pseudo-code description of the layoutShapeIncludingFloatingElements sub-routine, which is called by the layout routine of FIG. 94 to lay out shapes that have floating text or shape elements within them;

[0104] FIGS. 98A and 98B are a highly simplified pseudo-code description of the layoutShapeIncludingFixedElements sub-routine, which is called by the layout routine of FIG. 94 to lay out shape elements that have fixed child shape elements;

[0105] FIG. 99 is a highly simplified pseudo-code description of the layoutHBox sub-routine, which is called by the layout routine of FIG. 94 to lay out h-box shapes;

[0106] FIG. 100 is a highly simplified pseudo-code description of the layoutVBox sub-routine, which is called by the layout routine of FIG. 94 to lay out v-box shapes;

[0107] FIG. 101 is a highly simplified pseudo-code description of the findMinDerived-Width sub-routine, which is called by the routines of FIGS. 98A and 98B, 99, and 100 to estimate the minimum width a shape requires to be laid out properly;

[0108] FIG. 102 is a highly simplified pseudo-code description of a findMinDerived-Height sub-routine, which is called by the routines FIGS. 98A through 100 to estimate the minimum height a shape requires in order to be laid out properly; and

[0109] FIG. 103 is a highly simplified pseudo-code description of the allowChildsMaximizedHeight sub-routine, which is called by the sub-routines of FIGS. 98A, 98B, 99, and 100 to maximize the height of elements having maximized height after they have been laid out with a minimized height.

[0110] FIG. 2 illustrates a computer system 100, which forms one possible embodiment of the invention. The system 100 includes a computer 102, which in a preferred embodiment of the invention is a computer running the Microsoft NT operating system, but which in other embodiments of the invention can be any computer having enough power to run a document layout program. The computer 102 includes a CPU 104 for executing instructions; a random access memory (RAM) 106 for storing instructions and data to be used or written by the CPU; a video output device for enabling the computer to create screen images on a computer screen 110; and an I/O device 112 for receiving input from a keyboard 114 and a mouse 116 and for supplying output to a printer 118. The computer 102 also includes a hard disk 120 on which the computer can store programs and data.

[0111] The disk 120 includes an operating system program 112, which is the Microsoft NT operating system in the preferred embodiment of the invention, but which in other embodiments in the invention could be Microsoft Windows, the Macintosh operating system, the Sun operating system, the Lenix operating system, UNIX, or any other operating system capable of providing a graphical user interface to a computer. The hard disk also stores three programs that are used in the preferred embodiment of the present invention, a designer program 124, a producer program 126, and a server program 128.

[0112] FIG. 3 is a screen shot of the graphical user interface (GUI) window of the designer program 124 shown in FIG. 2. This program provides a user interface for creating, opening, editing, and saving the template files 130 shown symbolically in FIG. 2. The designer window 152, shown in FIG. 3, can be selected to contain a structure view 154 which provides a graphical representation of the shape and text layout elements in the tree-shaped data structure of the template currently being edited by the designer program.

[0113] FIG. 4 is a portion of the XML text of the template file 130 corresponding to the template shown in the designer window of FIG. 3. As is well known in the art, XML is the Extensible Mark-up Language. XML is an extensible mark-up language, in the sense that in it a programmer or user is allowed to define new tag types. As will be explained below, in the preferred embodiment, users are allowed to define new tag types for text and shape layout elements. XML is capable of representing hierarchical, or tree-shaped, data structures in the form of tag text. As can be seen by looking at FIG. 4, it normally marks texts, or other elements, by enclosing them between a start and a corresponding end tag. The start tag includes a tag name and zero or more attribute-value pairs in the general form

[0114] <tagName attribute 1=“value1” attribute2=“value2” . . . >

[0115] The corresponding end tag will have the form

[0116] “</tagName>”

[0117] The tree-shaped data structure of the template is represented by a nesting of elements between the start and end tags of their parent elements. For example, the entire document starts with a tag “<_DOCUMENT>” labeled with numeral 174 and ends with an end tag that is “<\_DOCUMENT>” labeled with the numeral 174A. Similarly, the tag that starts the representation of page two in the document shown in the structure view of FIG. 3 starts with a tag 176 that contains the tag name “PF_Page_Base” and ends with the tag 176A shown near the bottom of FIG. 3, which has the corresponding tag name preceded by a slash. As stated above, by looking at the nested elements of the XML file shown in FIG. 4, one can see the correspondence of those elements to the elements shown in the structure view of FIG. 3 in which corresponding elements have corresponding numerals, with the exception that the end tags of elements have the same numeral with the letter A added.

[0118] Once an XML template file is loaded into the designer program, it is translated into a corresponding tree data structure in which the elements of the tree are linked by pointers to increase the speed at which the designer program can process its elements. The elements of a template's tree structure include both shape layout elements and text layout elements.

[0119] Shape layout elements include the following: document pages 155; text containers 156, which are rectangular or oval shapes into which text elements can be placed; image elements 158, which are rectangular shapes into which images can be placed; plain group boxes 160, in which included elements have fixed positions relative to a corner of the group box; vertical group boxes 162, in which elements are sequenced along a vertical axis; horizontal group boxes 164, in which included elements are arranged along a horizontal sequencing axis; and area template boxes 166, which are containers into which a sub-tree of the template, having as its root element a shape element, can be placed. Shape elements can also include rectangular or oval graphic shapes that can be created and sized by the user to form graphic designs, such as bars between the sections of a document.

[0120] Text layout elements, such as the elements 170 shown in FIG. 3, occur inside text boxes in a floating layout, which means they are laid out along one or more horizontal line occurring within the text box. Text can also be comprised of hierarchical elements. For example, in FIG. 46 the variable text value 398A, which will be mapped, or “ingested”, into a variable text element, has three levels of hierarchy: that defined by the “DestinationDescrip” start and end tags, that defined by the “head” and “body” start and end tags, and that defined by the “bold” start and end tags. The text elements can include more complicated sub-trees, including elements comprised of formatting tags that define text attributes for the elements they enclose, elements corresponding to individual paragraphs, one or more possible levels of nested elements comprised of text attributes to be applied to parts of paragraphs or lines of text, and the actual text elements themselves.

[0121] In the structure view in FIG. 3 certain template elements have corresponding entries in a variable column 177 shown at the right hand side of the structure view. Each such entry is a variable name that occurs between left and right arrow characters, “<” and “>”, respectively.

[0122] Each such variable name indicates that its corresponding template element is a variable element, meaning that it is an element into which a variable value can be mapped when the template is used to produce a set of one or more variable data documents. As can be seen from FIG. 4, the XML equivalent of a variable element shown in the structure view includes within its start tag an attribute-value pair 180, which starts with the text “data_tag=” and is followed by a string in quotation marks corresponding to the variable name shown in the variable column 177 of FIG. 3. As will be explained below, when a set of one or more variable documents is produced for a template, each variable element in the template will have a variable value mapped into it with a content-mapping rule having the same variable name as the variable element. The template, which is partially shown in FIG. 4, has statically defined default values, both for its content values, i.e., its portions contained between its start and end tags, and for each of the attributes that has an attribute-value pair in its start tag.

[0123] As is explained below in more detail, when a variable value is mapped or ingested, into a variable element, the variable value's content will replace that of the variable element and any attribute-value pairs included within the variable value's start tag, and will replace the value of any corresponding attribute-value pair contained within the variable element.

[0124] As shown in FIG. 3, the designer program's GUI window also has a document window 155, which provides an interactive display of the layout of that portion of a selected page of the current template that fits within the layout window. In FIG. 3, elements shown in the document window 155, which correspond to those in the structure view 154 have corresponding numerals. This allows a user to see the laid-out appearance of various elements in the template as the user creates or changes them. The structure view and the document window also allow a user to see a given template with variable data that has been ingested into it according to a given document creation job.

[0125] The system shown in FIG. 2 also includes, in addition to the designer program, a producer program that enables a user to produce and define document creation jobs, each of which can create a set of one or more variable data documents based upon a selected template that has been produced by the designer program 124. The producer program enables a user to create one or more project files 132, shown schematically in FIG. 1. Each such project file contains a set 134 of content-mapping rules, each of which has a variable name, for mapping variable values into variable elements of a template that have the corresponding variable names.

[0126] The rules in the rule set of a project file are often called variables. This is because each of them has a variable name. When a rule set is used to map variable content into a template, there should be one content-mapping rule, or variable, having a variable name corresponding to each variable element in the template or and each variable element, if any, contained within any variable sub-tree mapped into the template.

[0127] A project file can also include a job list 136, which can include one or more jobs, each of which specifies how one or more documents are to be produced by using the content-mapping rule set of the project. Each job specifies the template to be used with the project file's content-mapping rule set to produce the document set, the set of profile records that are to be used to supply data to the content-mapping rule set for the production of each document in the set, and the output format in which the documents are to be produced.

[0128] The content-mapping rules each map a value into a variable element having the same variable name based on information of a profile record. These profile records are normally selected from a profile database 147 shown in FIG. 2. In this figure this database is shown as a single table 148 comprised of a plurality of profile records 149, each including a plurality of fields 150. In other embodiments other types of databases, such as relational databases could be used.

[0129] As is explained below in more detail, some content-mapping rules map the value of a single field in a profile database into a corresponding variable element in a template, but other content-mapping rules are more complicated and can use one or more fields in a profile database to select a content file for inclusion into a given variable element of a template. Such content can include text files 138, which are unformatted text; formatted text files 140, which can include formatted texts by no paragraph boundaries; formatted paragraph files 142, which can include formatted text including paragraph boundaries; image files 144, which can be virtually any type of image file, (in the preferred embodiment they can be TIFF, GIF, JPEG, and encapsulated postscript (EPS) images; and area template files 146, which can contain a sub-tree of template elements including text and/or shape elements.

[0130] In the embodiment of the invention shown in FIG. 2, content-mapping rules can also use a digital asset management system 151 to select variable values. A digital asset management system is a database designed to manage digital content files. The digital asset management system includes a database 141, which includes a plurality of records 143, each of which includes a pointer 147 to a content file, which could be a files path name or network address, and one or more metadata fields 145 associated with each such file pointer. As is explained in more detail below, a content-mapping rule can associate a variable with a query to a digital asset management system that uses a selection of values for one or more metadata tags 145 to select a content file as the value for such a variable. Such content-mapping rules can cause the metadata tag values used in such a query to be a function of one or more fields in the profile record for which a given document is being produced.

[0131] Each template file 130 also has associated with it a TSL. or Template Style Language, file 131 shown in FIG. 2. An example of a part of a TSL file used in the layout of the template illustrated in FIG. 3 is shown in FIG. 5. As shown in FIG. 5, each TSL file is composed of a plurality of model definitions 133, which in FIG. 5 are labeled 133A or 133B. The models 133A are models of shape element types, and the models 133B are models of text element types. Both types of models are written in the same language, have the same format, and can be included in the same file. Shape models define attributes of shape elements and text models define attributes of text elements. Each model is based on the definition of a parent model that is referenced after the colons on the first line of the model's definition. Each model inherits all the attributes of its parent's model, except those which are explicitly overridden by a different value in its own model definition than is contained in the model definition of its parent or other ancestor from which it inherits attribute values. For example, in FIG. 5 the model PF_Area_Template_Base inherits its attributes from the model PF_Box_Base, and PF_Box_Base inherits its attributes from a fundamental, or root level, model called_box. In the preferred embodiment, root level models are not defined in a TSL file, their definition is part of the layout software that is used by the designer and producer programs. Similarly the example of FIG. 5 shows that the model ToyName inherits its attribute values from the model PF_Paragraph_Base, and the model PF_Para_Base inherits its attributes from the predefined root model_para.

[0132] FIG. 6 is a screen shot of a GUI window 180 generated by the producer program 126 shown in FIG. 2.

[0133] This window normally includes a project window 182, which by operation of the selection box 184 or section of one of the icons 186 can be caused to display a list of a selected type of elements important to a given document production project. In FIG. 4, the project window displays the project's variable list, which corresponds to the project's set of content-mapping rules 134 shown in FIG. 2. This window can also be used to show the list of jobs associated with the projects, which is labeled 136 in FIG. 2.

[0134] If a user selects a given variable name 287 in the variable list, such as the variable bigpic 287A shown highlighted in FIG. 6, a Variable Editor dialog box 188 will appear showing the definition of the content-mapping rule associated with that variable name. Within the producer program, a user can also choose to display a job preview window 153, which enables a user to see the values of the records from a profile database 147 shown in FIG. 2, which have been selected for use with a given job, and enables a user to click on a given record within that set and to see a layout of the template associated with the job in a document window 192. The mapping of different variables in to a given template that results from selecting different profile records in a given job can cause substantial changes in the appearance of a template. This is particularly true since entire template sub-trees can be mapped into a template by the use of variable area template elements.

[0135] FIG. 7 illustrates a portion of an area template file, of the type labeled 146 in FIG. 2. It shows that such a file is composed of an XML tree-shaped data structure similar in structure to a part, or sub-tree, of a template file. The contents of such files can have their contents dynamically mapped into an area template container that is a variable element. FIG. 8 is a picture of the designer program window shown in FIG. 3 after the contents of the area template file shown partially in FIG. 7 has been mapped into the variable area template box element 166 having the variable name <p1Area> shown in the structure view in FIGS. 3 and 8. As a result of such a mapping, the default value of the <p1Area> variable area template element, that part indented under that area template element in FIG. 3, is replaced by the elements of the area template shown in FIG. 7. This results both in a change in the structure view 154 and the document window 155 for the template.

[0136] FIGS. 59 through 103 provide a pseudo code description to explain the operations of the invention shown in FIG. 1. Many aspect of this pseudo code have been highly simplified to make it easier to understand. It's purpose is not to communicate the complex details of the system, but rather to convey the more important essentials of how it works.

[0137] FIG. 59 is a highly simplified description of the response that the designer program 124, shown in FIG. 2, makes in response to user inputs. In FIG. 59 the structure for making these responses is represented as a control loop.

[0138] As shown in step 1002 of FIG. 59, if a user selects a command to create a new file, that step calls the fileNew sub-routine 1042 shown in FIG. 60.

[0139] As is shown in FIG. 60, the fileNew sub-routine displays a File New dialog box in step 1044 that allows a user to pick attributes for, and select to create, a new template. If the user selects to create a new template, step 1046 causes steps 1048 through 1054 to be performed. Step 1048 creates a new tree data structure comprised of a document root node, corresponding to the document element represented by the XML start and end tags 174 and 174A, respectively, at the start and end of FIG. 4. Then it creates one empty page node under the document node, such as the page node represented by the tags 176 and 176A in FIG. 4. Then step 1050 creates a default TSL style sheet similar to the style sheet shown in FIG. 5 containing all of the default styles used by the designer program These default styles include all of the styles that start with the characters “PF” shown in FIG. 5. These are the standard text and shape models that all of the designer program's templates start out with. Once this is done step 1052 displays the layout of this simple template in the designer program's document window 155 in FIG. 3, and then step 1054 displays the templates simple tree-shaped data structure in the designer window's structure view 1054.

[0140] Returning to the control loop of the designer program shown in FIG. 59, if the user selects to save a file, by selecting the File>Save command in the menu structure of the user interface window 152 shown in FIG. 3, a step 1004 calls the fileSave sub-routine 1056 shown in FIG. 61.

[0141] As shown in FIG. 61, the fileSave routine starts by displaying a File Save dialog box in step 1058, which allows the user to edit the name of, select a file directory for, and select to save the current template displayed in the designer GUI window 152 shown in FIG. 3. If the user actually selects to save the current template in this dialog box, step 1060 causes steps 1062 through 1066 to be performed.

[0142] Step 1062 translates the current template's tree-shaped data structure from the form in which it is internally represented in the designer program to a corresponding XML representation, of the type shown in FIG. 4. Once this XML representation has been created, step 1064 saves that representation in a template file 130 of the type shown in FIG. 2 with the given name selected in the Save File dialog box followed by a .xdt file extension, which stands for “XML Document Template.” This file is saved in the given directory selected in the File Save dialog box. Next, step 1066 saves the current template's corresponding style sheet in the same directory as a file having the same name followed by a .tsl file extension.

[0143] Returning to the designer control loop shown in FIG. 59, if the user selects a File>Open command, using the menus of the designer program, step 1006 calls the fileOpen routine 1068 shown in FIG. 62.

[0144] As shown in FIG. 62, step 1070 of this routine displays a File Open dialog box that allows a user to select a directory, and select to see and open any .xdt file (i.e., XML designer template file) stored in the currently selected directory. If the user selects to open a given xdt file, step 1072 causes steps 1074 through 1082 to be performed.

[0145] Step 1074 opens the selected template file. Step 1076 creates an internal representation of the tree-shaped data structure represented by the opened XML template file. Next, step 1078 opens the .tsl, or style sheet file, having the same name proceeding the file extension as the template file that was just opened. Then step 1080 creates a display in the document window of the template that has just been opened using the attributes contained in the TSL file to determine how each element defined by reference to such to a model contained in the .tsl file will be displayed. Then step 1082 displays the template's tree-shaped data structure in the structure view 154 of the designer window shown in FIG. 3.

[0146] Returning to the designer control loop of FIG. 59, steps 1008 through 1014 of that figure relate to the creation, positioning, and sizing of shape elements in a template.

[0147] The designer window 152 shown in FIG. 3 contains a toolbox 200 shown along the window's left hand edge that contains four shape tools, the text container shape tool 202, the image element tool 204, the area template tool element 206, and the graphic shape element tool 208. As shown in step 1008 of FIG. 59, if a user clicks on any of these shape tools 202 through 208, the createShapeElement sub-routine 1084, shown in FIG. 63, is called for the tool's corresponding shape type.

[0148] As shown in FIG. 63, when the createShapeElement sub-routine is called, step 1086 changes the mouse cursor to an add-shape-element cursor corresponding to the element type of the respective tool 202 through 208 for which the routine has been called. This cursor has the same appearance as the icon for the selected tool 202 through 208, with the addition of a small plus sign to one side when the cursor is over a location in which such an element can be created in the template.

[0149] If the user starts dragging on the mouse when it has an add-shape-element cursor, steps 1088 and 1090 will plant the first corner of a bounding rectangle for a shape element of the current element type on the designer program's document window at the location in the layout of the template at which the drag is first started. Then steps 1092 and 1094 will respond to further motion of the mouse while the drag is continued by interactively moving a diagonally opposite corner of the bounding rectangle for the element type, changing the height and width of the shape during such motion. When the user ends the drag, the bounding rectangle is left having the opposite corner located and their respective positions at the time the drag stopped.

[0150] At this point step 1096 changes the mouse cursor to a selection cursor, and step 1098 creates a shape element of the current element type (i.e., a text container, an image element, an area template, or a graphic shape element) having the size and position attributes defined by the first and diagonally opposite corners of the bounding box defined at the end of the mouse drag. Then step 1100 places an element of the appropriate element type in the template's tree data structure. Step 1102 calls the selectShape routine for the element, which causes the newly created shape element to be currently selected, and step 1104 displays the element in the document window at its given location, laid out according to its current attributes. Then step 1106 updates designer windows structure window to show the inclusion of the newly created shape.

[0151] As is shown in FIG. 64, the selectShape routine called by FIG. 63's step 1102 of the createShapeElement, has a step 1110, which causes the shape for which the routine has been called to be selected, a step 1112, which highlights the outline of the shape in the document window, a step 1113, Which highlights the shapes element in the structure view, and a step 1114, which makes visible drag boxes on the shapes bounding rectangle that are located at each of the bounding rectangles four corners, and in the middle of each of its four sides. These drag boxes enable the user to resize the selected shape by dragging on them.

[0152] Returning to the designer control loop of FIG. 59, if a user clicks on a shape or drags a selection box around it, step 1010 calls the select shape routine 1108, just described, for the shape.

[0153] If a user drags on one of the drag boxes of a selected shape, step 1012 of FIG. 59 calls the resizeShape routine 1116 shown in FIG. 65.

[0154] As shown in FIG. 65, while such a drag continues, steps 1118 and 1120 will interactively move the one or more sides of the shape's bounding rectangle on which the drag box that is being dragged is located. It will cause each such side to move with that component of the mouse's movement which is perpendicular to the side on which the drag box is located as long as the drag continues. As soon as the drag ceases, step 1122 updates the size attribute of the shape element that had been resized by the drag to correspond to those of its bounding rectangle at the time the drag ended. Then step 1124 updates the shape's display in the document window, which requires that it and its children be re-aid out so as to interactively show the user the effect of the change in size upon the appearance of the document whose template is being edited.

[0155] Returning to the control loop of FIG. 59, if a user drags on a selected shape's outline within the document window, a step 1014 moves the shape with the motion of the mouse as long as the drag continues, and once the drag terminates, it updates the shapes position attributes and makes corresponding change to the document view.

[0156] If a user selects the Elements>Properties in the designer program's menu while one or more shape elements are selected, or if the user double clicks on a shape, step 1016 calls a propertiesEditor routine 1126, shown in FIG. 66, for the selected one or more elements.

[0157] As shown in FIG. 66, this routine has a step 1128, which displays a Properties editor dialog box 210, shown in FIGS. 9 and 10. This dialog box has two tabs; a form tab 212 shown displayed in FIG. 9 and a flex tab 214 shown displayed in FIG. 10. Each such tab has two columns, a left column 213, which lists attributes of the selected one or more items and a second column 215 containing a user editable field listing the current value of the attribute listed on the same row for the current selection.

[0158] The flex tab lists the selected shape elements' flex attributes, that is, its attributes that relate to whether or not, and how, it changes size or shape in response to variable content and/or in response to variable amounts of available space when being laid out.

[0159] The form tabs displays an element's non-flex attributes. As shown in FIG. 9, an element's non-flex attributes include a width attribute 216 and a height attribute 217, which together define the size of a shape element. The non-flex attributes also include three position attributes, a left attribute 219, a top attribute 220, and an angle attribute 221. The left and top attributes define the xy position of the anchor point for the shape element (often its upper left hand corner) relative to a container shape in which the given shape is located. The angle attribute defines the angle of the shape relative to what would be the vertical axis of the container shape if the container shape itself had an angle attribute of zero degrees. Among other things, this allows horizontal and vertical group boxes, which are described in greater detail below, to be set at a angles which are other than horizontal or vertical, respectively.

[0160] The non-flex attributes further include three color and border attributes, including a fill color attribute 223, which defines whether or not the shape has a solid fill color and what that color is; a border color 224, which defines whether or not the shape has a visible border, and if so what its color is; and a border thickness attribute 225, which defines the thickness of the shape's border.

[0161] Each shape also has margin attributes including: a left margin attribute 227, a top margin attribute 228, a right margin attribute 229, and a bottom margin attribute 230. These define the minimum distance between the boundary of the shape and the allowed position for any included child shape or text elements whose positions are not fixed relative to their parent shape.

[0162] Each shape element has four bumper attributes: a left bumper attribute 232, a top bumper attribute 233, a right bumper attribute 234, and a bottom bumper attribute 235. These define an external margin around the shape element upon which other shape are often not allowed to overlap.

[0163] Finally, each shape element includes three special attributes, including the avoid me attribute 238, the runaround attribute 239, a vertical alignment attribute 240, and a horizontal alignment attribute 241.

[0164] The runaround attribute will cause text in text containers to run around a shape element that has a yes value for the avoid me attribute. This is illustrated in FIG. 16, in which the text 218 runs around the image shape element 215. A yes value for the runaround attribute for a text element or for a text container shape will cause that text or the text within that shape to run around, or avoid, the space occupied by a shape element having yes for the avoid me property, and that shape's external bumpers.

[0165] The vertical alignment properties can have values of top, center, bottom, or justified. The selected value determines the spacing of elements within a container shape that is a sequence box. Similarly the horizontal alignment attribute can have the corresponding values of left, center, right, or justified, and it determines the horizontal alignment of elements within a sequence box containing one or more sub-element shapes.

[0166] As shown in FIG. 10 the flex tab of the properties editor dialog box has a behavior attribute 242, a minimum attribute 243, and a maximum attribute 244 for the height of the selected shape.

[0167] As shown in FIGS. 11 and 12, the flex-height-behavior attribute can be set to one of five values: “none” 256, “maximize” 258, “minimize” 260, “proportional” 262, and “source size” 263. If the shape is not an image element only the “none,” “maximize,” and “minimize” values are available. If the image element is an image, only the “none,” “maximized,” “proportional,” and “source size” values are available.

[0168] If the flex-height behavior is “none” that means the shape has a fixed height, which will be the height defined by the value of the height attribute 217 on the form tab 212, shown in FIG. 9.

[0169] If the user selects that the shape has the “maximize” flex-height behavior, the layout process with try to “maximize” the height of the shape, that is, to have it take up all space available for it during the layout process, up to the height defined by the Flex Height Maximum attribute 244 shown in FIG. 10.

[0170] If the user selects the “minimize” value for the flex-height behavior, the shape's height will attempt to be as small as possible as is allowed by either the size of the shapes contents plus the shape's internal top and bottom margin attribute values 220 and 230 shown in FIG. 9, or the value of its Flex Height Minimum attribute 243 shown in FIG. 10, whichever is larger. A variable shape element with such a minimized dimension will tend to shrink around the content of variable values which are mapped into it. A non-variable value with a minimized dimension will tend to shrink around the size of variable sub-elements which are contained within it, or around non-variable sub-elements which a placed within it by a user.

[0171] If the user selects a “proportional” value 262, shown in FIG. 11, for the flex-height behavior for an image element, layout of the image element will automatically scale the image's height so as to maintain the aspect ratio of the image file is mapped into the image element given its width, whether that width be fixed, maximized or minimized.

[0172] If the user selects a “source size” value 263 for the flex-height behavior or an image element, layout of the image element will automatically cause the image element's height to equal the height of the image file mapped into the image element.

[0173] Returning to FIG. 10's illustration of the Flex tab of the Properties Editor, the Flex Height minimum attribute 243 specifies the smallest height allowed for the selected shape during layout, regardless of its contents. If the flex-height behavior 242 is “none,” then this minimum value should equal the value of the height attribute 217 shown in FIG. 9 for the shape. Similarly, the Flex Height maximum attribute 244 shown in FIG. 10 represents the largest height the shape can have during layout, and this value should equal the value of the height attribute 217 shown in FIG. 9 if the flex-height-behavior attribute 242 is “none”.

[0174] Each shape element can also have three flex width attributes, a behavior attribute 246, a minimum attribute 249, and a maximum attribute 248, as shown in FIG. 10. Each of these three Flex Width attributes correspond to the similarly named Flex Height attributes 242 through 244, discussed above, except that they relate to width rather than height.

[0175] FIGS. 13 and 14 provide one illustration of the difference between the maximize and minimize value for the flex-height-behavior attribute of the vertical 162B shown in those figures. In FIG. 13 the vertical group box 162B has a minimize height, causing the box to shrink in a vertical direction as far at its contents will allow, so as to push up as far as possible the horizontal group box 64C containing the text box 156B and the group 160B at the bottom of the vertical group box 162B, as can be seen in the document window of FIG. 13. FIG. 14 shows the same vertical box 162B, once it has been given a maximized height, which causes this vertical box to expand down as far as will be allowed by the horizontal group box 164B in which it is contained, allowing the horizontal group box 164C to be located just above the bottom of the horizontal group box 164B, as shown in the document window of FIG. 14.

[0176] FIG. 15 illustrates the effects of the flex height and flex width attribute values upon an image element into which one or more image files are mapped.

[0177] FIG. 15 illustrates eight different combinations of flex height and flex width attribute values for image elements 234 through 234G, each of which is represented as a box that has labeled on its top a character representing its flex-width behavior and on its right side a character representing its flex-height behavior. In this figure S stands for the “source size” flex behavior attribute value. F stands for the “none” flex attribute value, which is the fixed-size attribute value. M stands for a “maximized” flex attribute value. Finally, P stands for the “proportional” flex attribute value.

[0178] Associated with each image element 234 through 234G is a row of dotted boxes representing the space available for the layout of the image element. The dotted boxes 236 and 238 in a given row, respectively, are a small available space box and a larger available space box in which a first image file is laid out given the size and flex attribute's of the row's associated image element. The dotted boxes 240 and 242 in a given row, respectively, are a similarly sized small available space box and a larger available space box in which a second image file is laid out given the same size and flex attribute's of the row's associated image element.

[0179] The first row of FIG. 15 is associated with the image element 234. This image element has the “source size” flex attribute in both its height and width. As a result the image element maintains the size defined by the image file mapped into it, regardless of the amount of space available for its layout.

[0180] The image element 234A in the figure's second row has a “source size” flex attribute value in one dimension and a fixed (i.e., “none”) attribute value in the other. As shown in the second row of FIG. 15, this causes the laid-out image element to have one dimension with the size of the corresponding dimension in the image file mapped into the image element, and its other dimension to have the image element's fixed size defined by the height or width attribute, 216 or 217, in the form tab shown in FIG. 9, regardless of the amount of space available for the image element's layout.

[0181] The image element 234B shown in FIG. 15's third row has both fixed height and width, causing the image element be laid out with the same fixed width and height regardless the size available for such layout and regardless of the size of the image file mapped into the image element.

[0182] The image element 234C in the figure's fourth row has a maximized width and a proportional height. This cause the image element to be as wide as it can possibly be while both still fitting within the space available layout space and still maintaining the aspect ratio of the image file being mapped into it.

[0183] Image Element 234D in FIG. 15's fifth row has a maximized width but a fixed height. This causes the image element to be as wide it possibly can within the available layout space, and cause it to maintain the element's fixed height regardless of how much that distorts the aspect ratio of the image mapped into the element.

[0184] Image Element 234E in the figures sixth row has both a maximized height and width. This tends to cause the image element to occupy the entire space available for the image element in both the height and width direction.

[0185] Image Element 234E in the seventh row of FIG. 15 has a maximized height and a proportional width. This tends to cause the image element and the image mapped within it to be as high as it possibly can be within the available layout space while still being able to fit within that space when maintaining the aspect ratio of the image file being mapped into the image element.

[0186] Note that in the examples of FIG. 15, the images are exactly the same for the image element 234F, which has a maximized height and proportional width, as they are for the image element 234C, which has a maximized width and proportional height. This is not always the case, but it happens in the examples of FIG. 15 because, given the shape of the images 230 and 232 and given the shapes of the available spaces 236 through 242, width is the limiting dimension while expanding the image files 230 and 232 so as to maintain those image file's respective aspect ratios, whether attempting to maximize width or height. In case of images and available spaces having different shapes, this would often not be the case.

[0187] The image Element 234G in the bottom row of FIG. 15 has a fixed width and a maximized height. This tends to causes the image element's height to takes up all of the available height, while keeping the image elements width fixed.

[0188] The most commonly used combination of flex attributes for image elements are the one represented by image element 234, in which both the height and width are determined by the size of the image file; and by image elements 234C and 234F in which one dimension is maximized and the other is proportional. This is because these are the only combination of flex attribute values that tend to maintain an image's aspect ratio and thus prevent it from being distorted. For some images, however, particularly those including graphic decorations, such distortion often is not a problem and in such a case other combinations of flex characteristics may be desirable.

[0189] FIGS. 16 and 17 provide an example of the mapping of images having different width and height into an image element 234 (indicated with heavy dotted lines which have been added to the screen shot in those figures), which has the source size flex attribute for both its width and height. The image file 244A, mapped into the image element 234 in FIG. 16, is taller and slightly narrower than the image file 244B mapped into the image element in FIG. 17. The vertical box 162, shown in FIGS. 16 and 17, has minimized height and width attributes that causes it to shrink around the variable size of the image element within it. Both the text box 156 and the image element 234 have top bumpers on them, which cause the top of the text box 156 to be spaced from the bottom of the image element 234 and cause the top of the vertical box 162 to be spaced from the top of the image element 234, as the size of the image element and the vertical box 162 change in response to the variable size of the images placed within the image element 234.

[0190] FIG. 18 provides-an illustration of the anchor point dialog box 248, which pops up if a user clicks in the variable column element associated with the value of the anchor attribute 250 shown in FIG. 10. This dialog box enables a user to quickly select one of nine possible anchor positions that can be associated with the currently selected shape. The Anchor Point dialog box lets a user select an anchor point at each of the shape's four corners, or in the middle of each of the shape's four sides, or in the center of the shape. If the shape is non-rectangular, for example, if it is an oval text container or graphic shape, the nine selected points will be defined relative to the bounding rectangle that encloses such a shape. The selected anchor point defines that part of the selected shape that will have the fixed position will be defined by the values of the left position attribute 219 and the top position attribute 220 shown in FIG. 9.

[0191] Such left and top position attributes are only relevant to shapes contained within parent shapes, including page elements and non-horizontal, non-vertical group elements in which the contained shapes have a fixed location relative to the upper left-hand corner of their parent shapes. The choosing of an anchor point is relevant for shapes that are intended to flex, that is change in height or width.

[0192] FIGS. 19 through 30 illustrate the importance of selecting different anchor points for shapes that flex.

[0193] FIGS. 19 through 21 show a shape element 250, which has both flexible width and height, having an fixed anchor point 254 in its upper left-hand corner whose position is fixed relative to the parent shape 252 in which it is contained. As can be seen by comparing FIGS. 19, 20 and 21, as the shape 250 expands and contracts in response to variable content, the anchor point 254 remains fixed and only the shape's bottom and right side move in response to such expansion and contraction.

[0194] FIGS. 22 through 24 illustrate a shape, 250A, which has a fixed anchor point 254A located in its bottom right-hand corner, fixed relative to the containing shape 252A. In the example of these three figures, shape 250A is only flexible in a width direction although it can easily be understood that, were it flexible in both dimensions, FIGS. 22, 23, and 24 would have an appearance that would be identical to, but diagonally opposite of, that of FIGS. 19, 20, and 21.

[0195] FIGS. 25 through 27 illustrate a shape, 250B, which has a fixed anchor point, 254B, located in the center of its top edge. This anchor point is fixed relative to the containing shape 252B. The shape 250B shown in these figures has both a flexible height and width. As can be seen by comparing FIGS. 25 through 27, as the height of the shape 250B changes in response to variable content, the top edge of the shape remains fixed and the bottom edge moves. If the width of the shape 250B changes in response to variable content, the increase or decrease in width is centered about the fixed anchor point, causing the shape's left and right edges to move equally, but in opposite directions, in response to such expansion or contraction.

[0196] FIGS. 28 through 30 illustrate a shape 250C, which has a fixed anchor point located in its center, and which has both flexible height and width. As can be seen from these figures, expansion and contraction of the shape 250C in the height or width dimension is centered around the fixed anchor 254C, and any changes in height caused equal but opposite movement in both the top and bottom edges of the shape, and any changes in the shape's width cause equal but opposite movement in the left and right edges of the shape.

[0197] As can be seen from looking at FIGS. 19 through 30, the ability to allow shapes to have selective anchor points about which flex occurs, enables a designer of templates to accommodate flex in a variety of aesthetically pleasing ways.

[0198] Returning to the propertiesEditor routine of FIG. 66, our discussion of that routine left off with a discussion of how step 1128 displays the Properties Editor dialog box, which has the two tabs shown in FIGS. 9 and 10, and how that dialog box allows a user to edit values of attributes listed in either of those two tabs.

[0199] Continuing now to step 1130, if a user selects to display another of the two tab by clicking on it, steps 1130 and 1132 will display the other tab. If a user clicks on an attribute value, steps 1134 and 1136 allow the user to edit that value if the value is changeable for the currently selected shape for which the dialog box has been brought up.

[0200] If the selected shape is an image element, the form tab of the Properties Editor dialog box will include a source attribute value, which is not shown in FIG. 9. If the user clicks on this value field of this attribute, the program calls an insertImageFile routine, 1160, shown in FIG. 67.

[0201] As shown in FIG. 67, step 1162 of this routine displays the Insert Image File dialog box, which allows a user to select a directory and to see and select open any image file stored in the selected directory. If the user selects to open a given image file using the dialog box, step 1164 causes steps 1166 and 1168 to be performed. Step 1166 adds the image file's name as the value of the source attribute of the selected image element, and step 1168 will update the layout of the document window to show the selected file's image.

[0202] Returning to the propertiesEditor routine of FIG. 66, if a user clicks on the flex-height or flex-width behavior value field of a properties editor for an image element, steps 1142 and 1144 convert the field to a drop-down box offering the user a choice of a subset of the “none,” “maximize,” “minimize,” “proportional,” or “source size” values for such flex behavior attribute values, as illustrated in FIGS. 11 and 12.

[0203] Once the user has changed an attribute value in step 1136 of FIG. 66, if the current selection for which the Properties editor's dialog box has been evoked, if one or more shapes in the current template, step 1148 will cause steps 1150 to change the corresponding attribute value in the template's data structure, and step 1152 will update the layout in the document window to show the selected shapes with the selected attribute values.

[0204] If, on the other hand, the Properties Editor's dialog box has been evoked for a given style in the Style Editor, as will be described below, step 1154 will cause steps 1156 and 1158 to be performed. Step 1156 changes the TSL style sheet for the current template to cause any attribute whose value has been changed in the Properties Editor to have a corresponding change made to its value in the given style's model within the TSL style sheet. Then step 1158 will update the layout of the document window to show the new attributes of any shapes in the template that have the edited style or any styles that inherit the edited attribute value from the edited style.

[0205] Returning to the designer control loop of FIG. 59, steps 1018 and 1020 relate to the adding or removal of elements from an area template. As indicated above with regard to step 1008, the user can create shapes by clicking on the toolbox icon for a shape shown in the tool bar 200 illustrated in FIG. 3. This includes the area template icon 206, which allows the user to create area templates. As described above, an area template is a sub-tree of a template. The user can create an area template by creating an area template shape and then re-sizing it with drag boxes to include desired elements or groups of elements in the template's data structure. If the user resizes an area template shape to include more elements, or moves old shape elements into or creates new shapes in, the area template shape, step 1018 of FIG. 59 will cause the addElementToAreaTemplate sub-routine 1170 of FIG. 68 to be called.

[0206] The addElementToAreaTemplate routine is shown in FIG. 68. As can be seen from that figure, this sub-routine has a step 1172, which selects each element that is newly totally inside the containing area template shape. Then step 1174 performs a dialog, prompting the user to deselect any elements not wanted in the area template and to click a button indicating when and if the remaining selected elements are to be added to the area template. If the user clicks to have the remaining selected elements added to the area template, step 1176 causes steps 1178 through 1184 to be performed.

[0207] Step 1178 places the selected elements into the area template's elements branch of the template tree data structure. Step 1180 de-selects all selected elements. Step 1182 updates the display in the document window, and step 1184 updates the tree's structure view so as to show the change to the tree-shaped data structure caused by step 1178.

[0208] Returning to the designer control loop of FIG. 59, if the re-sizing of an area template shape, or the moving of any shapes formerly within the area template shape, causes any shapes formerly totally within the area template shape to no longer be so. Step 1020 calls the removeElementFromAreaTemplate's sub-routine 1186 shown in FIG. 69.

[0209] As shown in FIG. 69, this sub-routine has a step 1188, which causes each element that is newly no longer within the area template shape within the layout shown in the document window to be selected. Then a step 1190 performs a dialog prompting the user to de-select any of the resulting selected shapes that he does not want to be removed from the area template, and then step 1192 responds to the user's clicking within the dialog box to indicate that he wants the remaining selected items to be removed from the area template by causing steps 1194 to 1200 to be performed.

[0210] Step 1194 removes each of the selected elements out from under the area template's branch of the template data tree structure. Step 1196 de-selects all the selected elements. Step 1198 updates the document window if any such updating is needed, and step 1200 updates the template structure view to reflect the removal of elements from the area template's branch of the template's tree.

[0211] The addElementToAreaTemplate and removeElementFromAreaTemplate routines of FIGS. 68 and 69 prompt the user to decide exactly which elements he wants to add to or remove from an area template, because the location of elements within a document's layout, as displayed in the document window, does not necessarily correspond to its order within the template's tree-shaped data structure displayed in the structure view. This is because, within pages and non-horizontal or vertical group boxes, elements can be positioned at a fixed distance relative to the upper left-hand corner of such shapes by the value of the left and top position attributes, 219 and 220, shown in FIG. 9. This allows the position of those elements to be independent of their order within their container shape in the tree-shaped data structure. In fact, this even allows shapes to partially or totally overlap, which is sometimes desired for layout purposes. For this reason it is important that the user interface of the addElementToAreaTemplate and removeElementFromAreaTemplate routines allows a user to select exactly which elements located within a given area corresponding to an area template shape in the document window layout of a template are to be included in that area template.

[0212] Returning to the designer control loop of FIG. 59, the designer program allows the user to create group boxes, vertical group boxes, and horizontal group boxes by selecting corresponding menu choices under the Element menu of the designer window shown in FIG. 3.

[0213] If the user selects Element>Group in the menu, step 1022 calls the createGroup-Box routine 1202 shown in FIG. 70.

[0214] As shown in FIG. 70, step 1204 of this routine adds a group box element, such as the element 160 shown in the structure view of FIG. 3, to the current template's tree-shaped data structure and causes any elements that were selected at the time that the group box was created to be placed under the group box in that tree. Then step 1206 updates the layout of the document window to show a selected group box around the selected elements, if any, and then step 1207 updates the tree's structure view to show the changes that have been made in step 1204.

[0215] Returning to the control loop of FIG. 59, if the user selects Element>Vertical Group in the designer program's menu, step 1024 calls the createVBox routine 1208 shown in FIG. 71.

[0216] As shown in FIG. 71, this routine includes a step 1210, which adds a v-box, or vertical group element, to the template tree's data structure and causes any elements in the template that were selected at the time the vertical box was created, to be placed under the vertical box's element in the template's tree-shaped data structure. Then step 1212 updates the layout in the document window to show the newly created v-box around the previously selected elements, if any, with the elements being automatically distributed along the vertical box's vertical sequencing axis. The v-box's child elements are aligned by using the system's default values for horizontal and vertical alignment, which are left horizontal alignment and top vertical alignment. Finally, step 1214 updates the template's tree structure view.

[0217] Returning to the designer control loop of FIG. 59, if the user selects Element>Horizontal Group in the designer program's menu, step 1026 calls the createHBox sub-routine, 1216, shown in FIG. 72.

[0218] As shown in FIG. 72, this sub-routine has a step 1218, which creates an h-box, or horizontal group element, and adds it to the template's data tree with any elements that were selected at the time of this creation placed under the newly created h-box within the current template's tree data structure. Then step 1219 updates the layout in the document window to show the newly created h-box enclosing the previously selected elements, if any, with the enclosed elements positioned along the horizontal box's horizontal sequencing axis, using the default horizontal vertical alignment value. Then step 1220 updates the designer program's structure view window to reflect the changes to the template that had been made in step 1218.

[0219] Returning to the control loop of FIG. 59, steps 1029 through 1033 shown in that figure allow the user to edit text.

[0220] If a user types text at a cursor position within a text container, step 1028 enters the text at the cursor position. Such text is considered floating, since it occurs within one or more successive horizontally displaced lines within the portion of the text container shape not occupied by the text container's internal margins.

[0221] If the user selects Text>Insert Object>Shape in the menu structure of the designer program, step 1029 calls the insertShapeInText routine 1221, shown in FIG. 73.

[0222] As shown in FIG. 73, this sub-routine contains a step 1222, which places a shape rectangle in the location in the template tree data structure corresponding to the text cursor's location in the document window, splitting any text element in which the cursor might be placed into two text elements on either side of it. Step 1223 then updates the display of the layout of the template in the document window to show a selected rectangle at the location on the screen of the text cursor, as a selected shape. And step 1224 then updates the tree structure's view. Although it is not shown in the pseudo-code, once this rectangle has been created the user has the ability to change the rectangle into either a text container, an image container, an area template container, or a graphic shape.

[0223] Returning to the designer control loop of FIG. 59, if the user selects text by dragging a text cursor over it or by dragging a selection box around it, step 1030 calls the selectText routine for the text that the user has so selected.

[0224] As shown in FIG. 74, the Select Text sub-routine 1225 has a step 1226, which causes the text for which the routine has been called to be selected. Then step 1227 displays the selected text in reverse video in the document window.

[0225] Returning to the control loop of FIG. 59, if the user selects Text>Character in the Designer Window's menu, step 1031 calls the characterProperties sub-routine 1228, shown in FIG. 75, for the selected text.

[0226] As shown in FIG. 75 this sub-routine has a step 1230, which displays the Character Properties dialog box 260, shown in FIG. 31, for the selected text. This dialog box shows the values of the selected text attributes, and allows a user to change the values of any such attributes and to select to apply any such changed attribute values to the selected text. If the user selects to apply the changed values, if any, made in the Character Properties dialog box to the selected text step 1232 in FIG. 75 causes steps 1234 and 1236 to be performed. Step 1234 changes the corresponding attribute value of the selected text in the template data structure, and step 1236 updates the layout of the document window to show the text with the newly changed attribute values.

[0227] Going back to FIG. 59, if the user selects Text>Paragraph in the designer program's menu structure, step 1032 calls the paragraphProperties sub-routine 1238, shown in FIG. 76, for the selected text.

[0228] As shown in FIG. 76, this sub-routine includes a step 1240, which tests to see whether the selection with which the dialog box has been called is selected text or a selected style. If it's selected text, step 1240 makes all of the paragraphs in which any of the selected text occurs be selected. Then step 1242 displays the Paragraph Properties dialog box, 262, shown in FIG. 32. This dialog box shows the text attribute values for the selection, allows a user to change the values for individual attributes displayed, and allows the user to select to apply any such changed attribute values to the current selection.

[0229] As shown in FIG. 32, the Paragraph Properties dialog box has three tabs: a character default tab 264; a format tab 266; and a tab/indents tab 268. FIG. 32 shows the entire dialog box with the character defaults tab 264 shown. FIG. 33 shows the format tab of the dialog box. FIG. 34 shows the tab/indents tab of the dialog box. As can be seen from these figures, each of these dialog boxes allows the user to alter various text-related attributes for the currently selected paragraphs or style.

[0230] One attribute, which is discussed in more detail below, is that defined in Language selection box 270, shown in FIG. 33, which allows the user to select a value for the language_id attribute for the current selection. As is explained below, this attribute is used to select a hyphenation rule set, for use in laying out the text.

[0231] As shown in FIG. 76, if the user selects to apply any attribute values changed in the Paragraph Properties dialog box by clicking on the OK button, 272 shown in FIG. 32, step 1244 of FIG. 76 causes steps 1246 through 1256 to be performed.

[0232] Step 1246 tests to see if the current selection-for which the Paragraph Properties sub-routine has been called is a style, defined in the current template's TSL file of the type shown above with regard to FIG. 5. If so, it causes steps 1248 and 1250 to be performed. Step 1248 changes the attributes in the current template's TSL description of the currently selected style's corresponding model, to reflect any of the changes that have been made in the Paragraph Properties dialog box. Then step 1250 updates the layout of the template in the document window to show the new attribute values for any text in the template that has the currently selected style or that inherits any of the changed attributes from the currently selected style.

[0233] If, on the other hand, the current selection is text, and not a style, step 1252 will cause steps 1254 and 1256 to be performed. Step 1254 changes the attributes of the currently selected paragraphs in which the selected text occurs to reflect the changes that have been made to the values contained within the Paragraph Properties dialog box. Then step 1256 updates the layout in the document window to show the new attribute values of the selected text.

[0234] Returning to the designer control loop of FIG. 59, if the user selects Text>Style in the designer program's menu structure, step 1033 calls the textStyle sub-routine 1260, shown in FIG. 77.

[0235] As shown in FIG. 77, this sub-routine has a step 1262, which displays a Define Styles dialog box 274, shown in FIG. 35. This dialog box includes a style window 276, which provides a tree diagram of the hierarchy of text styles currently defined in the current template's corresponding TSL file. The user is enabled to click on one of the names of this tree diagram to make it the currently selected style. The dialog box 274 also includes a sample window 278, which includes a sample of text having the text attributes defined by the currently selected style. It also includes a description window 280, which lists the attributes of the currently selected style and the name of the style upon which it is based.

[0236] If the user selects the New button 282 in this dialog box, step 1264 in the text-Style sub-routine of FIG. 77 causes steps 266 through 270 to be performed. Step 266 displays a dialog box that allows the user to enter a name for a new style to be created and to select the name of the parent style from which it is to inherit default text attributes. If the user enters such a name for a new style with a value selected for a parent style and clicks OK in this dialog box, step 1268 causes step 1270 to be performed, which calls the paragraphProperties routine, described above with regard to FIG. 76, for the new style.

[0237] If the user selects the Edit button 284 shown in FIG. 35, steps 1274 through 1278 of FIG. 77 are performed. Step 1274 shows a dialog box that lets a user select a style by name. This dialog box comes up with the currently selected style, if any, within the Style Window 1276 as the selected style. If the user selects a Properties option contained within the dialog box put up by step 1274 for a named style, steps 1276 and 1278 call the paragraphProperties routine of FIG. 76 for the named style, allowing the user to select and edit attributes for that style.

[0238] It can be seen that the textStyle sub-routine allows a user to create and define new styles, as well as to edit previously existing ones. In both cases, the paragraph-Properties sub-routine, described above with regard to FIG. 76, is used. In the case of an edit of a previously existing style, this causes any text within a template that is nested under a tag bearing that style's name, or the name of any style that inherits attributes from that style, to have its display in the document window updated by step 1250 shown in FIG. 76.

[0239] Returning to the control loop of FIG. 59, if a user selects Element>Style in the menu structure of the designer program, step 1034 calls the shapeStyle sub-routine 1286 shown in FIG. 78.

[0240] As shown in FIG. 78, this sub-routine is substantially-identical to the textStyle sub-routine described above with regard to FIG. 77, except for the portions of its text that are underlined in FIG. 78. These differences relate to the fact that it displays the Properties editor dialog box for the selected style rather than the Paragraph Properties dialog box, and that it affects TSL definition of styles for shapes rather than styles for text.

[0241] Going back to FIG. 59, if the user selects Project>Show Variable List in the designer program's menu structure, step 1035 calls the variableList sub-routine 1312 shown in FIG. 79.

[0242] As shown in FIG. 79, step 1314 of this sub-routine causes a Variable List window 286, shown in FIG. 36, to be displayed. This Variable List contains a list of variables, which are content-mapping rules, each of which has as its name a variable name 287, which can correspond to a variable name 178, of the type listed in the variable column 177 in FIG. 3, of a template variable element. In the variable list the variable names 287 occur in a variable name column 292 shown in FIG. 36. Immediately to the left of each such variable name, in a rule-type column 290, is an icon 294, which defines the type of content-mapping rule that is associated with the variable name 287. Immediately to the left of these icons are content-type icons 296, contained in a content-type column 288. Each such content-type icon graphically represents the type of the variable. For example, the Icons 296A, which look like a capital letter A, indicate that their associated variable has a content type that is unformatted text. The Icons 296B, which look like two paragraph signs, indicate that their associated variables have a content type for formatted paragraph text, and the Icons 296C indicate that their associated variables are associated with content-mapping rules for images. Other content types supported by the current embodiment of the invention include non-paragraph formatted text and area templates.

[0243] As shown in FIG. 79, once step 1314 has displayed a variable list, if a user drags on one of the variables contained within that list, step 1316 causes steps 1318 through, 1322 to be performed. Step 1318 changes the mouse cursor to an add-type icon that has an appearance corresponding to FIG. 36's content-type icon 296 associated with the dragged variable. As long as the mouse is down during the drag, steps 1320 and 1322 in FIG. 79 cause the add-type Icon to be dragged on the screen with the motion of the mouse, and they cause the icon to have a plus sign if it is over a location in the document window at which it is legal to drop a variable of the-selected content type.

[0244] If the mouse button is released at a time when the icon has such a plus sign, step 1324 causes steps 1326 through step 1344 to be performed. Step 1326 tests to see if the variable has not been dropped inside a container that can accept its content type. If it has not been dropped inside such a container, step 1328 creates a corresponding container element that can hold the variable's associated content type in the template tree data structure of the current template. Thus, for example, if the current content type of the Add-Type icon at the time of the drop was text, a text container would be created to hold it. If it is an image, then an image element would be created to hold it; if it is an area template, an area template holder would be created to contain it, and so forth.

[0245] If the variable type that has been dropped in step 1324 is a text element, step 1330 causes steps 1332 through 1338 to be performed. Step 1332 tests to see if the variable has been dropped in the middle of an existing text element and if so it causes step 1334 to split the existing text element into which it has been dropped into two parts, each of which holds the text on one side of the place where the text variable was dropped. Step 1336 creates a new text element corresponding to the variable type that has been dropped and places it in the proper place in the template's tree data structure. Then step 1338 places a data_tag attribute having a value equal to the variable's name in the new text element that has been created, converting it into a variable text element. An example of a text element containing such a data_tag is shown in the character element 170 shown in FIG. 4 and is labeled with the numeral 180.

[0246] If the variable type being dropped by the release of the mouse button detected in step 1324 of FIG. 79 is other than a text element, step 1340 places a data_tag attribute having a value equal to the variable's name in the corresponding container element in the template tree data structure, making that container into a variable element. Then step 1342 updates the layout in the document window to reflect the insertion of any container elements that may have been created by steps 1326 and 1328, and step 1344 updates the structure view to reflect the insertion of the variable element, including the display of the variable name next to its associated variable element, and the splitting of any text element into which the variable has been inserted, which may have been performed by step 1334.

[0247] Although other embodiments could operate differently, the embodiment in the invention shown in FIG. 1 does not display variable elements in the layout window. If the user wants to see the location of a variable, he either enters a command to cause all variable elements to be highlighted, or to select a variable element in the structure view. Of course, variable elements can be given static attribute values and static content values, as indicated in FIG. 4, and such static values for variable elements will be displayed in the document window unless the user maps variable values into a template, in which case the variable element will be displayed with such variable values.

[0248] As is shown in FIG. 79, if a user selects the Remove button 298 shown in FIG. 36, when a variable element is selected, step 1348 tests to see if the selected element is a text variable element and if so it causes step 1350 to remove the text variable element from the template tree's data structure. If the selected element is not a text variable element, step 1352 causes step 1354 to remove the data_tag and the variable name of the selected variable element from the selected element in the template tree data structure. Then step 1356 updates the document window display to show any layout changes that have been caused by the removal, if any, and step 1358 updates the structure view to reflect the removal of the variable name from the variable column 177, of the type shown in FIG. 3, of the structure view.

[0249] A variable list corresponds to a rule set 134 of the type illustrated schematically in FIG. 2. Such rule sets are associated with project files and a user has to open a project file while in the designer to have access to that project's variable list.

[0250] Returning to the designer control loop of FIG. 59, if a user selects File>Export>Selection in the designer program's menu structure, step 1036 calls the export routine 1360 shown in FIG. 80 for the current selection.

[0251] As shown in FIG. 80, the export sub-routine contains a step 1362, which displays a dialog box that allows the user to select a directory, to select a file type, to see all files of the selected file type in the selected directory, to enter a new file name of edit a selected file name, and to select to save the selection under the new or selected file name. If the user makes a selection to save the currently selected content under a file name having the extension corresponding to the content type of the current selection, step 1364 causes step 1366 to save the selection in a file of the selected type in the selected directory under the selected name. In the embodiment of the invention shown in FIG. 2, unformatted text is saved as .txt files, formatted non-paragraph text is saved as files containing an .xft (for XML formatted text), formatted paragraph text is saved as .xfp (for XML formatted paragraphs), area templates are saved as .xat files (for XML area templates), and images are saved as either TIFF, GIFF, JPEG, or encapsulated postscript files.

[0252] As shown in the control loop of FIG. 59, if the user selects File>Insert>contentType, in the menu structure of the designer program, where contentType represents either text, formatted text, formatted paragraphs, image, or area template, then step 1037 calls the import sub-routine 1368 shown in FIG. 81 for the selected content type.

[0253] As shown in FIG. 81, this sub-routine starts with a step 1370, which displays a dialog box that allows the user to select a directory, to select a file type, to see all the files of the selected file type in the selected directory, to enter or pick a selected file name, and to select to open the file having the selected name. If the user selects to open a file of a selected name, step 1372 causes steps 1374 through 1392 to be performed. Step 1374 changes the mouse cursor to an add-type icon corresponding to the selected content type. Step 1376 and 1378 cause the add-type icon to move across the screen along with the motion of the mouse with the add-type icon having a plus sign if it is over a location in which a value of the selected content type can be dropped.

[0254] If the mouse button is released at a time when the icon has a plus sign, indicating it can be dropped at the location in which the mouse button is released, step 1379 causes steps 1380 through 1392 to be performed. If the mouse button has not been released in a container that can accept its type, step 1380 causes step 1381 to create a corresponding container element that can hold the type of content of the file that has been opened and places it in the appropriate place in the template's tree data structure. If the content file being opened is a text element, step 1382 causes steps 1383 through 1385 to be performed. Step 1383 tests to see if the content was dropped in the middle of an existing text element. If so, it causes step 1384 to split the existing text element into two portions representing the text on each side of the location at which the newly opened text content has been dropped. Step 1385 creates one or more text elements corresponding to the text content that has been opened and places it in the template tree data structure at the appropriate place.

[0255] If the imported content is an image file, steps 1386 and 1387 give the src attribute of the associated image element a value corresponding to the name of the selected image file. This is done because, in an image element, it is the src attribute which names the file containing the image data to be displayed in the image element.

[0256] If the content being imported is other than a text element or an image element, step 1388 causes the one or more elements of the imported file to be inserted as content, or children, in the sub-tree data structure under the container into which that content has been dropped.

[0257] After the operation of steps 1382, 1386, or 1388 has been performed, step 1390 updates the layout in the document window to show the inserted contents, and step 1392 updates the structure view in the designer window to reflect the inserted elements.

[0258] Returning to the control loop of FIG. 59, if the user selects Project>Select Project, step 1038 calls the selectProject sub-routine 1394 shown in FIG. 82.

[0259] As shown in FIG. 82, this sub-routine performs a step 1396, which displays a Select Project dialog box, which allows a user to select a directory, to see projects in the selected directory, to select one such project, and to select to have the selected project opened. If the user selects to open a project, step 1398 causes step 1400 to open the selected project, including making its variables available to the designer program as was discussed above with regard to the variable list shown in FIG. 36 and as was described above with regard to FIG. 79. As shown in FIG. 2, each project file includes not only a variable list, or rule set, 134, but also a job list 136.

[0260] Returning to the designer control loop of FIG. 59, if the user selects Project>Show Records and then uses the resulting dialog box to select one of the jobs contained in the opened projects job list 136, shown in FIG. 2, step 1040 calls the jobPreview routine 1472 shown in FIG. 86.

[0261] As shown in FIG. 86 this sub-routine includes a step 1474, which displays a Job Preview record selector window 153 shown in FIGS. 3 and 6. As will be described below, each time the user selects a profile record, represented by a row in the table shown in the Job Preview record selector, the program in which the record selector is shown, in the case of FIG. 3 the designer program, will import variable values into all of the variable elements of the current template on the basis of the values contained in the selected profile record, and will cause the document window to display a layout of the current template with such variable contents having been mapped into it.

[0262] Turning now to FIG. 83, this figure provides a highly simplified top level description of the control loop of the producer program described above with regard to numeral 126 of FIG. 2 and the GUI window 180 of FIG. 6. As was discussed above, this is the program that is used to create, edit, and save project files 132, shown in FIG. 2, each of which contains a content-mapping rule set 134 and a list 136 of jobs, each of which specifies information necessary to produce a set of one or more variable documents.

[0263] If the user selects File>New Project, step 1404 in FIG. 83 causes step 1406 to display a new project dialog box that allows a user to select a name and a directory for a new project file and to create and open the named file.

[0264] If the user selects File>Open Project, step 1408 causes step 1410 to display an Open Project dialog box that allows the user to select a directory, display the project files in it, and select to open a displayed project file.

[0265] If the user selects File>Save Project, step 1412 causes step 1414 to display the Save Project dialog box, which allows the user to save the current project including its set of variables and their content-mapping rules and the project's job list under a selected name and a selected directory. This is how project files such as the project files 132 shown in FIG. 2 are formed.

[0266] If the user selects Data>Add Source, step 1416 in FIG. 83 causes step 1418 to display a dialog box that allows the user to select a profile database such as the profile database 147 shown in FIG. 2 to be used by the project.

[0267] If the user selects Edit>Preferences>Add Content Folders>Add, step 1420 causes step 1422 to display a series of dialog boxes that allows the user to select a MediaBank digital asset management system, such as the digital asset management system 151 shown in FIG. 2 for use by the system.

[0268] If the user selects Template>Add Template, step 1424 causes step 1426 to display the Add Template dialog box, which allows the user to select a directory, display the templates in it, and select to open a displayed template file, such as the template file 130 shown in FIG. 2.

[0269] If the user selects Variable>Add, step 1428 in FIG. 83 causes step 1430 to call the variableEditor sub-routine 1444 shown in FIG. 84 for an undefined variable for a new variable.

[0270] As shown in FIG. 84, the variableEditor sub-routine has a step 1446, which displays a Variable Editor dialog box 300 shown in FIG. 37. This dialog box includes a “Name” edit box 302, which allows the user to enter a name for a new variable being defined by the Variable Editor or to edit the name of a previously defined variable being edited by the Variable Editor 300.

[0271] The Variable Editor box also includes an “OK to publish without a value” check box 304. If checked, this will allow variable elements for which the content-mapping rule to be associated with the variable being defined by the dialog box 300 fails to map any content value to be suppressed. As is explained below in more detail, such suppression causes variable elements to take up no space in the layout of a template. If this value is not checked, a variable element into which no value is mapped will take up the space defined by the combination of its height and width attributes and its flex attributes.

[0272] The Variable Editor dialog box also includes “Kind” combo box 306, which allows the user to select the content type of the variable currently being defined or edited. It also includes a “Source” combo box 308, which allows the user to select a type of content-mapping rule to be associated with the variable name.

[0273] In the embodiment of the invention shown in FIG. 1, there are five types of content-mapping rules, each of which has a separate rule definition area 310 in the Variable Editor dialog box of FIGS. 37 through 41. These five rule types are the constant rule type whose definition area is shown in FIG. 37, the script rule type whose definition area is shown in the dialog box 300A of FIG. 38, the simple rule type whose definition area is shown in the dialog box 300B in FIG. 39, the profile record content-mapping rule type whose definition area is shown in dialog box 300C in FIG. 40, and the MediaBank query content-mapping rule type whose definition area is shown in dialog box 300D in FIG. 41.

[0274] As shown in FIG. 37, the definition area of a constant rule type contains a “Value” edit box 312, which allows a user to type in a constant text string that is to be used as the value of the named variable if the variable kind shown in the combo box 306 is plain text. If the variable's content type or kind is other than plain text, the string contained within the value edit box 312 should define the name and path of a file whose contents are to be mapped into the named variable.

[0275] FIG. 38 shows the definition area 310A associated with a script rule type. In this case, it includes a “Script File” combo box, which allows the user to select or enter the name of a script file that is to be used to generate and/or select content for the variable kind indicated in the selection box 306 for the variable named in the edit box 302. The selection box 316 defines the language of the script, so that a program using the variable definition to map data into a template will know what interpreter it is to use for the script.

[0276] FIG. 39 shows the definition area 310B associated with content-mapping rules of the simple rule type. This definition area includes a “For variable” selection box 318, which allows the user to specify the name of a field in the profile database that is to be used as the tested value by the if/then rules defined by the remainder of the definition area. The definition area then contains one or more if/then rules 319, each of which includes a selection box 320, which allows the user to select from among a plurality of string relationship operators, and a target value edit box 322, which allows the user to specify a target string. If the string in the profile field identified in the selection box 318 has the string relationship specified in the selection box 320 to the target string 322, then the string or the contents of the file identified in the “Map to” selection box 324 will be mapped into the variable name identified in the edit box 302. At the bottom of the definition area, an “Otherwise map to” selection box 332 defines a string or the name of a file whose contents are to be mapped into the dialog box's variable name if none of the conditions of the if/then rules 319 are met. The plus and minus buttons 334 and 336 shown in FIG. 39 at the lower left-hand corner of the definition area enable a user to add or remove if/then rules 319 from the definition area.

[0277] FIG. 40 shows the definition area 310C for a Variable Editor dialog box, which has the profile-record-field content-mapping rule type. This definition area includes a “Field” selection box 338, which allows the user to specify the name of a field in a profile data that is to supply the value for the dialog box's variable name.

[0278] FIG. 41 shows the definition area 310D, which is used to define a MediaBank query content-mapping rule. A MediaBank query is used to define a variable template for an SQL query of the type shown in FIG. 42. This variable query template will be instantiated, as shown in FIG. 43, on the basis of the values of fields in a profile data record, and then the instantiated SQL query 352 shown in FIG. 43 will be sent to the digital asset management system 151 shown in FIG. 2 to select a digital content file that will be mapped into the dialog box's variable name.

[0279] The definition area 310D shown in FIG. 41 includes a “MediaBank Table” selection box 340, which allows the user to select a particular table 141 contained within the digital asset management system 151, as shown in FIG. 2, to be used by the content-mapping rule. The major portion of the rest of the definition area in FIG. 41 is composed of one or more rows 342, each of which contains three selection boxes: a selection box 344, which contains a metadata tag name; a selection box 346, which selects a string relationship; and a selection box 348, which specifies either a constant target string, or the name of a field in a profile data record that will contain the target string. The SQL query that will be generated in response to a MediaBank query will seek a MediaBank content file that has associated metadata tag values that meet the conditions set forth in the rows 342.

[0280] The first row of selection boxes 342A normally defines the desired value for a metatag data field that defines the content type of the file to be selected by the query. For example, in the query defined by the dialog box in FIG. 41, a metadata tag called “elementType,” which defines the data type of a content file, is defined to have a “PICTURE” value, meaning that only a content file whose associated record in the MediaBank table has an elementType metadata tag with a value of “picture” is to be selected. The other rows 342 specify that the names of one or more other metadata fields in the MediaBank table are to have values with a specified string relation defined in column 346 to the value of a named field in the profile record used to select content for the production of a given document. The add and subtract buttons 334 and 336 at the bottom of the definition field 310D allow the user to add or subtract rows 342 to or from the query definition if desired.

[0281] In the examples of FIGS. 41 through 43, if a profile data record is provided that has a “brand” field with a value equal to “Whirlpool,” a “product” field having a value equal to “Dishwasher 45” and a “customer role” field having a value equal to “Dealer,” the SQL query template shown in FIG. 42 will be instantiated to form the complete SQL query shown in FIG. 43. Once instantiated this query can be sent to the MediaBank database to obtain back the name and path of the content file, if any, that meets the selection criteria defined by the query.

[0282] It should be noted that in other embodiments of the invention different types of content-mapping rules could be used, including, for example, neural networks, and that in the simple rules and MediaBank queries other types of logical rules could be used, including rules allowing logical OR, XOR, AND, and NAND operators.

[0283] Returning to the variableEditor routine of FIG. 84, if the user clicks the apply button 303 shown in a Variable Editor dialog box of the type shown in FIGS. 37 through 41, Step 1448 of FIG. 84 causes Steps 1450 through 1454 to be performed. Step 1450 incorporates any changes to the variable definition that have been made by the dialog box into a data structure that stores the variable and its content-mapping rule in the rule set 134 shown in FIG. 2. If the variable's content-mapping rule is a MediaBank query, steps 1452 and 1454 cause the MediaBank query defined in the definition section 310D of the Variable Editor dialog box in FIG. 41 to be generated as an SQL query template 350 shown in FIG. 42 corresponding to the rule defined in the dialog box's definition area. In this SQL query template, metadata field names corresponding to those occurring in column 344 of FIG. 41 are included and variable symbols are used to represent the profile record field names represented in column 348 of FIG. 41.

[0284] Returning now to the producer program control loop of FIG. 83, if the user double-clicks on a given variable from the variable list, which is shown in the project window 182 of the producer program's GUI window shown in FIG. 6, then steps 1432 and 1434 will call the variableEditor routine, described above with regard to FIG. 84 and FIGS. 37 through 41 for the selected variable. This call to the variableEditor subroutine will enable the user to edit a variable, including changing its name, changing its content type, changing its content-mapping rule type, and changing the definition for how the variable's content-mapping rules selects variable content.

[0285] As shown in FIG. 83, if the user selects Job>Add Job from the menu structure of the producer programs, step 1436 will cause step 1438 to call the jobSetup sub-routine 1456 shown in FIG. 85 for a new job.

[0286] As shown in FIG. 85 the jobSetup sub-routine contains a step 1458, which displays a Job Setup dialog box 360 shown in FIG. 44. The dialog box 360 includes a “Job Name” edit box 362 in which the user can create or edit the name for the job that is defined by the edit box. It includes a “Template” selection box 364, which allows the user to enter or select the name of a template file 130, of the type shown above with regard to FIGS. 2 and 4, to be used in producing the job's set of one or more documents.

[0287] As shown in FIG. 45, if the user clicks the down arrow button 365 in the “Template” selection box, a drop-down list 367 appears displaying the name of all of the template files in any directories associated with the current project file. This figure shows that the embodiment of the invention shown in FIG. 2 allows a user to use the content-mapping rule 134 set associated with a given project with any one of a plurality of different template files 130.

[0288] The “Data Source” selection box 366 in FIG. 44 is used to select the name of the profile database 147 shown in FIG. 2 that is to be used in producing the job. The “Record Selection” area 368 allows the user to select which individual records from the database are to have corresponding documents created for them. This selection area has two tabs, a “Simple” tab 370 and an “Advanced” tab 372. If the simple tab is selected as is shown in FIG. 44 the user is presented with a “Select All Records in Table” selection box 374, which allows the user to specify a name 374 of a table 148, of the type shown in FIG. 2, contained within the profile database for which the user wants to produce a separate document for each individual record contained within that table.

[0289] If the user places “none” in this selection box 374 of FIG. 44, the job can be used in a transactional mode, in which the job can be called with the fields of one individual record as parameters. The job will respond to each such call by producing one document using the single record whose files have been passed as parameters. Such a transactional mode can be used in a system for producing documents in response to information submitted interactively, such as over the web as is shown below with regard to FIG. 50.

[0290] If the user puts the name of a profile database table in the selection box 374 of FIG. 44, the user should select in the selection box 376 the name of the field within that table which will be used to sort the order in which records from the selected table will be used to produce corresponding documents by the job.

[0291] If the user selects the “Advanced” tab 372 in the “Record Selection” area, a blank window is displayed in which the user can enter an SQL statement to select records from the profile data source identified in the selection box 366.

[0292] The “Output Settings” definition area 378 of the Job Setup dialog box 360 shown in FIG. 44 has a “Send to” selection box 380, which allows the user to select the output type in which the documents produced by the job are supposed to be created. The “PPD” selection box 382 allows the user to select a PostScript Printer Definition file. When the job's output will be created in PostScript, such a PPD file is used to define the capabilities of the printer to which the job's output will be sent, so the PostScript generated will not exceed the capabilities of the printer.

[0293] The “Properties” button 384 allows the user to pull up a dialog box that allows the user to select more specific parameters for the particular output desired. The “Pages” controls 386 allows the user to select whether or not all the pages in the template selected in the “Template” selection box 364 are to be included in the document produced for each profile record, or whether only one or more selected pages are to be so produced.

[0294] The “Automation” check box 388 enables the user to select that the job defined in the current Job Setup dialog box is to be the default job that will be used if a call is made to produce a document in a transactional mode, discussed above with regard to the selection box 374, if no other job is specified in such a call.

[0295] Returning to the jobSetup routine of FIG. 85, if the user selects the “Preview” button 390 shown in FIG. 44, steps 1460 and 1462 will call the jobPreview sub-routine 1472 shown in FIG. 86.

[0296] As was stated above with regard to FIG. 86, this sub-routine includes a step 1474, which displays the Job Preview record selector 153 shown in FIGS. 3 and 6. As can be seen in FIG. 6 this selector 153 displays a table showing the records and fields of the profile records that have been selected by the record selection criteria contained in the “Record Selection” area 368 of the Job Setup dialog box, shown in FIG. 44, of the job for which the jobPreview routine has been called. When step 1474 of FIG. 86 first displays the record selector, the first record in the table is automatically selected.

[0297] Each time a profile record is selected in the record selector, including the automatic selection of the first record by step 1474, step 1476 causes steps 1478 through 1488 to be performed. Step 1478 calls createVariableValueTree sub-routine 1490 shown in FIG. 87 for the job's template with the selected profile record.

[0298] As is shown in FIG. 87, the createVariableValueTree sub-routine has a step 1492. which adds each unique variable name occurring in the template for which it has been called to a temporary variable list. Then a step 1494 performs a loop for each variable name in this temporary variable list. This loop is comprised of steps 1496 through 1506. Step 1496 calls the map routine 1508 shown in FIG. 88 for the variable name by using the profile record with which createVariableValueTree has been called to obtain a matching value for the variable.

[0299] As in shown in FIG. 88, the map routine includes a step 1510, which executes the content-mapping rule associated with the variable name for which it has been called, using the profile record with which it has been called.

[0300] If the content-mapping rule is a MediaBank query, step 1510 includes the execution of a conditional statement 1512, which will cause steps 1514 through 1522 to be performed. Step 1514 will instantiate the MediaBank query's associated variable SQL query template, of the type shown in FIG. 42, by replacing each of its variable symbols with the current value of the corresponding field from the current profile record. Then step 1516 sends the instantiated variable query, such as the variable query shown in FIG. 43, to the MediaBank database. Step 1518 receives the results of the query back from the MediaBank database, which results will be the path name of a selected file if the query is successful. If the query is successful, step 1520 returns the selected file path name as the value matching the variable name with which the map routine has been called. If, however, the query to the MediaBank database was unsuccessful, step 1522 returns a NULL value from the map sub-routine as the variable name's matching value.

[0301] Returning to the createVariableValueTree routine of FIG. 87, once step 1496 has obtained a matching value for the name on the temporary variable list for which the current iteration of loop 1494 is being performed, step 1498 tests to see if the variable value just obtained itself includes any variable elements. This would include any XML elements that have a data_tag attribute set equal to a variable name. If this is the case, step 1500 adds each such data_tag associated variable name to the temporary variable list for which the loop 1494 is being performed. This allows the createVariableValueTree routine to create a variable value tree that includes values for all variable elements within a template, including those which have been included in the template as the result of ingesting variable values that themselves include variable elements.

[0302] After the test and possible response contained in steps 1498 and 1500, step 1502 creates an XML variable value element 398 of the type shown in FIG. 46 for the variable name within a pf_data file. As is indicated in the case of the variable value element 398A, shown in this figure, such variable value elements can themselves be XML sub-trees if the content associated with the variable name as a result of the mapping is itself a sub-tree. As explained above, such variable value elements can themselves include variable elements, or can themselves represent area templates.

[0303] As shown in FIG. 87, step 1502's process of creating a variable value element 398 includes testing to see if the matching value produced for the variable name is a NULL value. If so, it further tests to see if the content-mapping rule associated with the variable name had the “OK to publish without value” checkbox 304 shown in FIG. 37 checked. If so, step 1504 causes step 1506 to include a “suppressed” value for visibility attribute of the variable value, as is shown in FIG. 46 for the variable value elements 398B. This will cause these elements to be allocated no space, and no visibility, in the layout of the instantiated template into which they are ingested.

[0304] Returning to the createVariableValueTree routine of FIG. 87, once loop 1494 has produced a value, either a non-NULL value or a NULL value, for each variable name in the template for which the createVariableValueTree routine was called and for each variable name that has been, mapped into that template, the pf_data file it has created will be an XML variable value tree structure containing all of the variable values needed to instantiate a given template for a given profile record, using a given content-mapping rule set. At this point the createVariableValueTree sub-routine will return to the program that has called it.

[0305] Returning now to the jobPreview routine of FIG. 86, when the call to createVariableValueTree in step 1478 of the job preview routine returns, step 1480 calls the mapVariableValuesIntoVariableElements sub-routine for the job template, using the variable value tree created by the previous call to createVariableValueTree routine.

[0306] FIG. 89 describes the mapVariableValuesIntoVariableElements routine 1524. It starts with a step 1525, which adds each variable element, that is, each element with a data_tag attribute-value pair, to a variable element list. Then the rest of the routine is comprised of a loop 1526, which is performed for each variable element in the variable element list. For each such variable name, steps 1528 through 1536 are performed.

[0307] Step 1528 finds the variable value in the pf_data variable value tree returned by the createVariableValueTree routine of FIG. 87 whose start and end tags have a name equal to the value of the current variable element's data_tag attribute. For example, FIGS. 47 and 48 illustrate the mapping of different variable values into the same template variable element 400 during the production of different documents in response to different profile records. In FIGS. 47 and 48, a variable value 398C and 398D, respectively, is found whose start tag starts with a name “mainText” that matches the value for the data_tag attribute contained within the variable element 400.

[0308] Once a variable value matching the given variable element for which FIG. 89's iteration of loop 1526 is being performed has been found, the iteration's step 1532 adds any attribute values contained in the corresponding variable value to the corresponding attribute in the variable element. This is shown in both FIGS. 47 and 48 by the incorporation of the visibility=“Visible” attribute-value pair from the variable value 398C and 398D, respectively, into the instantiated variable text element 402. It is also shown in FIG. 48 by the incorporation of the language_id=“German” attribute-value pair from the variable value 398D into the instantiated variable element 402. In the preferred embodiment, this process enable a variable value to change almost any attribute value of a variable element into which it is mapped, including, without limitation, its flex behavior attributes.

[0309] Once step 1532 of FIG. 89 has been completed, step 1534 leaves any variable element attribute values that have been defined statically in the template for the variable element in effect unless such variable attribute values have been overridden by the variable value that is being mapped into it, in which case such overriding variable attribute values will be in effect for the purpose of the instantiated variable element.

[0310] Then step 1536 places any content, or child, elements that occur between the start and end tags of the current variable value between the start and end tags of the current variable element. This is indicated in FIGS. 47 and 48 in which the content of the mainText variable value 398C and 398D, respectively, is mapped into the MainText variable element 402. In FIG. 47 this text is in English, and in FIG. 48 it is in German. If the variable value for which step 1536 is being performed includes multiple content elements, as does the variable value 398A shown in FIG. 46, all such content elements will be placed between the start and end tags of the variable element.

[0311] After step 1536 is complete, step 1537 tests to see if any of the child elements added between the variable elements start and end tag itself has a data_tag attribute, and if so it adds each such variable element to the variable element list for which the loop 1526 is being performed.

[0312] Once step 1526 has been complete for each variable element in the variable element list, each variable element in the instantiated template, including variable elements brought into the template by the content of variable values grafted on to the template's sub-tree, will have been instantiated, that is, will have variable values appropriate for the current profile record mapped into them, and the template will be ready for layout.

[0313] Returning now to the jobPreview routine of FIG. 86, once the call to mapVariableValuesIntoVariableElements in step 1480 is complete, step 1480 tests to see if a portion of the template has been previously selected for display by the current call to the jobPreview. If so, step 1484 generates the layout and display of that portion of the template which was previously displayed with the ingested content associated with the current profile record. Because of the operation of steps 1482 and 1848 a user when selecting different records in the profile record selector will see corresponding portions of the template with different data ingested as a result of different profile records. If the test of step 1482 does not find that any portion of the template has been previously displayed by the current call to the job preview sub-routine, steps 1486 and 1488 generate layout and generate a display of the document window for the start of the template associated with the current job, with the ingested content associated with the currently selected profile record.

[0314] Returning now to the jobSetup routine of FIG. 85, if the user selects the submit button 392 of the Job Setup dialog box 360 shown in FIG. 44, steps 1464 and 1466 call the runJob sub-routine 1538 shown in FIG. 90, which is normally used to generate all of the documents in a job on a batch basis.

[0315] As shown in FIG. 90, this sub-routine includes a loop 1540, which is performed for each record that has been selected by the record selection criteria defined in the “Record Selection” area 368, shown in FIG. 44, of the Job Dialog box of the current job for which the runJob sub-routine has been called.

[0316] This loop 1540 includes steps 1542 through 1554. Step 1542 selects the next profile record associated with the current job. Then step 1544 calls the createVariableValueTree routine for the job's template with the selected profile record. This is the routine described above with regard to FIG. 87 that creates a variable value tree, in the form of XML pf_data file of the type shown in FIG. 46, having a variable value for each variable name associated with the current template and any variable values that are mapped into the template for the selected profile record.

[0317] Next, step 1546 of FIG. 90 calls the mapVariableValuesIntoVariableElements routine, described above with regard to FIG. 89, for the job's template and the variable value tree returned by the call to createVariableValueTree in step 1544. This will map the appropriate variable value attribute values and contents into all of the variable elements contained in the template and in any variable values ingested into the template. Once the template has been fully instantiated, step 1548 will perform a loop for each page that has been selected by the page selection controls 386 shown in the Job Setup dialog box, of the type shown in FIG. 44, for the current job. This loop performs steps 1550 through 1554 for each such page. If the page is to be sent out as HTML, steps 1550 and 1551 are called to generateHTMLPage sub-routine 1556 shown in FIG. 91. As is described in more detail below, this routine generates an HTML file for the page, which can be stored on a web site or sent out over the web as dynamic content to a particular client computer that may have requested it.

[0318] If the job is to be printed, steps 1552 and 1554 of FIG. 90 call the printPage sub-routine 1568 shown in FIG. 92. As is described in more detail below, this routine will lay out the page, rasterize it, and then either send it either to a printer or to a file from which it can later be printed, depending on the parameters that have been selected by using the “Property” button 384 of the job's associated Job Setup dialog box shown in FIG. 44.

[0319] FIG. 49 illustrates how the present invention allows different sets of content-mapping rules, to be saved in a persistent form in different project file (numbered 132A or 132B). It also illustrates how each such set of content-mapping rules can be selected for use with one or more different template files (numbered 130A or 130B), and how a given template file can be used with the content-mapping rule sets of different projects.

[0320] As described above with regard to FIG. 2, each project file contains a variable list (numbered 134 in FIG. 2 and 134A and 134B in FIG. 49) that represents a set of content-mapping rules 452. Each content-mapping rule in such a set is associated with a variable name 450, as has been described above with regard to the Variable Editor dialog boxes of FIGS. 37 through 41. Each project file normally also includes a job list, such as the job lists 136A and 136B shown in FIG. 49, which includes one or more jobs.

[0321] As is explained above with regard to the Job Setup dialog box shown in FIG. 44, each job normally includes a template selection 456, shown in FIG. 49, which indicates which template is to be used in the job with the set of content-mapping rules defined in the job's project file to create a set of one or more documents.

[0322] Each job 454 also includes a record set selection 458, which corresponds to the record selection criteria set forth in the “Record Selection” area 368 shown in FIG. 44 of the Job Selection dialog box. This selection specifies which profile records are to each have a corresponding document created for them in the current job.

[0323] Each job in a project also includes an output specification 460 defined by the “Output Sefting” area 378 of the Job Setup dialog box shown in FIG. 44, which specifies the form in which the file is to be output, such as postscript or HTML, and specifies if it is to be sent to a printer, to a file, or over a computer network to a client computer.

[0324] As is indicated in FIG. 49, different jobs within a given project can use different templates, provided that the content-mapping rule set associated with the job's project has a content-mapping rule for each variable name that occurs in each such template. Similarly, as is shown in FIG. 49, a given template can be used in conjunction with different project files provided that each such project has a content-mapping rule corresponding to each variable name contained in that template.

[0325] For example, as is shown in FIG. 49, Template1 is used both by Job1 in Project1, and by JobA in Project2, and Template2 is used by Job2 in Project1 and by JobB in Project2. The ability to use different templates with a given content-mapping rule set is often valuable. For example, it enables one to prepare a brochure that can have multiple different forms. For example, the same variable content can be used when one template is to be mailed, includes a mailing cover, and has a certain size format; with a second template that is designed to produce PDF output to be sent over the Internet in response to requests; and with a third template in the form of one or more HTML pages that could be displayed dynamically to client computers, as will be discussed in more detail below with regard to FIG. 50.

[0326] There are many other uses for enabling different templates to be used with a given set of content-mapping rules, such as producing documents of different length, or with focuses on different areas of detail but that share common variable elements.

[0327] Similarly, it is often of value to be able to use a given template with different sets of content-mapping rules, which in the preferred embodiment of the invention are contained in different projects. For example, if one wanted-to produce corresponding but different sets of variable documents that obtain their variable content from different databases in which data is indexed differently, this could be accomplished by running each of those different jobs from a different project that has a different set of content-mapping rules.

[0328] FIG. 50 is somewhat similar to FIG. 49, except it shows an interactive server program 473 running on an Internet server can used with aspects of the present invention to provide dynamically laid-out variable documents of the Internet. The figure also shows how a given project file 132C can be used with different templates to provide either dynamically created web pages, or dynamically created PDF documents for use by client computers over the Internet.

[0329] FIG. 50 shows a server system 471, which is connected through a computer network 475 to a client computer 472. This client computer is drawn twice in FIG. 50 to represent it at successive points in the process of interactively creating dynamic web content. The top left corner of FIG. 50 shows the client computer with a screen 474A, which has an HTML form on it that allows the user to enter values for each of a plurality of fields contained within that form. In the example of FIG. 50 this form includes fields asking for information such as the user's first and last name, a destination to which he would like to travel, and a month in which he would like to start such a trip.

[0330] In FIG. 50 when the interactive program 473 detects in a step 480 that the user of the computer 472 has submitted the data contained in the form shown in the screen 474A, step 480 causes steps 482 through 484 to be performed. Step 484 enters the data contained in the form that was just submitted into a currentClientRecord that can be used as a profile record for purposes of creating variable content with the present invention.

[0331] Next, if possible, step 484 queries the client computer 472 to find out its screen size and if possible other parameters about it, such as the browser it is using. If such information cannot be obtained the job will be run with default values that are considered to provide the best overall results for most client computers. If the query does provide information, such as screen size, the dynamically created web pages can be sized to such a resolution.

[0332] Next, step 486 calls the WebPage1Job 454A, which is shown in the TravelBrochureProject file 132C, which causes that job to be performed. This will cause a single web page to be created using the WebPage1 Template 130C shown at the upper right-hand corner of FIG. 50, with the CurrentClientRecord into which information just submitted by the user has been placed as the single profile record for that job, and with the output specification for the job specifying that it is to use the generateHTMLPage routine of FIG. 91 to generate a web page as output for the job.

[0333] As shown in FIG. 91, the generateHTMLPage routine will test to see whether it has been able to obtain information on the client's screen size in step 1558 and, if so, if the template's page element has a maximizable width. Step 1560 will then cause 1562 to set the page element's width to the width corresponding to the client's screen width. If step 1558 finds out that the system does not know the client's screen size, the template's page element will be left at its default value. Next, step 1564 calls layout routine 1590, shown in FIG. 94, for the page. As will be described below, the layout routine will cause the system to determine the size and location to be associated with each layout element in the current HTML page. Then step 1566 of FIG. 91 will generate HTML corresponding to the layout. This includes specifying the size and location of all shape elements in the HTML layout to correspond to those determined by the layout process performed in step 1564, and causing any text elements contained with any such shape elements to have a corresponding HTML form that will cause them to occur within such shapes. Once this has been done, step 1567 will send the HTML file out over to a client if the output specification of the job instructs it to do so.

[0334] Returning to Word Wide Web application of the invention shown in FIG. 50, in that figure it is assumed that none of the web page jobs used in it instruct the HTML file to be sent out over the network, as just described with regard to step 1567 of FIG. 91, but instead that step 1488 of FIG. 86 does that job after the call to such web jobs are complete. Once step 1488 is complete, the client's computer will display an image of the dynamically created web page, as shown in the screen 474B in FIG. 50. This dynamically created web page can include variable content from the form that the user submitted with the screen 474A shown at the top of that figure, as well as variable content selected from among the content files 138, 140, 142, 144, and 146 shown in FIG. 50 by operation of content-mapping rules, including those which use the data asset management system 151, to help make such selections on the basis of the values of fields entered in the form shown in screen 474A.

[0335] If the user of the client computer selects a link to a different web page of the brochure generated by the TravelBrochureProject of FIG. 50 being shown on the screen 474B, step 490 causes steps 492 and 494 to be performed. Step 492 will call a web page job for the selected page. For example, if the user selects to see page two, step 492 will call WebPage2Job 454B. Calling this job will have substantially the same effect as calling the WebPage1Job 454A described above; that is, it will cause the template for the selected web page to have variable content mapped into its variable elements and it will produce a layout of that template and then produce an HTML description of that layout. Then once step 492 is done, step 494 will send the HTML of the page to the client so that it can be viewed on his computer.

[0336] If the user selects through a link or button available on one of the web pages created by the server system 471 to see a PDF copy of the brochure, step 496 causes steps 498 and 500 to be performed. Step 498 calls the PDFJob 454C.

[0337] Calling the PDFJob will cause the runJob routine 1538 shown in FIG. 90 to be performed for the PDFTemplate using the CurrentClientRecord submitted from the screen 474A shown at the top left corner of FIG. 50. This will create a variable value tree having a variable value for each variable element in the PDFTemplate or in any variable content mapped into that template. It will also map all such variable values into such variable elements within the template. Finally it will call the printPage routine 1568, shown in FIG. 92, for each page in the PDFTemplate.

[0338] As is shown in FIG. 92, the printPage routine has a step 1570, which calls layout for the current page. This determines the size and location of each layout element, whether it be a shape element or a text element within the current page of the template for which it is being called. Then step 1572 creates a rasterized page image for the page, which includes, for each layout element in the page, displaying the element in the size and position calculated for it by the page's layout with all of the element's visual attributes displayed. Once this is done, if the output specification dictates it the print page routine will send the page image to a printer, store it in a file, or send it over the network to a client computer.

[0339] In the example shown in FIG. 50, it is assumed that the print page routine itself does not send the PDF file to the client directly, but rather that a step 500 sends the PDF file created by step 1578 of FIG. 92 to the client once that file has been created dynamically for the entire template. This is indicated in FIG. 50 by printed document 502, which is shown being printed on the client computer's printer 476. The PDF file could be viewed directly on the screen of a client's computer as well as being printed.

[0340] FIGS. 51 through 58 illustrate some of the impressive flexibility that the present invention allows the page layout with variable documents.

[0341] FIG. 51 illustrates a sub-portion of a template tree, which includes an area template element, a variable area template element 166E into which a sub-tree 167, shown encircled by dotted lines, has been mapped.

[0342] FIG. 52 provides a graphic illustration of the hierarchical sub-tree elements shown in FIG. 51. As can be seen from both these FIGS. this template portion has as its highest level element a horizontal group box 164E. This contains within it two top level child elements that are horizontally displaced relative to each other within the h-box: the variable area template element 166E associated with the variable name “labeledPic,” and a text box element 156F. In the example shown in these figures, the area template variable element has had mapped, or ingested into it, a vertical group box 162E, which has two child elements, a variable image element 158E with the variable name “pic,” and a text box 156E that includes a variable text element 168E associated with the variable name “picText”.

[0343] The text box 156F includes two variable text elements as children: a TitleText element 168F associated with the variable name “titleText,” and a MainText element 168G associated with the variable name “mainText”.

[0344] In FIG. 52 the flex attributes of individual elements are indicated by arrows pointing in the dimension of the shape having such a flex characteristic. For example, the vertical group 162E, the image element 158E, and the text box 156F both have a maximized width (i.e., a maximized flex width behavior attribute value), and the area template 166E, and the text box 156E both have a minimized width (i.e., a minimized flex width behavior attribute value). All of the other dimensions of the shapes in FIG. 52 are fixed, (i.e., have a none flex width or flex height behavior attribute value) with the exception of the vertical dimension of the vertical box 162E, which is maximized, and the vertical dimension of the image element 158E, which has a proportional height (i.e., a proportional flex height behavior attribute value). In the example of FIG. 52 the maximized height of the v-box 162E will cause that v-box to expand to the fixed height of the area template element 166E into which it is ingested. The proportional height of the image element will cause the image element to maintain the same aspect ratio as the image file mapped into the image element, regardless of the image element's changes in width resulting from the image element's maximized width.

[0345] FIG. 52 also provides graphic illustration for the internal and external margin of each shape having such a margin by means of little T-shaped markers, which are labeled 504 in the case of internal margins and 506 in the case of external margins, or bumpers.

[0346] FIGS. 53 through 56 illustrate how the hierarchical layout elements described in FIGS. 51 and 52 change appearance in response to different values for their variable elements.

[0347] FIGS. 53 and 54 provide two illustrations of this portion of the template when different variable values, having different sizes, are mapped into each of its variable elements. In FIG. 53 the ingested variable values all relate to a beach pail. In FIG. 54 the variable elements all mapped in relate to a wooden airplane.

[0348] In FIG. 53 text element mapped into the text box 156E is wide and in FIG. 54 it is narrow. Since the v-box 162E and area template container 166E (shown sharing the same dotted rectangular lines in FIGS. 53 through 55) both have a minimized width, and since, in the embodiment of the invention shown, the tendency of a container to minimize dominates over the tendency of a contained element to maximize, in each of these figures the area template container 166E minimizes to the width of the v-box 162E, the v-box 162E minimizes in width to the width of the text box 156E, and the text box 156E minimizes around the size of the variable text element that has been mapped into it. This causes the maximized width of the variable image element 158E to equal the width of the text box 156E, causing the image element in FIG. 53 to be substantially wider than the image element in FIG. 54. In both figures, the large, maximized-width text box 156F expands into all of the space left available after the minimization of the vertical box 162E, after taking bumpers and internal margins into account.

[0349] It can be seen from comparing FIGS. 53 and 54 that the maximized width text box 156F and the minimized width area template 166E perform size sharing. That is, as the minimized-width one of these shapes expands and contracts in response to the variable size of its content, the maximized-width one of them contracts and expands, respectively.

[0350] FIG. 55 provides an example of the layout of the horizontal group 164E shown in FIGS. 51 and 52 if there is no image value mapped into the variable image element 158E. If this is the case, steps 1504 and 1506, described above with regard to FIG. 87, will cause there to be a “suppressed” attribute value for the visibility attribute in the variable value that is mapped into the variable image element. As will be explained below, any layout element that has a suppressed visibility will be treated as if it does not exist for purposes of layout, as can be seen in FIG. 55, in which the image element is totally missing and in which the only remaining element in the vertical group, the text box 156E, is shown in the middle of the vertical group, or v-box, 162E since it is assumed for purposes of these figures that the elements of that v-box have a centered vertical alignment.

[0351] FIG. 56 provides an example of what happens if no variable value is mapped into the variable area template element 166E shown in FIG. 51. In this case, the area template variable itself will have a “suppressed” visibility attribute mapped into it and it will be treated as non-existent for purposes of the layout of the element of which it is a direct child. This is shown in FIG. 56, where the area template element 166E, shown in FIGS. 51 through 55, is not shown at all and the text box 156F, which has a maximized width attribute, takes up all of the space within the horizontal group 164E, except that occupied by the margins 504 shown in FIG. 52.

[0352] FIGS. 57 and 58 illustrate how the flexible characteristics of the current invention tend to cause variable values to be laid out appropriately, even if they are ingested into locations of different size, including locations of different sizes in different templates.

[0353] FIG. 57 includes a top portion 510, which shows Template1130F, which contains a horizontal group 164E similar to that described above with regard to FIGS. 51 and 52, and it shows the variable area template value 167, which is mapped into the horizontal group 164E in FIGS. 51 and 52. Part 510 of FIG. 57, the horizontal group 164E, is shown containing only those of its elements which are statically defined within its template. The elements of the variable area template value 167 are shown separately.

[0354] The middle portion 512 of FIG. 57 is identical to FIG. 52, and it represents the shape elements of the horizontal box 164E once the area template value 167 has been mapped into it, indicating the flex properties of each such shape.

[0355] The bottom portion 514 of FIG. 57 is identical to FIG. 53. It illustrates the appearance of the horizontal box 164E when the Beach Pail values shown in FIG. 53 are mapped into the area template value 167 and the other elements of the h-box 164E.

[0356] FIG. 58 shows, however, that if the all the same variable values, including that same area template value, shown in FIG. 57, are mapped into portions of different templates, they will have a very different layout. This is because Template2, shown in the upper portion 510A of FIG. 58 has a vertical group 164F, rather than the horizontal group 164E shown in FIG. 57, as the container for the area template 166E and its sibling text box 156F.

[0357] The middle portion 512A of FIG. 58 provides a graphic representation of the shape elements contained within the vertical group 164F once the area template 167 has been mapped into that v-box, and the flex properties, if any, of each such shape element. As is shown in this portion of FIG. 58, the area template container 166E has a fixed width and a maximized height attribute. The text box 156F has a minimized height and a fixed width. The height and width attributes of the variable area template value 167 are the same in FIG. 58 as they were in FIG. 57 and in FIG. 52, since it is the same area template value that being ingested in both cases. That is, the text box 156E has a minimized width, both the vertical box 162E and the image element 158E have a maximized width, the vertical box 162E has a maximized height, and the image element has a proportional height that causes it to maintain the aspect ratio associated with its source image file, regardless of the width it ends up having.

[0358] As shown in the bottom portion 514A of FIG. 58, when the same area template 167 and the same Beach Pail values are ingested into the vertical group 162E they assume a very different appearance than when they were ingested into the horizontal group 164E of FIG. 57, a size and shape that is more appropriate for the different space available for them in FIG. 58.

[0359] FIGS. 91 through 103 describe the major layout-related functions of the preferred embodiment of the present invention shown in FIG. 2. The generateHTMLPage and printPage routines of FIGS. 91 and 92, respectively, have been described above.

[0360] FIG. 93 describes the updateScreen routine 1580. This routine is called by all the steps, described above, which update the document window of either the designer or the producer program in response to any changes made to the template or variable values of the document being laid out.

[0361] This updateScreen routine includes a step 1582, which determines which elements of the current page have to be laid out to generate an updated screen, given the current location of the screen relative to the page and given any changes that have been made, either to the template, to variable values, or to viewing parameters.

[0362] Next, step 1584 performs a loop for each such element that needs to be laid out and/or redisplayed by calling the layout function 1584. Once this has been done, step 1586 performs a loop for each element that has been changed, which includes drawing an image of the portion of the element that is on the screen with the element's size and position calculated by the page's layout and with all of the element's visual attributes displayed.

[0363] FIG. 94 illustrates the main layout routine, called layout, which is called to lay out all shape elements. As is shown above with regard to FIGS. 91 and 92, this routine is called to start the layout of a given page, with the page as the element to be laid out, since a page is the highest level shape that can occur within a document. Then as will be explained below, this routine tends to be called recursively for any child shapes contained within a given shape. As in shown in FIG. 94, this layout routine is called with a parameter identifying the particular shape for which it is called within an instantiated template tree for which layout is being performed, and it is called with available width and available height parameters that indicate the amount of room available for its layout. In the case of the page, this would be the size available to the page shape given the page's size and its margins. When layout is being called for a child shape within the page, this availableHeight or availableWidth is a function of the available space for the child within its parent's containing shape.

[0364] The layout sub-routine includes a step 1592, which tests to see if the shape's visibility attribute has a “suppressed” value. As stated above with regard to steps 1504 and 1506 of FIG. 87, if the value mapped into a variable element's variable name is a NULL value, and if the variable name's corresponding Variable Editor window has the “OK to publish without value” check box shown in FIG. 37 checked, that variable element will have its visibility attribute set to a “suppressed” value. If the test of step 1592 is met, steps 1594 and 1596 are performed. Step 1594 treats the shape for all layout calculations as if it did not exist and step 1596 indicates that there is to be no graphic rendering of the shape nor any rasterization or screen image generation. FIGS. 55 and 56, discussed above, illustrate the effect of steps 1592 through 1596. As described above, FIG. 55 describes a situation where an image element 158E is suppressed and FIG. 56 displays a situation where an area template variable element is suppressed.

[0365] If the shape for which layout has been called does not have a suppressed visibility attribute value, step 1598 of FIG. 94 causes steps 1600 through 1622 to be performed. These steps call the particular layout sub-routine appropriate for the particular type of shape for which the layout routine of FIG. 94 has been called.

[0366] If the shape for which the layout routine in FIG. 94 has been called has no child elements in the instantiated template tree, then steps 1600 and 1602 call the layoutEmptyShape routine 1624 shown in FIG. 95 for the shape with the same available width and available height with which the layout routine in FIG. 94 itself was called.

[0367] As FIG. 95 shows, this sub-routine starts with steps 1626 and 1628, which cause any flexible dimensions of the shape to expand as far as possible. If the dimension is a width that has either a maximized or minimized behavior attribute, step 1628 will cause that width to expand to the available width with which the layoutEmptyShape sub-routine has been called or to the shape's maximum width defined by the flex width maximum attribute 248, shown in FIG. 10. Similarly, if the shape has a flexible height, that is, a maximized or minimized height, step 1628 will cause that height to be equal to the available height with which the layout empty shape sub-routine has been called, unless that available height is larger than the value of the flex height maximum attribute 244, shown in FIG. 10, in which case it will be set to that maximum height.

[0368] Next, step 1630 of FIG. 95 tests to see if the shape has a minimized width flex behavior. If so it causes step 1632 to set the shape's width to the value defined by the flex width minimum attribute 249, shown in FIG. 10. Next, step 1634 tests to see if the shape has a minimized height and if so, it causes step 1636 to set the shape's height to the value of the shape's flex height minimum attribute pair 243, shown in FIG. 10.

[0369] Thus, the layout empty shape sub-routine causes a shape that has no children to assume a height equal to its fixed height, if it has a fixed height, equal to its minimum height if it has a minimized height attribute, and equal to the smaller of the available height with which the layoutEmptyShape sub-routine was called or the shape's maximum height attribute. It causes the shape's width to be determined in a correspondingly similar manner.

[0370] Returning to the layout routine of FIG. 94, if the shape with which the layout routine has been called is an image element, steps 1604 and 1606 will call the layoutImageElement sub-routine 1638 shown in FIG. 96.

[0371] As shown in FIG. 96, this routine starts with a step 1640, which tests to see if the shape has a maximized or minimized flex behavior for the shape's width and/or height. If this test is met, steps 1642 through 1648 will be performed. Step 1642 will change whichever of the shape's width or height dimension has such a flex attribute to the smaller of the available width or height with which the shape has been called or its maximum width or height defined by the attribute 244 or 248 shown in FIG. 10. Steps 1642 is identical to the step 1628 discussed above with regard to FIG. 95 in that it expands the current shape's flexible dimensions to their largest possible value, given the available width and height with which the shape's layout has been called and given the shape's maximum width or height attribute values.

[0372] Once step 1642 is performed, step 1644 tests to see if one of the shape's flex behavior attributes has a proportional value of the type discussed above with regard FIGS. 11, 12, and 15. If so, step 1646 finds the maximum possible height and width of a shape having the same aspect ratio as the image file that has been mapped in to the image element that can fit within the shape, given its current dimensions after step 1642. This sizing was illustrated in the example of the image elements 234C and 234F shown in FIG. 15. Once step 1646 has found the maximum size shape having the current images aspect ratio that will fit within the image element, step 1648 sets the image element's current height and width to that maximum possible size.

[0373] If the image shape does not have a maximized or minimized height or width attribute, the else statement 1647 will cause steps 1648 through 1652 to be performed. Step 1648 performs step 1649 for each dimension of the shape whose flex behavior attribute has a “source size” value. This step 1649 sets the image element's size in that dimension to the size of the image file that has been mapped into the image element, as was described above with regard to image elements 234 and 294A in FIG. 15.

[0374] Once the loop of step 1648 has been performed, step 1650 tests to see if one of the image element's flex dimension attributes has a proportional value. Since an image element cannot have two proportionally flexed dimensions and cannot have a minimized value, if this condition is met at this location in the program, it means that the shape's other dimension either a) has a fixed or b) has a source size value, which after step 1649 can be treated as a fixed value. If this is the case, step 1652 will set the proportional dimension to the length that would make the image element have the same aspect ratio as the image file mapped into it, given the image element's other fixed length dimension.

[0375] Returning to the layout routine of FIG. 94, if the shape element for which the layout routine has been called includes floating elements, that is, it is a text box having child elements laid out along one or more vertically displaced horizontal lines, such as is commonly the case with text elements, steps 1608 and 1610 call the layoutShapeIncludingFloatingElements routine 1654 shown in FIG. 97.

[0376] As shown in FIG. 97, the layoutShapeIncludingFloatingElements routine starts with steps 1656 and 1658, which are similar to steps 1626 and 1628, which start the layout empty shape sub-routine of FIG. 95. These two steps cause any of the dimensions of the shape that have either a minimized or maximized flex behavior to be expanded as much as is possible given the available width and height for which the layout of the shape has been called and given the shape's maximum width and height attribute values.

[0377] Next, step 1660 of FIG. 97 performs a loop for each child shape within the shape for which layoutShapeIncludingFloatingElements has been called having a minimized dimension. Normally most of the elements in a shape having floating elements are text elements rather than shape elements, but the preferred embodiment of the invention does allow shape elements such as images or text boxes to be floating elements. Such shape floating elements are normally placed in a shape box by using the insertShape-InText sub-routine described above with regard to step 1029 of FIG. 59 and with regard to FIG. 73. Normally such shapes are inserted in the middle of text within a text box, but it is possible for a user to insert nothing but floating shapes within a text box if desired.

[0378] Returning to the layoutShapeIncludingFloatingElements routine of FIG. 97, for each minimized child shape inserted within a text box, step 1660 causes steps 1662 and 1664 to be performed. Step 1662 calls layout for the child's shape with the availableWidth parameter for the call equal to the width of the parent text container, minus the text container's margins and the child shape's bumpers, if any. Step 1662 also sets the availableHeight parameter for the layout call equal to the height of the parent text container minus the container's vertical margins and the child's vertical bumpers, if any. Then step 1664 treats the child shape for which the current iteration of the loop 1660 is being performed as if it had a fixed size corresponding to that returned by the layout routine called in step 1662.

[0379] Once the loop of step 1660 has been performed for all child shapes within the floating element box that have a minimized dimension, if any, step 1666 lays out the text container's successive floating text and shape elements onto one or more successive horizontal lines within the internal space of the text container not occupied by its own margins.

[0380] As indicated at step 1666, this layout includes an iteration 1668, which performs steps 1670 and 1672 for each text element to be laid out. Step 1670 selects a hyphenation dictionary specified by the value of the language_id attribute for the current text element being laid out. Then step 1672 lays out the current text element on portions of one or more lines, including making any hyphenation decisions appropriate in such layout on the basis of the hyphenation dictionary selected in step 1670. This is indicated in FIGS. 47 and 48.

[0381] In FIG. 47 the text element 399 has no language_id attribute value specified in its start tag. This is because the default language_id value is us_english, which cause all text elements not having another language_id attribute value specified to have the us_english as their language_id attribute value. This causes the us_english hyphenation dictionary 600A to be selected by step 1670 of FIG. 97, and it causes step 1672 to use that us_english hyphenation dictionary to lay out FIG. 47's text element 399 on successive horizontal lines of a text box 156G, as shown at the top of FIG. 47.

[0382] In FIG. 48, a text element 399A is shown, which has a language_id attribute value equal to “german.” As is illustrated in that figure, this causes step 1670 of FIG. 97 to select the german hyphenation dictionary 600B, shown in FIG. 48, and causes the step 1672 to use that hyphenation dictionary when laying out the German text 399A along successive lines of the text box 156G of FIG. 48.

[0383] Since hyphenation rules can vary substantially from language to language, this ability for a variable text element to inherit language_id attribute values significantly improves the ability of a text layout system to more appropriately lay out variable text elements of different languages into the same templates.

[0384] Once step 1666 of FIG. 97 has laid out all of the text container's child elements, step 1674 tests to see if the container shape has a minimized width. If so, it causes step 1676 to set the shape's width to the larger of the shape's minimum width attribute value 247, shown in FIG. 10, or the width of the shape's content and the content's bumpers, if any, plus the width of the shape's internal margins. If the shape's contents, that is, its text and floating shape elements, are spread out upon more than one line, step 1676 will normally result in little decrease in the width of the container shape. This is because the layout of the elements performed in step 1666 is performed for any shape having a minimized width, after that minimized width has been expanded to its maximum value given the availablWidth parameter and given the maximum width parameter for the shape as described above with regard to steps 1656 and 1658.

[0385] After the test and response, if any, of steps 1674 and 1676, step 1678 tests to see if the container shape has a minimized height. If so, step 1680 sets the shape's height to the larger of the shape's minimum height value or the height of the shape's contents plus the height of the shape's vertical margins.

[0386] Once this has been done, the text container and any of its floating elements will have been laid out and the sub-routine can return.

[0387] Returning to the layout routine of FIG. 94, if the shape for which the layout routine has been called includes child shapes that have a fixed position, steps 1612 and 1614 call the layoutShapeIncludingFixedElements routine 1682, shown in FIGS. 98A and 98B. Shapes that include child shapes having fixed positions include group boxes, other than h-boxes and v-boxes, and they include page elements and area template elements. In such elements child element positions are defined by the left and top position attributes 219 and 220, respectively, shown in FIG. 9.

[0388] As shown in FIG. 98A, the layoutShapeIncludingFixedElements routine starts with steps 1684 and 1686, which are substantially identical to steps 1626 and 1628 described above with regard to FIG. 95. These steps cause any dimension of the shape for which the layout routine of FIGS. 98A and 98B has been called that has a maximized or minimized flex behavior to be made as large as possible, given the availableWidth and availableHeight with which the layout has been called and given the maximum width and height values of the shape.

[0389] Once steps 1684 and 1686 are complete, step 1688 performs a loop for each fixed or minimized width child shape included within the container shape for which the sub-routine of FIGS. 98A and 98B has been called. This loop includes steps 1690 through 1704. Step 1690 tests to see if the given child shape for which the current iteration of loop 1688 is being performed has a minimized width. If so, it causes step 1692 to set a variable value availableWidthForChild equal to the maximum width the child could have given the current width of the parent container, given the width of the parent container's margins, and given the child shape's fixed position defined by the left and top attributes 219 and 220 shown in FIG. 9 by its anchor point shown by the attribute value 250 shown in FIG. 10, and by the child's left and right bumpers set by the attribute values 232 and 234 shown in FIG. 9.

[0390] As is shown in FIGS. 19 through 30, if a child shape has an anchor point at a fixed position relative to a parent container, its ability to expand is a function not only of the position of that anchor point relative to the parent shape, but also of the position of that anchor point relative to the child shape itself, since the position of an anchor point relative to its shape determines in what directions the child shape can expand and contract in response to variable content.

[0391] If the test of 1690 finds the child does not have a minimized width, step 1694 sets the availableWidthForChild value equal to the child's fixed width since, as was described above with regard to step 1688, the loop of that step is performed only for children with fixed or minimized widths. Once availableWidthForChild has been set, step 1696 tests to see if the child shape for which the current iteration of loop 1688 is being performed has a flexible height, either a maximized or a minimized height. If so, it causes step 1698 to set the availableHeightForChild equal to the maximum height the child could have given the current height of the parent container shape, given the parent shape's margins, and, given the child's position, its anchor point, and the height of its relevant bumpers. If the test of step 1696 finds the child has a fixed height, step 1700 sets the availableHeightForChild equal to that fixed height.

[0392] Once the availableWidthForChild and availableHeightForChild parameters have been set, step 1702 calls the layout routine of FIG. 94 for the child shape with availableWidth equal to the availableWidthForChild value set in steps 1684 through 1688 and availableHeight equal to the availableHeightForChild value set in steps 1698 or 1700. For purposes of this call, if the child shape has a maximized height, it will be treated as having a minimized height instead. As will be explained below, several of the layout routines treat a maximized height as being a minimized height during initial layout, and then go back later and increase that height, if appropriate.

[0393] Once step 1702 has called layout for the child shape, step 1704 causes the child shape to have the size returned by that layout routine at a position within the container shape determined by the child's anchor point and its position attribute values.

[0394] Once the loop of step 1688 has been performed, step 1706 tests to see if the container shape for which the routine of FIGS. 98A and 98B has been called has a minimized width attribute. If so, it causes steps 1708 and 1710 to be performed. Step 1708 calls the findMinDerivedWidth routine for the container, assigning to all of the children that have been laid out by the loop 1688 the laid-out width returned for them by the call to the layout routine in step 1702. In step 1708's call to findMinDerivedWidth, all of the container shape's non-laid-out child shapes are assigned their minDerivedWidth value, which is obtained for them by calling the same findMinDerivedWidth routine for those children.

[0395] The findMinDerivedWidth routine is called for a shape to estimate the minimum width that the system thinks the container shape can have and still allow proper layout of its child elements, recursively taking into account the descendant elements of those child elements.

[0396] FIG. 101 describes the findMinDerivedWidth routine 1808 in more detail.

[0397] The routine starts with a step 1809, which tests to see if the shape for which the routine has been called is an image element having a “source size” flex behavior in either the width or height dimension. If so, step 1810 causes that width and/or height dimension to be treated for purposes of the rest of the layout as having a fixed length equal to the width and/or height, respectively, of the image file mapped into the image element.

[0398] Next, step 1811 tests to see if the shape's width is fixed, either by the flex-width behavior attribute or by the operation of step 1810. If so, step 1812 returns with the fixed width plus the width of the shape's bumpers, if any, as the minDerivedWidth of the shape for which the routine 1808 has been called.

[0399] If step 1811 does not find that the current shape has a fixed width, step 1814 causes steps 1816 through 1848 to be performed. Step 1816 tests to see if the shape is an image having a fixed height and a proportional width. If so, steps 1818 and 1822 are returned. Step 1818 finds the aspect ratio of the image file that has been mapped into the image element. Then step 1820 causes the image element to be treated for the rest of the current layout as having a fixed width that maintains the image's aspect ratio given the element's fixed height.

[0400] Then step 1822 returns from the findMinDerivedWidth routine with a minDerivedWidth value equal to the width of the image element set in step 1820, plus the width of that element's bumpers, if any.

[0401] If the shape for which the findMinDerivedWidth routine has been called is an empty shape or is an image element that has not been handled above with regard to steps 1809 through 1812 or steps 1816 through 1822, step 1824 causes step 1826 to return from the findMinDerivedWidth routine with a minDerivedWidth equal to the current shape's minimum width attribute value plus the width of its bumpers, if any. This causes shape containers that do not have any child elements, whether they be maximized or minimized, to be treated as requiring a minimum width equal to the value of their minimum width attribute. And it treats image elements that have a maximized width but do not have a proportional height also to be treated as requiring a minimum width equal to their minimum width attribute value.

[0402] If the shape for which the findMinDerivedWidth routine has been called is a text container with floating content, step 1830 returns with the shape's minimum width attribute value plus the width of its bumpers. This step is something of a computational shortcut, performed to improve the speed of the system's layout procedure, which has to be fast enough to be performed interactively on screen. It is a shortcut because it does not take into account the size of the shape element's contents. In other embodiments of the invention more complex algorithms could be used for determining the minimum width of such text containers as a function of their content.

[0403] If the shape for which the findMinDerivedWidth routine has been called contains fixed shapes, step 1832 causes steps 1834 through 1840 to be performed. Step 1834 performs a loop comprised of steps 1836 and 1838 for each of the container shape's child shapes. In this loop, step 1836 calls the findMinDerivedWidth function recursively for each such child shape. Then step 1838 finds the position of the child's right edge, given its fixed position, the location of its anchor point, and its minDerivedWidth value returned by the call in step 1836. Once the loop of 1834 has been returned for all such children, step 1840 returns from the findMinDerivedWidth routine with the minDerivedWidth of the parent shape equal to the greatest distance between the left edge of that container shape and the right-most edge, including any right bumper of any child determined in any step 1836 of the loop 1834, plus the width of the container's right margin and both of the containers' horizontal bumpers.

[0404] If the shape for which the minDerivedWidth routine has been called is an h-box, step 1842 calls step 1844 to return the sum of the values produced by calling minDerivedWidth for each of the h-box's children, plus the width of the h-box's margins and bumpers.

[0405] If the shape for which the findMinDerivedWidth routine has been called is a vertical box, step 1846 causes step 1848 to return with the largest value produced by calling findMinDerivedWidth for each of the v-box's children, plus the width of the v-box's margins and bumpers.

[0406] It can be seen that the findMinDerivedWidth sub-routine of FIG. 101 provides an estimate of the minimum width that will be required to lay out a certain shape, given its contents, if any. This determination operates by recursively calling the findMinDerivedWidth routine for any child elements of any shapes that occur at any level in the hierarchy of sub-elements contained within the shape for which the findMinDerivedWidth routine has been called.

[0407] Returning to the layoutShapeIncludingFixedElements routine of FIGS. 98A and 98B, step 1708 of that routine calls the findMinDerivedWidth function for each of the non-laid-out children of the container shape for which the sub-routine of FIGS. 98A and 98B is being called. It does this to determine a width for such shapes that will be temporarily treated as their fixed width and then calls findMinDerivedWidth for the parent container itself. Similarly, the widths that have been laid out for any fixed width or minimized width shapes by step 1702 will also be treated as fixed widths for purposes of the call to findMinDerivedWidth in step 1708. Once all of these widths have been assigned to all of the current containers' children, the call to findMinDerivedWidth for the container will return a minimum derived width value that will be equal to the width of all the containers' child elements, plus their bumpers, plus the width of the margins, if any, of the container shape.

[0408] Once the container shape's minDerivedWidth has been derived in step 1708, step 1710 will set the container shape's width to the larger of a) its minimum width or b) that minDerivedWidth minus the width of the container shape's bumpers, since the findMinDerivedWidth routine includes the widths of a shape's bumper in the minDerivedWidth value it returns.

[0409] Once step 1706, and possibly steps 1708 and 1710, have been performed, step 1712 performs a loop for each non-laid-out child element of the container shape for which the routine of FIGS. 98A and 98B has been called. This will include any shapes that have a maximized width attribute. The loop of step 1712 includes steps 1714 through 1724. Step 1714 sets the availableWidthForChild variable equal to the maximum width that the given child could have given the width of the parent container and its margins, and given the child's position, its anchor point, and the width of its relevant bumpers. This is similar to the step 1692 described above.

[0410] The operation of step 1714 allows child shapes to maximize into space occupied by other child shapes within the container for which the routine of FIGS. 98A and 98B is being performed, which could cause shapes to overlap. Again, this is a shortcut. It should be appreciated that in other embodiments of the invention, more complex rules could be used so as to prevent fixed child elements within a container from expanding so as to overlap one another.

[0411] After step 1714 has been performed, step 1716 tests to see if the child has a flexible height. If so, step 1718 sets the availableHeightForChild variable equal to the maximum height the child could have given the current height of its parent container and the parent container's margin, and given the child's position, its anchor point, and the height of its relevant bumpers. This corresponds to step 1698 above.

[0412] If the test in step 1716 finds the child does not have a flexible height, step 1720 sets the availableHeightForChild equal to the child's fixed height.

[0413] Next, step 1722 calls the layout routine of FIG. 94 for the current child shape for which the loop 1712 is being performed. It does so with availableWidth equal to the availableWidthForChild set in step 1714 and availableHeight equal to the availableHeightForChild set in step 1718 or 1720, and with any maximized height attribute being treated as a minimized height attribute for purposes of the layout call.

[0414] Then step 1724 places the laid-out child shape in a position relative to its parent shape determined by the child's anchor point and its position attributes.

[0415] Once the loop of 1712 has been performed for each maximized width child element, step 1726, shown in FIG. 98B, tests to see if the container shape for which the routine of FIGS. 98A and 98B is being performed has a minimized height. If so, step 1728 and 1730 are performed. Step 1728 calls findMinDerivedHeight for the container, assigning all children their laid-out height for purposes of that sub-routine to find the container's current minDerivedHeight.

[0416] FIG. 102 shows the findMinDerivedHeight sub-routine 1850. This sub-routine is virtually identical in function to the findMinDerivedWidth function described above with regard to FIG. 101, except that it operates to estimate the minimum height, rather than width, which an element requires in order to have proper layout of it and its child elements, if any. Since the text of FIG. 102 is virtually identical to the text of FIG. 101, except for changes reflecting the fact that it applies to estimating height rather than width, there is no need to describe FIG. 102 any further.

[0417] Returning now to the layoutShapeIncludingFixedElements routine in FIG. 98B, once the call to findMinDerivedHeight for the container shape for which the routine of FIGS. 98A and 98B has been called returns with an estimate of the minDerivedHeight that will allow proper layout of the container shape, step 1730 sets the container shape's height to the larger of a) the container's minimum height value or b) the minDerivedHeight returned by the call in step 1728 minus the height of the current shape's margins.

[0418] Once step 1726 and any of its resultant steps have been performed, step 1732 performs a loop comprised of steps 1734 and 1736 for each child shape having a maximized height within the container shape for which the routine of FIGS. 98A and 98B has been called. Step 1734 sets a variable availableExtraHeightPerChild equal to the maximum increase in height the child could have given the current height of its parent shape and the parent's margins, and given the child's position, its anchor, and the height of its relevant bumpers. Then step 1736 calls allowChildsMaximizedHeight for the child with availableHeight equal to the child's current height plus the availableExtraHeightPerChild attribute set in step 1734.

[0419] FIG. 103 illustrates the allowChildsMaximizedHeight sub-routine 1892. As was mentioned above, during several of the layout routines, child elements having a maximized height are treated for purposes of initial layout as if they had minimized height. The function of the allowChildsMaximizedHeight routine is to attempt to maximize the height of any such child elements that were previously laid out as if they had a minimized height. This is done because if a container shape's height is minimized, that container's tendency toward minimization is intended to dominate the tendency of any of its child elements to maximize. This, for example, is one of the reason that in many of the layout routines, fixed and minimized width shapes are laid out first. It is also the reason that maximized height shapes are treated as minimized until after their parent shape has had a chance to minimize, if it has a minimized height attribute.

[0420] The routine seeks to maximize the height of each child element having a maximized height attribute up to the height allowed by the height of its parent shape, given the vertical internal margins of the parent shape and the external vertical bumpers of the child shape. This process is often recursive because if the child shape itself includes child shapes that have a maximized height, the allowChildsMaximizedHeight routine will be called for these grandchild shapes to allow them to maximize. This recursion will travel down as many levels as is necessary to allow all maximized height elements to achieve their maximized height given the height of their container shapes.

[0421] As can be seen from FIG. 103, the allowChildsMaximizedHeight routine contains a step 1894, which tests to see if the current shape for which the routine has been called is an image element having a maximized height and proportional width. If so, the step returns without changing the child's height. This is done because changing a child's height would require changing its width if it has a proportional width.

[0422] In the embodiment of the invention shown, determinations of width dominate determinations of height, and are performed first. This is because, in laying out elements including text, the height of an element cannot usually be determined until its width has been determined. To avoid the computation that would be required for iterative layout, the present invention never changes any element's width once it has been laid out. Thus, it does not readjust the width of images having a maximized height and proportional width merely because there is more height available for the maximized height dimension.

[0423] After step 1894, step 1896 sets the height of the shape for which the allowChildsMaximizedHeight routine has been called to the smaller of a) its maximum height attribute value or b) the availableHeight with which the routine of FIG. 103 has been called. Then step 1898 tests to see if the shape for which allowChildsMaximizedHeight has been called is a container shape having one or more child shapes. If so it causes steps 1900 through 1918 to be performed. Step 1900 is a loop that is performed for each child shape having a maximized height. This loop is comprised of steps 1902 through 1914.

[0424] Step 1902 tests to see if the child has a fixed location relative to its parent. If so, it causes step 1904 to set availableExtraHeightPerChild equal to the maximum increase in height the child could have, given the current height of its parent shape and that parent shape's margins, and given the child shape's position, its anchor point, and the height of its relevant bumpers.

[0425] If the child shape for which the current iteration of the loop 1900 is being performed is located in a v-box, steps 1906 and 1908 set the availableExtraHeightPerChild variable equal to the current height of that v-box minus the vertical margins and the current height of each of the v-box's child shapes, plus any vertical bumpers those child shapes have, all divided by the number of children in the vertical box having a maximized height.

[0426] If the current child of the loop 1900 does not have a fixed location and is not within a v-box, steps 1910 and 1912 set the availableExtraHeightPerChild parameter equal to the current height of the child's parent shape minus that parent shape's margin and minus the current height of the child and its bumpers.

[0427] Once steps 1902 through 912 have set the availableExtraHeightPerChild variable for the current child shape, step 1914 makes a recursive call to the allowChildsMaximizedHeight routine for the child with the available height parameter equal to the child's current height plus the value just calculated for availableExtraHeightPerChild. This recursive call will cause all descendant elements of the element for which the routine of FIG. 103 has been called having a maximized height to have their height expanded to the extent allowed by the increase in height of their parent shape made in step 1896.

[0428] After the loop 1900 has been performed for each of the current shape's children, step 1916 tests to see if the current shape is a v-box, h-box, or text container. If so, step 1918 vertically realigns that shape's child shapes according to the vertical alignment attribute value for the container shape to take into account any changes in height of those child shapes which may have been caused by the operation of the loop 1900.

[0429] Returning now to the layoutShapeIncludingFixedElements routine in FIG. 98B, it can be seen that once the call to allowChildsMaximizedHeight in step 1736 has been performed for each child shape within the shape for which the routine of FIGS. 98A and 98B has been called, the layout of that shape having fixed elements will be complete and the layoutShapeIncludingFixedElements routines of FIGS. 98A and 98B will return.

[0430] Returning now to the layout routine of FIG. 94, if a shape for which the layout routine of FIG. 94 has been called is a horizontal box, steps 1616 and 1618 will call out the layoutHBox routine 1738 shown in FIG. 99.

[0431] As is shown in FIG. 99, the layoutHBox routine starts with steps 1740 and 1742, which correspond to steps 1626 and 1628 discussed above with regard to FIG. 95. These steps cause any dimension of the h-box that has either a maximized or minimized width or height to be expanded as large as is possible given the availableHeight and availableWidth with which the sub-routine has been called, and given the maximum width or height attribute values for the h-box.

[0432] Next, step 1744 sets availableExtraWidthPerChild to a ratio. The numerator in this ratio is equal to the h-box's current width after the changes, if any, made in step 1742 minus the sum of the following: the width of the h-box's margins and the minDerivedWidth returned by calling findMinDerivedWidth for each of the h-box's child shapes. The denominator of the ratio equals the number of child shapes with flexible width, either maximized or minimized, in the h-box. This sets the availableExtraWidthPerChild equal to the total amount of space left for expansion in the h-box after each child element is given its minDerivedWidth, divided by the number of child elements whose width can expand either by the operation of the minimized or maximized flex attribute value.

[0433] After step 1744 is complete, step 1746 performs a loop for each child shape in the h-box having a fixed or minimized width. This loop comprises performing step 1748 for each such child shape. This step calls layout for the child shape with availableWidth equal the child's minDerivedWidth plus the availableExtraWidthPerChild, and with availableHeight equal to the height of the h-box minus its vertical margins and the child's vertical bumpers. If the child shape has a maximized height attribute it will be treated as a minimized height attribute for purposes of the call, since, as has been described above, maximization of child element's height is performed by using the allowedChildsMaximizedHeight routine described above with regard to FIG. 103 after such child shapes have been laid out and their parent shape has been allowed to minimize its height, if that parent shape has a minimized height attribute value.

[0434] Once steps 1746 and 1748 have been performed for all fixed or minimized width child elements, step 1750 tests to see if the h-box has a minimized width. If so, it causes step 1752 to set the h-box's width to the larger of either its minimum width attribute or the sum of the following: the width of the h-box's margins plus the width of each laid-out, that is, fixed or minimized width, child and that child's bumpers, plus, for each un-laid-out child (i.e., each child having a maximized width) a width equal to the child's minDerivedWidth, its horizontal bumpers, and availableExtraWidthPerChild.

[0435] Once the test of step 1750 and its possible consequences have been performed, step 1754 sets availableExtraWidthPerChild equal to a ratio having as a numerator a value equal to the h-box's current width, including any change that may have been made in steps 1742 and 1752, minus a sum including the width of the h-box's margin, the width of each laid-out child element, the minDerivedWidth of each maximized-width child, and the width of all child element bumpers. The denominator of this ratio equals the number of maximized width children.

[0436] Next, step 1756 performs a step 1758 for each child element having a maximized width. Step 1758 calls layout for the child element with availableWidth equal to the child's minDerivedWidth plus availableExtraWidthPerChild, and with availableHeight equal the height of the h-box minus its vertical margins and the child's vertical bumpers. If the child has a maximized height, this call treats the child as if it had a minimized height.

[0437] Once the loop of step 1756 has been performed for each child element having a maximized width, the width of all child elements will have been determined and step 1760 horizontally aligns the child shapes within the h-box.

[0438] Horizontal alignment can have a left value that pushes all child elements as far to the left as is possible, given the sequence box's margin and the children's bumpers; a right alignment, which causes all of the children to be squeezed as far to the right as is possible, given the sequence box's margin and the children's bumpers; a center horizontal alignment, which causes all of the h-box's children to be squeezed as close to the center as is possible given their bumpers; or a justified horizontal alignment value, which seeks to equally distribute any available space within the sequence box equally between the child elements, with the left-most child element as far to the left as it can go given the sequence box's and its bumpers, and the right-most element within the sequence box as far right as possible, given the sequence box's margins and its right bumper. It should be understood, however, that if any child element within an h-box has a maximized width attribute, all four of these justification options will normally have an identical appearance because all available in the h-box will be normally be taken up by the one or more maximized width child elements.

[0439] After step 1760 has been performed, step 1762 tests to see if the h-box has a minimized height and, if so, it causes step 1764 to set the h-box's height to the larger of its minimum height attribute value or the sum of the height of the h-box's margins plus the largest height comprised by a combination of any given child shape within the h-box and the heights of that child shape's bumpers.

[0440] Next, step 1766 performs a loop for each child having a maximized height that causes step 1768 to call the allowChildsMaximizedHeight sub-routine described below with regard to FIG. 103 for the child. This call is made with availableHeight equal to the height of the h-box minus its vertical margin and minus the current child elements' vertical bumpers. As was explained above with regard to FIG. 102, this will cause each such maximized-height child element to have its height increased to the availableHeight, and will cause any of the child element's descendants having a maximized height to also have their heights increased to the extent made possible by their respective parents' height maximization.

[0441] After the loop of step 1776 has been performed, step 1770 vertically aligns child element shapes within the h-box, giving them a top, bottom, or alignment, which correspond, respectively, to the left, right, and center alignment settings discussed above, except that they operate in a vertical dimension rather than a horizontal dimension.

[0442] Returning now to the layoutShapeIncludingFixedElements routine of FIG. 94, if the shape for which the layout routine has been called is a vertical box, steps 1620 and 1622 will call the layoutVBox sub-routine 1772 shown in FIG. 100.

[0443] As is shown in FIG. 100, the layoutVBox sub-routine has steps 1774 and 1776, which operate like steps 1626 and 1628 of FIG. 95 to cause the shape for which that sub-routine was called to expand in any of its two dimensions that have a minimized or a maximized flex behavior attribute to as a large a value as is allowed by the availableHeight or availableWidth parameters with which the sub-routine has been called, or by the shape's maximized height or width attributes.

[0444] Next, step 1778 sets availableExtraHeightPerChild to a height defined by a ratio having as the numerator the height of the v-box minus the sum of the v-box's vertical margins, plus the minDerivedHeight returned by calling findMinDerivedHeight for each of the v-box's child shapes. The denominator of the ratio is the number of the v-box's child shapes.

[0445] Next, a loop 1780 performs step 1782 for each child shape within the vertical box having a fixed or a minimized width. Step 1782 calls the layout routine of FIG. 94 for each such child shape with availableWidth equal to the width of the v-box minus its horizontal margins, and with the availableHeight parameter equal to the child's minDerivedHeight plus the value of availableExtraHeightPerChild. If the child element has a maximized height, step 1782 treats the shape as having a minimized height for purposes of the call.

[0446] After each fixed or minimized width child shape has been laid out, step 1784 tests to see if the v-box has a minimized width. If so, step 1786 sets the v-box's width to the larger of the v-box's minimum width attribute value or the sum of the v-box's horizontal margins plus the largest width associated with any child shape, using for any child shape that has been laid out in the loop 1780, using the laid-out width of that child shape plus the width of its bumpers, and using as the width for any child shape that has not been laid out, i.e., which has a maximized width, the minDerivedWidth returned by a call to findMinDerivedWidth for such maximized width child element.

[0447] Next, step 1788 performs a loop for each maximized width child shape that causes step 1790 to call layout for that shape. In each such call availableWidth equals the width of the v-box, minus its horizontal margins, and availableHeight equals the minDerivedHeight value returned by a call to findMinDerivedHeight for the child shape, plus the value of availableExtraHeightPerChild set in step 1778. If the child has a maximized height, it is treated as having a minimized height for purposes of the call.

[0448] After the loop 1788 has been performed, step 1792 horizontally aligns the child shape elements within the v-box as a function of the vertical box's horizontal alignment attribute value.

[0449] Next, step 1794 tests to see if the v-box has a minimized height. If so, it causes step 1796 to set the v-box's height to the larger of its minimum height attribute value or the sum of the height of each laid-out child, plus the height of each such child's vertical bumpers, plus the height of the v-box's margins.

[0450] If the v-box does not have a minimized height, the else statement 1798 will cause steps 1800 through 1804 to be performed.

[0451] Step 1800 sets availableExtraHeightPerChild equal to a height defined by a ratio having as its numerator the v-box's height minus the sum of the v-box's vertical margins, plus the height of each child shape and its vertical bumpers. The denominator of this ratio is the number of child elements having a maximized height.

[0452] Next, step 1802 performs a loop comprised of step 1804 for each of the vertical box's child elements having a maximized height. Step 1804 calls the allowChilds-MaximizedHeight sub-routine, described above with regard to FIG. 103, for each such child with availableHeight equal to the child's laid-out height plus availableExtraHeightPerChild. As explained above with regard to FIG. 103, this causes each such child element to have its height increased by the availableExtraHeightPerChild and recursively causes any of its child elements having a maximized height attribute value to also have their height values increased.

[0453] After the operation of steps 1794 through 1804 has been completed, step 1806 vertically aligns the child shapes within the v-box, depending upon the vertical alignment attribute value for the v-box. If any of the child elements within the vertical box have a maximized height, there will normally be no distinction between the top, bottom, centered, or justified vertical alignment attribute values, since vertical maximization will normally take up any available space within the vertical box, preventing any room for vertical alignment.

[0454] After the performance of step 1806, the layout of the v-box will be complete and the layoutVBox sub-routine will return.

[0455] From the above discussion, it can be seen that the combination of the layout routine of FIG. 94, and the various layout routines it calls, is capable of laying out all of the shape elements used in the described embodiment of the inventions.

[0456] It should be understood that the foregoing description and drawings are given merely to explain and illustrate, and that the invention is not limited thereto except insofar as the interpretation of the appended claims are so limited. Those skilled in the art who have the disclosure before them will be able to make modifications and variations therein without departing from the scope of the invention.

[0457] In particular, it should be noted that this application explains the present invention in more detail than is common in many patent applications, and the inventors hope they will not be improperly punished for providing such detailed teaching of this invention to the public by having the scope of their claims limited by the greater details of that teaching. Punishing a more detailed teaching of an invention with a more limited interpretation of the claims would be contrary to one of the primary purposes of the patent system, which is to reward inventors for teaching their inventions to the public. Considerable thought has gone into the wording of the following claims so that they will provide an accurate description of what we consider to be our invention, and it is hoped that such wording will be viewed as the most accurate description of exactly which details are considered to be part of an invention recited by a particular claim and those which are not. For example, where a dependent claim includes limitations not contained in a parent claim, it is our intention that that such a limitation not be read into the parent claim.

[0458] The following paragraphs list just some of the many way in which other embodiments of the invention could differ from those shown above.

[0459] The invention of the present application, as broadly claimed, is not limited to use with any one type of operating system, computer hardware, or computer network, and, thus, other embodiments of the invention could use differing software and hardware systems.

[0460] Furthermore, it should be understood that the program behaviors described in the claims below, like virtually all program behaviors, can be performed by many different programming and data structures, using substantially different organization and sequencing. This is because programming is an extremely flexible art in which a given idea of any complexity, once understood by those skilled in the art, can be manifested in a virtually unlimited number of ways. Thus, the claims are not meant to be limited to the exact steps and/or sequence of steps described in the figures. This is particularly true since the pseudo-code described in the text above has been highly simplified to let it more efficiently communicate that which one skilled in the art needs to know to implement the invention without burdening him or her with unnecessary details. In the interest of such simplification the structure of the pseudo-code described above often differs significantly from the structure of the actual code that a skilled programmer would use when implementing the invention. Furthermore, many of the programmed behaviors which are shown being performed in software in the specification could be performed in hardware in other embodiments.

[0461] In the main embodiment of the invention discussed above, almost all of the various aspects of the invention are shown occurring together in the one system shown in FIG. 2. It should be understood that in other embodiments of the invention different subsets of one or more individual aspects of the invention will occur in a given system.

[0462] In the description above, the operation of certain aspects of the invention are optional. In other embodiments of the invention, the user might not be given the choice of selecting whether or not a given aspect of the invention is to operate. As just one example, in the embodiment of the invention above, the ability of a variable element to be suppressed if no value is mapped into it depends upon the user's selection of the “OK to publish without value” option, as is discussed with regard to steps 1504 and 1506 of FIG. 87. In other, less flexible embodiments of this aspect of the invention, variable elements might always be suppressed.

[0463] In other embodiments of the some aspects of the invention, other types of content-mapping rules might be used. For example, rules allowing more complex logical mappings might be used, or rules using other mapping techniques, such as neural networks or multi-dimensional clustering, might be used. Also, in different embodiments, different user interfaces could be used to enable a user to define or select content-mapping rules. For example, content mapping rule sets could be stored in their own files, separately from job lists, and/or the content mapping rules used for a given job could be individually selected from different rule sets. In other embodiments, variable queries of the type discussed above with regard to FIGS. 41 through 43 could be used to send queries to other types of data bases besides MediaBank digital asset management systems, and the variable queries could be represented in a form other than SQL.

[0464] In other embodiments of some aspects of the invention, content-mapping rules and variable elements can be bound together by a technique other than the use of common variable names, as is disclosed above. For example, they could be bound together by use of a common symbol other than a text name, or they could be bound together by a user interface which would allow a user to selectively associate a given content-mapping rule with a given variable element by dragging and dropping an icon representing that rule into a representation of the variable element.

[0465] In other embodiments of some aspects of the invention, the ingesting, or grafting, of variable content into variable elements could be performed in a different way. For example, in some less flexible embodiments, variable values might not include attribute values which can be imported into a variable element. In other less flexible embodiments, variable elements might not be allowed to contain default attribute values or default contents. In more flexible embodiments, a combination of variable values, instead of just one variable value, could be grafted into a given variable element. In some embodiments, variable content could be selected using one content-mapping rule and variable attributes for the variable value could be selected with a separate content-mapping rule.

[0466] In other embodiments of some aspects of the invention, the minimization or maximization of a shape element could function differently,such as by using either more complicated or more simple rules. For example, in other embodiments, minimization or maximization need not be limited by the element's minimum or maximum attribute values. In the embodiment described above, the maximization of a child shape is usually limited by the minimization of its parent shape. In other embodiments this need not be the case. In the embodiment described above, the layout of a text container with a minimized width does not take into account how much vertical space the container has for multiple lines of text when determining its width. In other embodiments of the invention it could. In the embodiment of the invention described above, the layoutShapeIncludingFixedElements routine of FIGS. 98A and 98B does not prevent the overlapping of child elements. In other embodiments it could. In the embodiment of the invention described above, each element is only laid out once, with only one call to the layout routine. In other embodiments of the invention the layout of multiple shapes could employ more complicated schemes such as constraint propagation, iterative relaxation, or automatic learning techniques.

[0467] In other embodiments, some aspect of the invention could be used to layout different types or combinations of output, laying out documents on computer screens, on printed documents, on printable file formats, in HTML, on electronic signs and billboards, in documents or images created with electronic ink, in video content, in holographic projections, and virtually any other type of two- or three dimensional visual media, including interactive media.

[0468] In other embodiments of some aspects of the invention different user interfaces can be used. The various aspects of the invention claimed below are not meant to be limited to the particular command structure or GUI of the user interface shown above, except to the extent, if any, that such a limitation is specifically contained in claims to that aspect of the invention.

[0469] In other embodiments of some aspects of the invention, different forms of representation could be used than those shown above. For example, templates, area templates, and formatted text and formatted paragraphs, need not be stored in XML, but could be stored in virtually any form capable of representing the relationships between their elements. Some aspects of the invention are not even limited to templates which are represented as a tree shaped data structure.

[0470] In other embodiments of some aspects of the invention, text and geometric models need not be stored in the form shown in FIG. 5. For example in other embodiments they also might be represented in XML or a similar tagged text language. According to some aspects of the invention text and geometric models might actually be stored in different files.

[0471] In other embodiment of different aspects of the invention, text and shape elements and styles could have different attributes, different combinations of attributes, and different possible combinations of attribute values than those shown above. And in other embodiments of some aspects of the invention, different types of elements could be used. For example, in some embodiments of the invention text containers having a shape corresponding to a user defined polygon can be used.

[0472] In other embodiment of the invention functionality could be spread across different programs and/or different computers in a different manner than is shown in the figures above. For example, in other embodiments of the invention all the functions of the designer, producer, and server programs 124, 126, and 128, respectively shown in FIG. 2, could be placed into one program. In other embodiments of some aspects of the invention different functions could be performed by different machines. For example, as indicated above the designer, producer, and server programs can all be run on different machines. The server program in particular can benefit from running on a computer which has hardware optimized for rasterizing page images. In the network embodiment shown in FIG. 50, the definition of the screen images shown on the computer's screen 474B is in part performed by the server system 471 and partially performed by the client computer 472. In other embodiments, other distributions of tasks could be performed. For example, the data bases on which content files are stored might be on different machines than those on which page layout is performed.