Superblock structure in a multiple in a data editor

Abstract

Improvements in an application composite editor for compound documents containing not only text but also graphics and tables facilitate the manipulation of object sets in the formatting algorithm. The editor works with a page layout philosophy wherein data objects reside on the page and data resides in the data objects. All pages reside within a document object, and some data objects may have additional objects within them. Objects are data-specific entities that the user can manipulate on the page. All objects exist within a specified boundary on the page, and this boundary is defined as an object set boundary. Object sets may be moved into positions on the page such that more than one object set is occupying a single displayable area on the page. Such an arrangement of objects creates a structure called a superblock. A superblock is any displayable area containing two or more object sets positioned so that the object sets overlap one another, reside side-by-side or extend above or below one another. A text object set may not be overlapped by any other object set. Although the superblock is itself a complex structure, the creation of this structure by the editor greatly simplifies integration of different data types on the page for the user and allows the user to manipulate a group of object sets within a single displayable area on the page with relative ease. Moreover, formatting of the document is facilitated by the editor since the superblock is treated as an object set without taking into consideration the complexity inside the superblock structure except when a page end decision must be made.

Claims

What is claimed is:

1. In an integrated multiple data editor of the type which produces a compound document having diverse text and/or non-text objects positioned on the same page or on the preceding or succeeding page of the document, said editor manipulating object sets containing said objects wherein each object set has a data structure for its type including data which points to the previous and next object sets and each object set data structure has a unique identification used in paging data, said object sets each having objects of the same residing therein and being delineated by displayable icons indicating the object set type, the method comprising the steps of:

creating a superblock data structure by defining an internal representation of a displayable area, said representation containing two or more object set data structures for object sets positioned so that the object sets overlap one another, reside side-by-side or extend above or below one another in said displayable area, and

formatting the document by manipulating the superblock data structure as a single entity as if it were an object set data structure without taking into consideration the complexity inside the superblock data structure except when a page end decision must be made.

2. The method as recited in claim 1 wherein the step of creating a superblock data structure comprises the steps of:

selecting left and right hand margin offsets of the displayable area represented by said superblock data structure, and

delineating the displayable area represented by said superblock data structure by a single displayable icon.

3. The method as recited in claim 2 further comprising the step of placing non-text object sets so that they do not overlap text object sets within the displayable area represented by said superblock data structure.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

The invention disclosed in this application is related to the inventions disclosed in the following applications filed concurrently herewith and assigned to the assignee of this application:

Ser. No. 645,620 for IMPLICIT CREATION OF A SUPERBLOCK STRUCTURE filed by Barbara A. Barker and Irene H. Hernandez filed on Aug. 30, 1984;

Ser. No. 645,630 for EDITING OF A SUPERBLOCK STRUCTURE filed by Barbara A. Barker, Irene H. Hernandez and Rex A. McCaskill filed on Aug. 30, 1984; and

Ser. No. 645,621 for FLOW ATTRIBUTE FOR TEXT OBJECTS filed by Irene H. Hernandez, Barbara A. Barker and Beverly H. Machart filed on Aug. 30, 1984.

The disclosures of the foregoing applications are incorporated herein by reference.

BACKGROUND OF THE INVENTION

The present invention generally relates to integrated multiple data editors and, more particularly, to a super block structure containing two or more diverse object sets positioned so that the object sets overlap one another, reside side-by-side, or extend above or below one another. The object sets may be text, graphics or tables, and once created, the super block structure is treated as an object set in the formating of a document thereby simplifying the formatting algorithm of the editor.

Computers are coming into more common use tnroughout society not only because computers can perform many jobs more efficiently than prior devices or methods, but because the relative cost of computers has decreased dramatically over the past decade. At first, mainframes and then minicomputers with multiple terminals made access to computers available to many people in larger businesses. With the advent of microcomputers for both business and personal use, great numbers of people now have access to computers. The trend is for most computer users not to be computer professionals or sophisticated in data processing techniques. It has therefore been necessary to design what have come to be known in the art as user friendly computer programs to allow the unsophisticated user to perform desired tasks on a computer without extensive training. One technique that has been employed is to provide the user with a menu of choices of the particular tasks or functions which may be performed. Such a menu may take the form of a full or partial screen display with spaces adjacent the menu entries where the cursor may be placed by the use of keys on a keyboard or other cursor moving device. A selection of the desired task or function is made by placing the cursor in the space adjacent that entry and pressing the ENTER key or other key provided for that purpose. The program may be provided with a series of menus so that the user is led through progressively more complex tasks or functions in a simple and unconfusing process. Such programs are generally described as menu driven programs as distinguished from command driven programs. In the latter case, the tasks or functions to be performed by the user must be chosen and entered by a series of commands. This type of program is typical of earlier types of programs and requires some degree of sophistication and training of the user.

In addition to making programs more user friendly, the recent trend has been to provide some form of integration of computer program applications. Without integration, the user must employ separate application programs for, say, word processing, data processing, and graphing, and it is often difficult to merge the outputs of the several applications in a single document. Therefore, the purpose of program application integration is to further simplify the use of a computer to produce a desired output product. Software integration has evolved in several forms Perhaps the simplest form of integration is a series of application programs designed to work alike sharing the same files and using the same or similar commands to perform the same or similar functions. This form of integration is relatively easy to implement but does not allow the individual programs of the family to be run simultaneously. Currently, the most popular integrated software are what may be termed multiple-function programs. These are characterized as incorporating a variety of applications within one program. Such programs generally allow splitting of the screen into several different windows almost as if each were a separate program. Typically, these multiple-function programs include text, spreadsheet and business graphing applications. Somewhat similar to the multiple-function programs is the now evolving integration technique based on a database application environment wherein all applications share a common set of data. Quite a different approach is taken when an integrated operating environment is provided. In this approach, individual programs can share information and often appear on the screen at the same time, each in its own window. Applications can be chosen and combined in contrast to multiple-function programs that are limited to applications programmed into the package.

Integrated operating environments are best implemented in object-oriented systems. This is a relatively new approach in that software systems have traditionally had two components: data and procedures. The data represents the information manipulated by the software and the procedures represent a unit of the software. Actions occur when a procedure is invoked and is given some data to manipulate. The problem with this traditional approach is that the data and the procedure are treated as if they are independent when in fact they are really related. In contrast, there is only one component in an object-oriented system, i.e. the object which represents both the information and the manipulation of this information. A programmer using an object-oriented system sends a message to invoke a manipulation, instead of calling a procedure. The message includes a symbolic name which describes the manipulation but not the manipulation details. The object reciving the message determines which method to execute on the basis of the message selector. The most thorough investigation of the object-oriented approach has been done by the Xerox Learning Research Group in Palo Alto, California, which designed and implemented Smalltalk, a language very similar to tne process of human interaction. A Smalltalk programmer implements a system by describing messages to be sent and describing what happens when messages are received.

Smalltalk has been particularly advantageous in the development of software for the user of personal computers with a high-resolution display, a keyboard, a pointing device such as a mouse, and a disk storage and processor unit. A pointing cursor is used to track the current screen mouse position and allows the user to point to any displayed object. Usually, the mouse has one or more buttons, one being used for object selection and another being used for menu presentation. Such a machine was designed and developed by Xerox to facilitate the research and development of Smalltalk. This machine is the Alto computer, and several machines were donated by Xerox to Stanford and Carnegie-Mellon Universities and the Massachusets Institute of Technology to be used for research projects. The Alto was never commercially produced.

Early in 1981, Xerox introduced the 8010 Star Information System, a personal computer patterned after the Alto computer for use in offices by business professionals. The Star is a multifunction system which combines document creation with data processing, electronic filing, mailing and printing. As in the Alto, an important component of the Star computer is an all points addressable (APA) or bit-mapped display screen which makes visual communications more effective by allowing full graphics flexibility. The approach in designing the Star computer was to first establish the fundamental concepts of how the user would relate to the system and then design the software and hardware specifications. The design of the Star user interface was based on a familiar user's conceptual model, seeing/pointing as opposed to remembering/typing, what you see is what you get (WYSIWYG), a set of universal commands, consistency, simplicity, a modeless interaction and user tailorability. There are icons on the display which represent office ob3ects, such as documents, folders, file drawers, in-baskets, and out-baskets. The icons can be "opened" to enable the user to deal with the object the icon represents. Documents can be read, the contents of folders can be inspected and mail can be examined. Everyth:ng to be dealt with by the user and all actions available to the user have a visible representation on the screen so that the user never has to remember the different meanings and contexts of any key. The mechanism used to make these concepts visible is the property and option sheets. A property sheet presents all the possiole options for a particular object such as, for example, type font and size, bold, italic, underline and superscript/subscript on a text character property sheet. To select any of these options, tne user merely selects the option by pointing and pressing the appropriate button, and then to change any property on the property sheet, the user points to it and presses the appropriate button again. To prevent the user from being overwhelmed with information, property sheets display only the properties relevant to tne type of object currently selected thereby hiding complexity until it is needed. The Star computer also allows the system to be tailored to fit the individual user's needs. The user can tailor the working environment by choosing the icons for the desktop display. Blank documents can be set up with text, paragraph and page layout defaults. The filing system can be tailored by changing the sort order in file drawers and folders.

Early in 1983, Apple Computer introduced a new kind of computer called the Lisa. Lisa's designers drew heavily on the previous work done at the Xerox Palo Alto Research Center, but they also refined several borrowed concepts and combined them with many new ideas. The first task tackled by Lisa's designers was to devise a new way for users to interact with the computer. The result was an internal "User Interface Standards" document that describes how a user interacts with the Lisa system. Like the Star computer, the desktop manager for the Lisa is an icon base, but unlike the Star where the icons can be put at fixed locations on the screen so that they can never overlap, the Lisa icons can be placed anywhere. For that reason, the Lisa computer can have overlapping, arbitrarily shaped objects on the display screen. The Lisa computer depends on the metaphor that the video display is a desktop, while the icons are objects on the desktop. Everything in the Lisa system is represented on the desktop by either an icon or a rectangular area referred to as a window. All icons can be selected via the mouse, and all windows can be scrolled horizontally or vertically, expanded or contracted, and moved by holding down the mouse button and moving the cursor. The design of the Lisa system is integrated. Each of the Lisa programs has a large amount of common behavior and structure. There are no modes to restrict the user's activities at a given time. For example, the user can switch from text to spreadsheet to graphing applications just as if those applications were separate sheets of paper on the desk. Like the Xerox Alto and Star computers, the Lisa computer is based on the Smalltalk language/operating system. The technology developed for the Lisa computer has been further refined in the recently introduced Macintosh and Lisa II computers from Apple Computer.

As part of a research effort at the IBM Cambridge Scientific Center in Cambridge, Mass., to develop software techniques in the field of office systems, Sheldon Borkin and John Prager developed the personal on-line integrated text editor (POLITE). This is an easy-to-use, real-time editor and formatter for compound documents. A compound document is one containing images, draw graphics, charts, handwriting, text, tables and mathematical symbols. The philosophy of Polite is the idea that an editor should be able to handle integration of function in-line without having to invoke separate applications and without using a cut and paste buffer. The Apple Lisa and Macintosh and the Xerox Star computers are all integrated systems offering the capability to edit compound documents, but the method commonly used in those computers is to place the result of the requested function in a cut buffer and then return to the document editor to paste the result in the desired location. This is a time-consuming and tedious process. However, the inspiration for Polite was drawn from the research done at the Xerox Palo Alto Research Center, and the concepts of the Polite editor are similar to those developed for the Smalltalk programming language and further refined by the Star and Lisa computers. Since Polite is intended to have a very wide audience, the human factors of the system have been carefully considered. Some of the ease-of-use features of the system include unlimited UNDO and REDO functions, real-time formatting, use of menus, a pointing-based help system, multiple window editing, and tutorial "help-by-example". In Polite, there is no distinction between source document and formatted document. There is only one form of a document in existence, and it is always formatted and it is always printable. Thus, whenever the user makes a change, the document is automatically reformatted thereby providing immediate feedback to the user and elimating much of the guesswork that characterizes prior editors. The user sees a portion of the document on the screen along with a small menu identifying the current programmed function key definitions. On the function keys are requests (commands) which are either immediately executable or which act as a "gateway" to further menus. In these other menus, some of the function keys have other, i.e. local, definitions. The Polite system consists of two major functional components: the screen-manager and the document-manager. The document-manager contains Polite's internal representation of the document (both text and formatting information), while the screen-manager contains the displayable form of the document (the only form the user ever sees) and controls the interaction with the user. The screen-manager maintains a display-oriented WYSIWYG (what you see is what you get) representation of some subset of the document. This subset includes at least that portion of the document which fits on the screen, and possibly the whole document depending on the document size.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide improvements in integrated computer software.

It is another more specific object of the invention to provide improvements in an application composite editor which simplifies integration of different data types on a page of a document.

It is a further object of the invention to provide a multiple data editor which facilitates the manipulation of a group of diverse object sets within a single displayable area on a page of a document and simplifies the formatting procedure of the editor.

The subject invention is directed to improvements in an application composite editor which is based on the Polite system. Like Polite, the application composite editor is an easy-to-use, real-time editor formatter for compound documents containing not only text but also images, graphics, tables, annotations and handwriting. The application composite editor provides integration of all data on a single page in relation to each other in dynamic editable form. All data types can be created within the same document, and text can flow around graphics or tables. All data in the editor resides on pages and all pages reside within a composite document The user interface design for the application composite editor is based on the following ease-of-use features to make document creation and editing a quick, easily learned and straight forward process:

1. Use of key-word commands on a command bar which is always displayed at the top of the screen. The command bar lists all of the commands currently active for the type of data being edited.

2. Use of pop-down panels when a command is selected which lists a set of options which can be selected and/or modified.

3. Use of full screen windows as a mechanism for viewing and manipulating data.

4. Use of unlimited UNDO and REDO functions to allow the user to reverse previously performed functions without fear of damaging data.

5. Use of a help-by-demonstration function which allows the user to request a demonstration of how a particular command works. The editor will show the user how the command works by doing it and then undoing it.

The editor works with a page layout philosophy wherein data objects reside on the page and data resides in the data objects. All pages reside within a document object, and some data objects may have additional objects within them. Objects are data-specific entities that the user can manipulate on the page. The objects that are within other objects reside within a defined object set boundary. All objects are explicit, i.e. they are recognizable, choosable entities. Blocks are user-selected ranges of any part of the document. For example, a block can be defined as a range of cells in a column or a character string. The block object allows the user to underline characters, change fonts, or define a "keep" around a group of objects. When the user applies an attribute to the block such as underline, the underline is ignored where it has no meaning. For example, an underline of a set of graphics objects is not meaningful. All objects exist within a specified boundary on the page. This boundary is defined as an object set boundary. For example, a text character exists within the boundary of either a line object set or a paragraph object set; a rectangle exists within tne boundary of a graphic object set; and a cell exists within the boundaries of a table object set. According tc the present invention, object sets may be moved into positions on the page such that more than one object set is occupying a single displayable area on the page. Examples of this are a paragraph flowing around a graphic object set, a table object set next to a graphic object set and a graphic object set in the middle of a paragraph with text flowing above and below. Such an arrangement of objects creates a structure called a superblock.

A superblock is any displayable area containing two or more object sets positioned so tnat the object sets overlap one another, reside side-by-side or extend above or below one another. A text object set may not be overlapped by any other object set. As a result, text will always be readjusted according to its flow attribute. The purpose of the superblock structure is to simplify the calculation of the space the object sets occupy. By creating the superblock structure, the formatting algorithm does not have to take into consideration the complexity inside each object's block structure except when a page end decision must be made. Presentation of the complex relationship on the page is also simplified.

The superblock is implicitly created by the editor as the result of a user specified action. There are five actions which can cause the creation of a superblock. They are CREATE, MOVE, COPY, PASTE and GET. When the editor creates the superblock, the superblock icon is placed at the starting top boundary for the superblock. One method of selecting the superblock or of selecting one of the sets within the superblock is for the user to first select the superblock icon. A pop-down panel showing a list of the icon representations for each object set within the superblock structure is displayed, and the pop-down panel is positioned below the superblock icon and appears to the user as an extension of the icon. To select the object set within the superblock, the user selects the icon representation of the object set from the pop-down panel. Another selection method is to point at the desired object set within the superblock. An enclosing routine is then called to determine the object set selected. In cases where selection by pointing results in ambiguity, the first selection method should be used. When the user selects an object set within the superblock, the command bar changes to reflect the actions which are valid for that type of object set. Inside the superblock, the object set can be moved, copied, deleted, described, etc. The editor implicitly dissolves the superblock and replaces the superblock icon with an object set icon whenever there is only one object set remaining in the display space of the superblock. Inside the superblock, non-text object sets can overlay each other so that the data of an object set is totally hidden from view. When this occurs, the user can redefine the position of the obscured object set by selecting the object set, selecting MOVE from the command bar and then selecting a new destination for the object set. The destination can be inside the boundaries of the superblock or at some other document location. A superblock can cross page end boundaries as long as the data within the superblock can be split across pages. Although the superblock is a complex structure, the creation of this structure by the editor simplifies integration of different data types on the page for the user and allows the user to manipulate a group of object sets within a single displayable area on the page with relative ease.

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG. 1 is a sample "compound" document incorporating text, graphics and a table;

FIG. 2 illustrates the page layout philosophy of the application composite editor upon which the improvement according to the preferred embodiment of the invention is based;

FIG. 3 shows the normal object set placement in a document;

FIG. 4 illustrates a superblock according to the present invention with text flowing around a non-text object set;

FIG. 5 illustrates a superblock with no text flow around a non-text object set;

FIG. 6 is a flow diagram illustrating the process of implicitly creating a superblock structure;

FIG. 7 illustrates the manner in which a location is selected within a text object set for the insertion of another object set thereby causing the creation of a superblock;

FIG. 8 is a flow diagram illustrating the process of editing a super block;

FIGS. 9A to 9C show the case of a superblock edited via a move edit function wherein the superblock boundaries do not change;

FIGS. 10A to 10C show the case of a superblock edited via a move edit function wherein the lower boundary of the superblock has changed thereby affecting the page ending;

FIGS. 11A to 11C show the case wherein a superblock is edited via an insert edit command resulting in the superblock being split by a page end;

FIGS. 12A to 12C show the case wherein a superblock is edited via a create object action which results in the superblock overflowing the page size;

FIGS. 13A to 13F are illustrations which summarize the several possibilities of no text flow around a non-text object set and text flowing around a non-text object set;

FIGS. 14A and 14B, taken together, are a flow diagram illustrating the flow attribute for text objects;

FIGS. 15A to 15D are illustrations showing additional examples of flow;

FIG. 16 shows an object set overlay with non-text object sets creating a super block according to the subject invention;

FIG. 17 shows an object overlay creating a superblock with a text object;

FIG. 18 illustrates a superblock object DESCRIBE pop-down panel according to the invention;

FIG. 19 is a block diagram of the document object data structure linked into the document ring of the application composite editor upon which the improvement according to a preferred embodiment of the invention is based; and

FIG. 20 is a block diagram of the superblock as implemented internally by the application composite editor.

DETAILED DESCRIPTION OF THE INVENTION

The application composite editor upon which the improvement according to a preferred embodiment of the invention is based is an application that provides for the creation and modification of documents consisting of mixes of at least four different data types. The data types available are text, graphics (both free form and charts), and tables (structured spreadsheet array data and from tables). Documents containing more than one type of data are called compound documents. An example of a compound document is illustrated in FIG. 1 of the drawings. The example illustrated is a letter containing text, a vertical bar chart and tabular data. The application composite editor performs real-time WYSIWYG formatting and editing on such compound documents and is intended for use on personal computers such as the IBM PC/XT with a color graphics display. The editor is a single integrated programming application which is supported by the IBM PC disk operating system (DOS) and uses a windowing system to display and manage pop-down panels.

All data in the editor resides on pages and all pages reside within a composite document. Each paragraph within the text of the document exists as an entitiy by itself; therefore, the user can create each paragraph with its own attributes. One paragraph can be centered and double spaced, the next right adjusted and single spaced, and the following left adjusted and quadruple spaced. Each paragraph can have its own margin settings which can be different from the margins specified for the page. Moreover, paragraphs do not have to have a right and left margin that are fixed. A paragraph can be wrapped around a graph or table structure on the page. A variety of shapes are available for the user to choose from while creating graphic objects, and a variety of chart types are also available for selection. Tables can be a single cell or multiple row/multiple column tables. In the latter case, arithmetic computations within a cell are supported as in a typical spreadsheet application.

The example shown in FIG. 1 of the drawings also illustrates two application command bars at the top of the display screen. Within the command bars are command buttons which represent all the commands currently valid for the type of data being edited. The contents of these command bars change to reflect the actions which may be applied to the selected data type. A command may be selected by pointing with a pointing device, such as a mouse, and pressing an appropriate button. When a command is selected from the command bar and that command requires futher user interaction, a pop-down panel will be displayed. A specific example of the superblock object DESCRIBE pop-down panel is described hereinafter with reference to FIG. 18, but suffice it to say here that pop-down panels consist of keywords and/or value fields and/or informational text. Each pop-down panel has a QUIT button in its upper right-hand corner which, when selected by the user, causes the panel to be removed from the screen with the result that any selections made in a selection or parameter entry panel will be cancelled. Most multiple selection and parameter entry panels also have a DO button in the lower right hand corner which, when selected by the user, causes execution of the command. The pop-down panel is removed from the screen when the command is completed.

Also illustrated in FIG. 1 along the left hand margin are icons which indicate the type of data within an object set. The icons illustrated are H for heading, L for line, for paragraph, G for graphics, and T for table. The editor works with a page layout philosophy which is illustrated in FIG. 2 of the drawings. Data objects reside on the page and data resides in the data objects. All pages reside within a document object. Some data objects have additional objects within them as will be described in more detail hereinafter. Indicated in FIG. 2 are polyline, free-hand drawing and circle examples of free form graphics object sets and a pie-chart example of business graphics object sets. Objects are data-specific entities that the user can manipulate on the page. The objects that are within other objects reside within a defined object set boundary, and all objects exist within a specified boundary on the page. This boundary is defined as an object set boundary. More than one like data object may exist within a single object set. Depending on the type of data in the object set, the display space size can be constant or adjustable. For example, a paragraph is a dynamic object set; text can be added or deleted at any time. As a result, the display space of the paragraph changes to accomodate increases and decreases in data. For a graphic or table object set, the display space size is a function of the dynamic adjust attribute defined for the space and can be managed by the user. When the dynamic adjust attribute is on, the display space grows when data is added to the object set and shrinks when data is deleted. For a graphic object set, the default is dynamic adjust=ON. This means that the display space will be adjusted to fit the size of the drawing or chart. To change this default, the user points to the graphic object set icon and selects the DESCRIBE command in the command bar. The default for a table object set is dynamic adjust=OFF so that the size of the display space is constant and is equal to the minimum display space size of the table. As with the graphic object set, the user can change this default via the DESCRIBE command. If the displayable area of a graphic or table object set is constant, the data within the object may exceed the boundaries of the display space. For example, the user may have defined a table with 255 rows and 63 columns, but only 15 rows and 10 columns fit within the display space. When this occurs, the data within the object set is scrollable.

According to the invention, object sets may be moved into positions on the page such that more than one object set is occupying a single displayable area on the page. Examples of this are a paragraph flowing around a graphic object set or a table object set next to a graphic object set in the middle of a paragraph with text flowing above and below. Such an arrangement is represented by an object set structure called a super block.

The concept of object sets simplifies the user's understanding of the editor. The user is free to create and design very complex structures and does not need to be aware of the difference between object sets and other types of objects. Object sets are automatically created when the user selects the line, paragraph, graphics or table option from the CREATE command pop-down panel. Once the object set has been created, the editor automatically determines which editing rules are applicable to the data within the object set. When an object set is created, the ob3ect set is placed on the page relative to the left and right hand margin offsets specified by the user. The normal placement of object sets on the page is continuous, i.e. each object set is placed immediately after the preceding object set as shown in FIG. 3 of the drawings. The left margin of each object set is defined as an offset from the left page edge.

According to the present invention, object sets do not have to be placed on the page consecutively. For example, a graphic object set can be placed in the middle of a paragraph so that the text of the paragraph flows around the graphic object set filling in any white space that was created by the insertion of the graphic object set. An example of this is shown in FIG. 4 of the drawings. This flowing of text implies a grouping of text and graphics and creates a superblock structure. As previously defined, a superblock is any displayable area containing two or more object sets positioned so that the object sets overlap one another, are side-by-side or extend above or below one another. A text object set may not be overlapped by any other object set in the composite text editor, and as a result, text will always be readjusted according to its flow attributes. If flow is off, text is placed above and below any non-text area as shown in FIG. 5. If flow is on, text is adjusted to fill in the white space around the non-text object set as shown in FIG. 4.

FIG. 6 is a flow diagram illustrating the process of the creation of the superblock. First, the operator fetches a pointer or cursor. The operator then moves the pointer on the display screen by means of a locator device, such as a mouse, until the pointer is at the desired window location as represented by the arrow in FIG. 7. When the pointer is at the desired window location, the operator presses a button or switch on the mouse to select the location. The positioning and selecting operations are depicted by block 1 in FIG. 6.

Next, the operator selects a command to perform an action. The command can be selected by any of several methods. These include selecting a command key, a command button from a command bar or entering a command on a command line. The selection of the command is depicted by block 2 in FIG. 6. After the command has been selected, a test is performed to determine if the edit action results in data being inserted. This test is depicted by block 3. If the result of the test in block 3 is true, then the pointer location is converted to a location within the document to determine if the location is within the bounds of a previously created object set. Block 4 indicates the conversion occurring. If the location is within the bounds of another object set, then a superblock object set is created; otherwise, a normal object set is created. Block 8 depicts the creation of a superblock, and block 7 depicts the creation of a normal object set. The result of creating the superblock in block 8 is shown by either FIG. 4 or FIG. 5, whereas the result of creating a normal object set in block 7 of FIG. 6 is shown in FIG. 3. After creation of either the superblock ob3ect set or the normal object set, the newly created object set must be inserted into the document. This is indicated by block 9 in FIG. 6. If the result of the test in block 3 is false, then normal command processing follows as indicated by block 5. After all command processing is complete, the display screen is updated. This redisplay of the data is indicated by block 10.

The pseudocode for the implicit creation of a superblock is set forth below:

    ______________________________________
    ON POINTER SELECTION
    CALL QUERY LOCATION --POINTER
    SELECT EDIT ACTION
    IF EDIT ACTION = INSERT --DATA
    THEN CALL GET --DOC --LOCATION
    IF DOC --LOCATION = EXISTING OBJECT SET
    THEN CALL CREATE --SUPERBLOCK
    ELSE CALL CREATE --OBJECT --SET
    CALL INSERT --OBJECT SET
    ENDIF
    ELSE CALL NORMAL --EDIT
    ENDIF
    CALL REDISPLAY --DATA
    ______________________________________

    __________________________________________________________________________
    ON POINTER SELECTION
    CALL QUERY --LOCATION --POINTER
    CALL TRANSLATE --LOCATION
    SELECT EDIT ACTION
    CALL EXECUTE --COMMAND
    IF EDIT ACTION = CHANGE PAGE BREAK
    THEN CALL FIND --PAGE --BREAK
    IF PAGE --BREAK IS WITHIN SUPERBLOCK BOUNDARY
    THEN CALL SPLIT --SUPERBLOCK
            IF SPLIT SUPERBLOCK IS TRUE
              THEN CALL PAGINATE (PAGE,
                SPLIT)
              ELSE CALL CREATE --MESSAGE --
                RECORD
                CALL PAGINATE (PAGE,
                  KEEP)
                CALL BUILD --MESSAGE --PANEL
            ENDIF
    ELSE CALL PAGINATE (PAGE, NORMAL)
    ENDIF
    ENDIF
    CALL REDISPLAY --DATA
    __________________________________________________________________________

    __________________________________________________________________________
    TEXT --EXISTS = FALSE
                   {INIT TEXT EXISTS FLAG }
    FLOW --ON = FALSE
                   {INIT FLOW FLAG}
    REPEAT
    CALL GET --OBJECT --SET --TYPE
    IF OBJ --SET --TYPE = TEXT
    THEN TEXT --EXISTS = TRUE
    CALL TEST --FLOW --ATTRIBUTE(FLOW --ON)
    ENDIF
    UNTIL ALL OBJECT SETS IN SUPERBLOCK CHECKED OR FLOW --ON
    IF TEXT --EXISTS
    THEN IF FLOW --ON
    THEN CALL DETERMINE --NUMBER --OF --FLOW --AREAS
    ENDIF
    REPEAT
    CALL GET --OBJECT --SET --TYPE
    IF OBJ --SET --TYPE = TEXT
    THEN CALL TEST --FLOW --ATTRIBUTE(FLOW --ON)
    IF FLOW --.0.N AND NO --OF --AREAS <> .0.
                {INIT TEXT DATA FLAG}
            THEN NO --MORE --TEXT = FALSE
               REPEAT
                CALL GET --FLOW --AREA
                CALL FLOW --TEXT
                IF FLOW --TEXT SUCCESSFUL
                  THEN CALL RESTART --
                      FLOW
                    IF RESTART --FLOW
                      FAILED
                      THEN SPLIT
                      REMAINING
                      TEXT
                    ENDIF
                  ELSE
                    IF ALL TEXT
                      DATA HAS
                      BEEN FLOWED
                      THEN N.0. --MORE
                       --TEXT = TRUE
                    ENDIF
                  ENDIF
                UNTIL NO --MORE --TEXT OR
                  RESTART --FLOW HAS
                  FAILED
              ELSE CALL SPLIT --OBJECT --SET
            ENDIF
    ENDIF
    UNTIL ALL TEXT OBJECT SETS IN SUPERBLOCK PROCESSED
    ENDIF
    __________________________________________________________________________

    ______________________________________
    LIST OBJECT BEFORE EDITING
    1.       Item 1. This is item 1 which has a set of
             attributes of its own.
    2.       Item 2. This is item 2 having a different
             set of attributes.
    3.       Item 3. . . .
    4.       Item 4. . . .
    LIST OBJECT AFTER EDITING
    1.       Item 1. This is item 1 which has a set of
     2.      attributes of its own. Item 2. This item 2 having a different
             set of
                           ##STR1##
             attributes.
    3.       Item 3. . . .
    4.       Item 4. . . .
    ______________________________________

    ______________________________________
    PASCAL CODE FOR SUPERBLOCK DEFINITION
    ______________________________________
    distance = integer; {some number of generic units}
    {id for requesting editor objects from storage mgmt}
    obj --id = word;
    {pointer to object set formatting information}
    fcb --ptr =  obj --set --fcb;
    {pointer to user defined label information}
    label --ptr =  n --label;
    {pointer to Table specific object set information}
    tbl --head --ptr =  tbl --head;
    {pointer to graphics specific part of obj --set}
    g --head --ptr =  g --head;
    {pointer to text specific information in obj --set}
    txt --head --ptr =  txt --head;
    {pointer to super block specific object set info}
    sblk --head --ptr =  sblk --head;
    sblk --head =     {super block information}
    record
    first --obj --set,  {first object set in super block}
    last --obj --set : obj --set --id --ptr; {last object set}
    end;
    o --types = (
                 {types of object sets}
    {obj --set consisting of two or more obj --set types}
    superblock,
    text --obj, {a single line, a paragraph or list obj --set types}
    graph obj,   {draw or business graphics object --set}
    table --obj);
                 {spreadsheet or one --cell table obj --set}
    obj --set --ptr = {pointer to an object set}
    object --set =
    record
    prev,
    next        : obj --set --ptr;
    name        : label --ptr;
    height      : distance; {how high is the object set}
    formatted,   {is the obj --set ready for display}
    keep        : boolean; {can the obj --set be split}
    fcb         : fcb --ptr; {pointer to format info}
    id --tag    : obj --id; {unique id for object set}
    case obj --set --type
                      : o --types of
    superblock        : (s --head : sblk --head --ptr);
    graph --obj       : (g --head : g --head --ptr);
    table --obj       : (t --head : tbl --head --ptr);
    text --obj        : (text --head : txt --head --ptr);
    end;
    {An obj --set --id --ptr is a pointer to the structure containing
    the information on each object set within a super block.}
    obj --set --id --ptr =  obj --set --id;
    obj --set --id =
    record
    loc : offset; {location within the super block}
    next --obj --set : obj --set --id --ptr; {next sblk obj --set}
    {assumes left to right order}
    {ptr to obj --set associated with this id ptr}
    obj --set : obj --set --ptr;
    end;
    ______________________________________

• Inventors
  Barker, Barbara A.; McCaskill, Rex A.;
• Assignee
  International Business Machines Corp. (Armonk, NY)
• Published
  Feb-2-1988
• Current US Classes:
  715/514
• Application #
  645622
• International Classes
  G06F 015/20
• Field of Search
  364/200 354/7 354/8 354/9 400/61 400/83 340/721 340/747
• Examiner
  Harkcom; Gary V.
• Agent
  Whitham; C. Lamont, Whitham; Michael E.
• US Patent References:
  4448557
  4451900
  4539653