Generating Figures in a Document Formatter Directly From a Declarative Tag

1. Technical Field

The present invention relates generally to document composition. In particular, the invention relates to software systems which provide interactive support for authors of complex documents which combine text and graphics art. Typically, these documents have several illustrations on each page.

2. Background Art

Previously, creating these documents involved manually merging the text and illustrations by a "cut and paste" method to determine individual page layouts. Quite clearly this type of production is quite costly in terms of time and labor. In addition, revising such documents or maintaining multiple versions of a document in this way is difficult and expensive.

To solve these problems, an interactive document formatter program JANUS was developed which provided authors with immediate feedback and direct electronic control over page layouts. It permits the author to control placement of illustrations in text electronically and to review the finished pages immediately on a graphic display. The architecture of the JANUS program is described in a paper by D. D. Chamberlin, et al. entitled "JANUS: An Interactive Document Formatter Based on Declarative Text", IBM Systems Journal, Volume 21, Number 3, 1982, at page 250. In the JANUS system, an author may mark up his document using "tags", a high level of notation which identifies the various parts of the document, such as paragraphs and chapter headings, numbered items and footnotes. Each tagged items is formatted according to the instructions contained in a separate procedure specific to that tag. Such a system provides the benefit of a high level markup language in which complex formatting procedures are invoked by simple tags and are uniform because their appearance is controlled by the tag procedure rather than by an individual writer. Furthermore, an entire set of documents can be uniformly reformatted by revising the tag procedure without revising the markup in the individual documents.

More recently a software system called the Interactive Composition and Editing Facility (ICEF), which is based on the JANUS system, has been made commercially available. The ICEF program allows a document to contain mixtures of text in various fonts, graphics, scanned images, tables and mathematical formulae. Pages containing all such text may be displayed on the user's terminal and changes applied without going off line. At the conclusion of preparing the document, it may be printed. The ICEF program operates on an IBM System 370 under the VM/CMS operating system and the document is printed out by a high resolution printer such as the IBM 4250 printer.

The document may be displayed on a two-screen work station such as the IBM 3277 display terminal and a Tektronix 618 storage tube which provides a full page size, all-points-addressable screen for display of the formatted document. The JANUS system allows various kinds of figures to be placed in the document and thereafter printed by preparing the figure in a specified file format using an image or a graphic editor, using a command to prepare the figure to be displayed and printed and using the name of the file as an attribute for some tag that calls for an imbedded image or graphic drawing. This technique, while quite useful, has the disadvantage of requiring a separate graphic file to produce the image at the desired location on the document. The graphic file needs to be separately generated and requires a relatively large amount of storage for the graphic.

The ICEF program is described in the following publications which are available from an IBM branch office: "Interactive Composition and Editing Facility--User's Guide", IBM document no. SH20-0363-0, and "Interactive Composition and Editing Facility--Installation and Style Definer's Guide", IBM document no. SH20-0364-0.

ICEF can format documents for printing and is an interactive system which allows an author to see immediately what his formatted pages will look like on the display, although ICEF may also be used with the traditional "batch" approach to formatting.

ICEF, like JANUS, allows the author to "mark up" the document with high level "tags" in a notation known as the "generalized markup language" (GML). GML tags identify the various parts of the document such as headings, figures, and footnotes. The program then formats the pages of the document based on this understanding of the various document parts. The ICEF program also allows an author to embed images and graphics in the document which are shown on the display as the document is formatted and which are printed on the final output pages.

Both the JANUS and the ICEF program systems allow various kinds of figures to be placed in the document and thereafter printed. The figure is generated by a graphic editor in a specified format. The figure is prepared for display and printing by using a command which is not a tag. Finally, at the place in the markup where the figure is to be inserted, a tag is included in the markup language. This tag causes the figure to be embedded in the formatted output. The name of the figure would be an attribute of that tag. This technique, while quite useful, has the disadvantage of requiring a separate graphic file to produce the image at the desired location on the document.

A similar problem is addressed by Lemelson in U.S. Pat. No. 3,872,462. Lemelson discloses electronically generating a blank form, i.e. certain entries not filled out, on a CRT and then keying in the missing entries. Lemelson does not disclose the use of graphics however. Fessel in U.S. Pat. No. 4,403,301 discloses an apparatus similar to that of Lemelson.

It is an object of the invention to provide formatting of graphics in a document without resorting to a manual "cut and paste" method.

It is another object of my invention to improve and expand the function of interactive document formatters.

It is a further object of my invention to make it unnecessary for graphics such as curves to be stored in a file while is separate from the mark up file of such formatters.

It is yet another object of my invention to improve the capability of automatic text formatter programs which recognize some types of generalized markup language.

This invention provides the generation of curves and other figures from within a generalized markup language tag and placement of them in formatted text output by mathematically calculating the position of some number of points on the curve or other figure and placing a mark in the formatted output for each point. In this way, the curves or other figures are generated directly from the tag. By using this invention, separate graphic files are not necessary. In this invention, a neg tag is created which will be recognized by the formatter program in which the language for implementing the tags provides a way to generate a mark of an arbitrary size at an arbitrary location in the formatted output.

The foregoing and other objects, aspects and advantages of my invention will be better understood from the following detailed description with reference to the drawings in which:

FIG. 1 is a block diagram of the ICEF architecture.

FIG. 2 is a sample document, generated by the invention, which incorporates a rectangle with rounded corners in the formatted output.

FIGS. 3 and 4 illustrate a flow diagram for the procedure of the invention.

FIG. 5 illustrates an arrow and a circle in the formatted output.

As noted above, my invention is useful for any automatic text formatting program which recognizes a generalized markup language, is capable of creating new tags which will be recognized by the formatter and which provides a way to generate a mark of an arbitrary size in an arbitrary location in the formatter output. In the following description I will specifically refer to the Interactive Composition and Editing Facility (ICEF) program which is a commercially available program offering from the IBM Corporation.

The ICEF user marks up his document using a set of high-level tags which itentify the various parts of the document. The tags are interpreted according to a style definition that controls the appearance of each part of the document. A document may contain various parts such as headings, paragraphs, lists, footnotes, tables and mathematical formulae. A standard style definition called GDOC also provides tag that may be used to generate a table of contents, list of illustrations, index and bibliography. The ICEF program also provides a means whereby a user can modify parts of a style definition or create new style definitions of his own.

The advantage of marking up documents with high level tags allow a single descriptive tag such as "footnote" to take the place of dozens of lower level commands to control the appearance of a footnote, and tags enable the formatting system to understand the structure of the document. The user can use this information to make the job of editing the document easier. A complete list of tags used in the ICEF program is shown in the previously cited "Interactive Composition and Editing Facility: User's Guide".

The ICEF notation for marking up a document is a subset of the proposed ANSI/ISO standard generalized markup language (GML). The proposed standard is described in a docuemnt entitled "International and American National Standard for Computer Languages for the Processing of Text: Standard Generalized Markup Language", Dec. 1, 1982, cited in footnote 4 on page 15 of the previously cited "Interactive Composition and Editing Facility: User's Guide". In this language, each structural part or "element" of a document is identified by a "tag" which begins with a colon (:).

The particular style which will be used throughout this specification is the GDOC (general document) style which is intended for use with general documents. The GDOC style definition of ICEF is modeled on a "starter set" of tags which are listed, along with their functions and attributes, in the above-referenced "Interactive Composition and Editing Facility: User's Guide".

One of the commands of the ICEF language is the BOX command, as described in the User's Guide at pages 33-40. The BOX command is central to the formatting of the document and the generated box is usually invisible in the final output. However, this command allows a Framed option which makes the boundaries of the box visible in the final output. The Framed Box Command thus enables the final document to contain outlining boxes, perhaps with included text. Such boxes are considered very useful for emphasizing important points and for graphically organizing a document for ease of understanding.

However, a box is only a limited graphical tool and it is felt that more elaborate graphics should be made available.

One very useful graphic, particularly for the computer and word processing industry, would be a graphic that represents the screen of a terminal or CRT. It is typical in instruction manuals in the industry to present a few paragraphs of text regarding data entry and then to illustrate a resultant display on the CRT screen. A visible box, generated by the Framed BOX command in the ICEF language, could be used to represent the screen. However, a CRT screen almost invariably has rounded corners so that the box representation does not immediately elicit the desired recognition. Furthermore, a box representing a CRT screen can be confused with boxes intended only to highlight important points. In user's manuals, any possible confusion should be minimized.

At the present time, the ICEF language does not provide the graphic for a screen. The principal embodiment of the invention to be described below will involve a tag for generating a screen graphic, that is, a box with rounded corners. However, it is to be understood that the invention is not so limited to the generation of rounded boxes, but can be extended to more general non-rectangular graphics, a few of which will be briefly described. The described embodiment of the invention uses the presently available ICEF language to allow the use of a tag :SCREEN that will eventually generate a screen graphic, perhaps enclosing some text, in the formatted output.

For an understanding of the invention, it is useful to understand the ICEF architecture, illustrated in FIG. 1. During an ICEF session, the user at a terminal 10 has available the regular editing commands of XEDIT 12 as well as some specialized ICEF commands, implemented as XEDIT macros. The user can call up lines from the user's markup file 14, perhaps revise them, and send them to a parser 16. The parser 16 using rules from a syntax file 17 for the current style recognizes tags and finds a possible textual passage associated with each tag. For each tag, the parser calls a tag interpreter 18, which interprets the tag using a tag routine found in a TAGDEFN file 20. The TAGDEFN file 20 contains an efficient representation of the tag routine provided by the style definer in a TAGS file 22 as translated by a style translator 24. While interpreting a given tag, the tag interpreter 18 may make calls to a formatter 26 and a data base manager 28. The data base manager can temporarily store in a database 29 information about headings, figures and the like for use elsewhere in the document. The formatter 26 accepts commands from the tag interpreter 18 and text from the parser 16 to produce a long column of formatted text called a galley. This galley is sent to a packer 30, which cuts up the galley and packs it onto pages according to page templates contained in a TEMPLATE file 32. The resultant formatted pages are displayed on a graphic display 34 and saved in an output file 36.

The present invention uses the tag definition language of ICEF to produce a new tag :SCREEN in the TAGS file 22. The tag :SCREEN can be defined either by the style editor or could be included as a predefined tag in an expanded version of ICEF. A tag can be inserted into the edited markup file 14 by the user at the terminal 10. Thereafter, the tag :SCREEN is recognized by the tag interpreter 18 which invokes the :SCREEN tag definition from the TAGDEFN file 20. The result is a screen graphic appearing on the formatted page displayed on the CRT display 34 and preserved in digital form in the output file 36.

The invention provides for the formatted display shown in FIG. 2. The screen outline consists of two horizontal straight lines 40 and 42 and two vertical straight lines 44 and 46. The screen frame further consists of four 90.degree. rounded corners 48, 50, 52 and 54. The :SCREEN tag is written to simulate the screen frame with a series of Framed BOX commands, each with the Frame option active so that the resultant boxes are visible. The two vertical lines 44 and 46 consist of tall slender boxes, while the horizontal lines 40 and 42 consist of boxes that are wide and shallow. The corners 48-54 each consist of a sequence of very small boxes so close together that they appear as continuous curves. Of course, all the lines 40-54 are positioned so as to form a continuous screen frame.

The tag definition contained within the TAGDEFN file 20 is an executable procedure. A flow chart for this procedure is given in FIGS. 3 and 4, and is executed whenever the tag :SCREEN is encountered by the tag interpreter 18.

The radius of the circles for the four corners 48-54 is first determined. This radius can be either a number of units fixed in the procedure or can be produced by the parameters resulting from the styling of the tags. Then an invisible box is opened to enclose the entire screen. This is a rectangular box resultant from the BOX command. The left and right sides of the box are generated from the parameters of the chosen style. For instance, the width of the box is dependent upon the page width and whether the page is divided into columns and the width of side margins. The height of the box is determined later when the box is closed. The box thus opened is never made visible but simply determines the extent of the final display. Then a thin wide box is generated for the top horizontal edge 40 of the screen frame. This thin wide box is made visible by the Frame option. The height of the box is chosen such that the two horizontal edges appear to the viewer of the output to merge into a single line. The width of the box is the width of the enclosing box of the previous step reduced by two radii to account for the top edge 40 only extending to the beginnings of the two top corners 48 and 50.

Then the number of points in 45.degree. of arc for any of the corners 48-52 is determined. This number is determined so as to provide the appearance of a continuously varying curved line and thus will depend upon the value of the radius and the size of the very small boxes generated later to form the curved corners 48-52. The number of points can be either fixed within the procedure or made dependent upon style parameters.

Thereafter, a series 56 of steps is entered that generates seemingly continuous curves from a number of boxes to form the two upper curved corners 48 and 50. The series 56 is a loop of steps. For each pass through the loop, boxes are placed at four symmetric points on the two upper corners 48 and 50. First, a test is made to determine if all the points from 0.degree. to 45.degree. have been drawn for the top corners 48 and 50, that is, whether the loop has been passed through as many times as the number of points determined in the previous step. If the result of the test is true, then execution passes outside of the series of steps 56, as will be described later. If, however, there are points remaining to be drawn, then the angle .alpha. of the next point is calculated. This angle .alpha. will, of course, depend upon the number of points in the 45.degree. of arc and the number of times the series 56 of steps has been executed. Once the angle .alpha. has been determined, then the trigonometric function sin (.alpha.) and cos (.alpha.) are calculated. These trigonometric calculations are included as separate steps because the ICEF, language, being non-scientific, does not provide trigonometric functions and the procedure must include a method of calculating these functions, such as power series expansion.

The positions of 4 points in the upper two corners 48 and 50 are then determined. The position of the point at the angle .alpha. from the bottom-most end of the arc of the right upper corner 50 is located at (1-cos.alpha.) times the radius of the 4 corners 48-54 to the left of the right edge of the invisible box enclosing the screen. This invisible right edge traces the right edge 46 of the screen except in the vicinity of the two right corners 50 and 54. The point is located vertically (1-sin.alpha.) times the corner radius below the top edge of the invisible enclosing box. This top edge coincides with the top edge 40 of the screen except in the vicinity are expressed in the same units as the radius.

Then the position of the point at 90.degree.-.alpha. in the upper right corner 50 is determined. This second point is symmetric to the first point about the 45.degree. bi-sector of the upper right corner 50. The position is (1-sin.alpha.) times the radius to the left of the right edge of the enclosing box and (1-cos.alpha.) times the radius below the top edge of the enclosing box.

The two more points on the upper left corner 48 are determined. The position of the point at 90.degree.+.alpha. is (1-sin.alpha.) times the radius to the right of the left edge of the enclosing box and (1-cos.alpha.) times the radius below the top edge of the enclosing box. The left edge of the enclosing box coincides with the left side 44 of the screen except in the vicinity of the two left corners 48 and 52. The position of the point at the angle 180.degree.-.alpha. is (1-cos.alpha.) times the radius to the right of the left edge and (1-sin.alpha.) times the radius below the top edge.

Then at the edge of the four positions so determined, a dot-sized visible box is generated by the BOX command with the Frame option on. The four boxes are sized so that they appear at point. However, there are a sufficient number of finite sized boxes that they provide the appearance to the viewer of a continuous line. Once the four boxes have been generated, execution returns to the beginning of the series 56 of steps. In this way, the two upper corners 48 and 50 are formed and meet the upper side 40 of the screen.

Then an invisible box is opened inside and below what has been drawn. This box opening does not yet define the bottom of the open box. The top of the opened box can conveniently be defined as being a radius of the corners 48-54 below the top edge 40 of the screen. The left edge of the opened box could conveniently be placed a fixed distance to the right of the left edge 44 and the right edge of the opened box the same fixed distance to the left of the right edge 46 of the screen.

Then the scope of the screen is obtained from the markup file 14 and this is formatted into the just opened box. This scope is typically dictated by the text which is to be enclosed within the screen and is included as alphanumeric characters as parameters of the :SCREEN tag entered by the operator. An example of such text and its format is shown in FIG. 2 enclosed by the frame of the screen. With the text entered into the opened box, the box is then closed. The height of the closed box is dependent upon the amount of text which had been formatted into the box. Thus, the closed box will be used to determine the height of the screen.

Then an invisible named box is generated. The box will be inserted below the just closed box so that its top identifies the bottom of the formatted text. The named box is immediately closed so that its height is infinitely small. This box is used only to obtain positioning information. Then two narrow, tall boxes are generated and made visible. These boxes extend respectively from the bottoms of the two top corners 48 and 50, respectively, to the top or bottom of the named box. They are narrow enough to appear as though their respective right and left sides merge and thus form the right and left edges 46 and 44 of the screen frame.

Then the two lower corners 52 and 54 are generated similarly to the upper corners 48 and 50 of the upper corners 48 and 50 by generating points at 180.degree.+.alpha., 270.degree.-.alpha., 270.degree.+.alpha. and 360.degree.-.alpha.. A looped series of steps is executed similarly to the series 56. Of course, the position equations are somewhat modified, as should be obvious by the geometric configuration, and the vertical positions are measured relative to the top or bottom of the named box that has been determined by the bottom of the formatted text.

Then, a thin, wide, visible box is generated to form the bottom edge 42. This box is displaced vertically downward one radius from the top of the named box and has its horizontal length reduced by two radii such that the box touches the lower ends of the two lower corners 52 and 54.

Finally, the invisible box that was opened at the beginning of the procedure is closed. This box will barely include the lower edge 42 of this screen frame. Execution then returns to the parser.

A software program, written in the tag definition language of ICEF that will execute the above procedure, is presented in Appendix A. The line ".imbed rtos" in the SCR TAGS file causes the contents of the RTOS TAGS file, included in Appendix B, to be included by the style compiler at that point. It works as though the code in RTOS TAGS has been physically located where the "imbed" appears. The tag :SCR is a separate preparatory tag that is executed to initialize various parameters in the editing. The software presented in Appendix A defines a complete style that was used in the development of the :SCREEN tag. The intention is to incorporate the tag :SCREEN into the general GDOC style, in which case the initializing is already provided so that the :SCR tag is not then necessary.

Although the principal embodiment has involved the graphic for a screen, it is to be appreciated that the invention can be easily extended to other geometric but non-rectangular graphics. For example, software has been written, similar to the :SCREEN tag for an arrow 60 and a circle 62, as shown in FIG. 5. This figure shows how two graphics can be beneficially combined, one primarily intended for a teaching tool and the other for a representation of a physical object. It should be noted that the software can easily include the option of rotating the arrow 60. The software required for both these graphics can easily be written by a programmer skilled in the ICEF language, following the example for the :SCREEN tag.

The procedure of Appendix A can be called from the mark-up language by software presented in Appendix C. Calls for several different tags are presented therein. The call of interest is ":screen". It is of course noted that capitalization is not required and that the complete call is ":screen. This text is the scope of the screen tag. It should etc." The text following the period after "screen" and up to the next colon-delimited tag is the text which will be included within the screen. The placement of the screen in the document depends on the location of the screen tag in the markup.

Also included in Appendix C are calls for the circle graphic and the arrow graphic as well as a combined arrow and circle. ##SPC1##