Method for editing spatially related data in an interactive text processing system4435778Abstract An improved text processing method is disclosed which permits spatially related data to be displayed and edited by the same method employed to display and edit conventional text type data in an interactive text processing system which includes a keyboard, a display device, and a microprocessor. Claims Having thus described our invention, what we claim as new and desire to secure by Letters Patent is: Description DESCRIPTION
______________________________________
Pat. No. Serial No. Issue Date
______________________________________
3,911,418 380,002 05/26/79
4,001,779 400,980 07/28/81
3,859,664 221,550 09/11/78
______________________________________
A comparison of the above data to the characters shown in FIG. 5 illustrates a number of basic characteristics of storage of text type data. A storage location is needed for each separate character to be displayed which corresponds to a keystroke. Generally, one keystroke will equate to one storage position, but there will be exceptions such as when one character is underlined or two conventional characters are employed to create a desired graphic, for example, a .0. or a .noteq.. Similarly, white space is sometimes stored as a blank character, a tab code, or a control code, such as a carriage return at the end of the text. In addition, the display of vertical bars (not shown above) for separation of displayed fields is desirable but requires considerable steps and time by the operator if entered in a conventional text mode. By definition, text data is not spatially related in that the distance between the start of the data and its storage location is not significant, other than from an appearance and convention standpoint. Line lengths are not stored with the data and different line lengths are usually only discernible by carriage return symbols indicating the beginning of a new line. As shown in FIG. 5, the data, while spatially related, has been entered and stored as text data without use of tab keys, which would have improved the storage efficiency to some degree. However, for purposes of explanation of the limitations of conventional text processing, now assume that the document has been drafted, which includes the above 3.times.3 matrix of data and that it is desired, after editing by the author, to add a fourth column (Filing Date) to the table and also interchange the position of the serial number column with the patent number column and sequence the list by serial number order, such that in the revised document the data might appear as follows:
______________________________________
Ser.No. Filing Date
Pat. No. Issue Date
______________________________________
221,550 05/03/77 3,859,664 09/11/78
380,002 09/15/77 3,911,418 05/26/79
400,980 06/12/78 4,001,779 07/28/81
______________________________________
It will be generally recognized by those persons familiar with text processing systems that all of the keystroke data which has been stored in memory, representing the initially entered data, is substantially worthless and that the operator, from an efficiency standpoint, would probably start and enter the data again in the order desired, rather than trying to use the stored information. If the table was large, such as 200 rows, the task might not even be contemplated. However, the data may be manipulated by the microprocessor in the desired manner quite easily when the data is encoded as vectors corresponding to the spatial relationship of the data. In these systems, when the spatially related data is stored as vector data, editing operations unique to the stored formatted data are required, as contrasted with the use of one editing process for both types of data, as contemplated by the present invention. In accordance with the present invention, the spatially related data is initially entered into an area of memory designated as the display format buffer, which is similar in function to the text storage buffer in that it supplies output data to the refresh buffer 12 for display. The format of the data stored in the display format buffer 29 of FIG. 3 is exactly the same as the format of the text data stored in the text storage buffer 27. The display format buffer is contained within the section of memory referred to generally as the Horizontal Display Control Block (HDBC). The HDBC is fixed between address positions in memory and, in practice, may be approximately 6,000 storage positions of the memory. The display format buffer 29, on the other hand, is variable in size, and its beginning position is fixed at a point in memory near the beginning of the HDCB. The bottom section of the HDCB contains the display data area for storing the data in vector format. The end of the display data area is fixed, while the starting point varies as the length of the stored vectors. This permits a "free space" between the display format buffer and the display data area which is employed in modifying the data in either area, e.g., lengthening or shortening the data. As will be explained in detail later on in the specification, the entry of spatial data into the system is similar to the entry of text data except that the operator is presented with the header information on the screen. As a line of spatial data is entered, it is displayed to the operator from the display format buffer 29. However, at some subsequent time, the entered data is encoded in a vector format and stored in the display data area 28. The display format buffer 29, therefore, merely functions to provide to the display device some predetermined "slice" of all of the spatially related data stored in vector format in the display data area 28. FIG. 6 illustrates the vector format employed for storing the data in the display data area. Each line or row of the matrix comprises a row vector and a plurality of column vectors. The row vector comprises four bytes designated LLTR, respectively, where byte positions 0 and 1, i.e., LL, store the total number of bytes on the line (including the four bytes of the vector description), byte position 2, i.e., T, indicates the type of line and, in this example, will be considered always to be 0. Byte position 3, i.e., R, is the row number, which permits a table of 255 rows. The data in each column is also encoded as a vector having the format 11tc where 11 is two byte positions specifying the length of the data in number of characters which are in the column, including the four byte representation 11tc. "t" is a 1-byte designation of the type of data in the column which, in the present example, will be either 1 or 0. A zero indication signifies that the data portion of the vector is actual data. A one indication in the type byte indicates that the data portion of the vector is a 6-byte pointer, 4 bytes of which designate a location in memory where the data is stored, and the last two bytes indicate the length of that stored data. The last byte of the column vector, c, is the column number, thereby permitting a table having 255 columns. At the point in the preparation of the document where the table is to be created, the operator notifies the system by placing the system in a query-response mode, where one option presented to the operator is to "Create a File." After selecting this option and assigning a name to the file, the system prompts the operator for defined parameters of the file by column or field, such as the name of the column or field, the type of data to be placed in the column, and the width of each column. The information entered by the operator is stored in memory as a table similar to that shown in FIG. 7. After all the parameters have been defined, the header data is displayed to the operator to assist in the entry of the records into the file. In order to display the header data, a header vector is created from the table as shown in FIG. 7 and stored in the display data area. The header data is transferred to the display format buffer 29 in decoded form as conventional text stream data and then to the refresh buffer 12, from which it is displayed. The header row vector for the present example is reproduced below, where the first column represents the vector name, the second column the byte location or address in memory where the vector is stored, the third column the vector byte designation stored at that location, the fourth column the actual data character, and the last column comments relating to the byte of data stored at that location.
______________________________________
1 2 3 4 5
______________________________________
VR0 0 L 4 Number of
1 L 4 bytes in
2 T Zero row
3 R Zero Type
Row Number
4 1 1 Number of
5 1 0 bytes in
6 t 1 column VC0
7 c 0 Type
8 P0 X Column
9 P1 X number
10 P2 X 4-byte
11 P3 X pointer to
12 P4 Y memory
13 P5 Y location
where title
is stored
2-byte
pointer
for length
VC1 14 1 1 Same
15 1 0 format
16 t 1
17 c 1
18 P0 X
19 P1 X
20 P2 X
21 P3 X
22 P4 Y
23 P5 Y
VC2 24 1 1 Same
25 1 0 format
26 t 1
27 c 2
28 P0 X
29 P1 X
30 P2 X
31 P3 X
32 P4 Y
33 P5 Y
VC3 34 1 1 Same
35 1 0 format
36 t 1
37 c 3
38 P0 X
39 P1 X
40 P2 X
41 P3 X
42 P4 Y
43 P5 Y
VR1 44 L 5 Next
45 L 8 row
______________________________________
As the data for row 1 is entered in the appropriate field by the operator, it is transferred to the display format buffer 29 before it is encoded, or it may be encoded column by column as it is entered. In the preferred embodiment of the present invention, the operator, after keying in the last character of the data for a column, moves the cursor to the first character position of the next column by depressing a specified cursor move key. The system recognizes this signal and encodes the data just entered for that column as a column vector at that time. The encoding process is, thus, done on a column by column basis in the preferred embodiment. In this regard, the data for the line length is accumulated at the end of encoding each column. The two bytes of data stored at LL, therefore, represent the running total of the number of byte positions involved in the columns encoded to that point in the encoding process. The encoding operation is achieved by programming the microprocessor to convert text to vector formatted data. The number of row vectors normally maintained in the display data area of memory at any time is dependent on the size of the memory. The remaining portion of the file, e.g., the rows above and below the rows being displayed, is stored either in another section of memory or, preferably, on the diskette in a compressed vector format in which the vector portion only includes the field length, but does not include type or column number parameters. FIG. 8 illustrates the format for storing data on the diskette. It will be appreciated by those persons familiar with the storage of text type data in interactive systems that to find a given line of text, each preceding line of text must be scanned, since the text data stream does not involve positional type data. Therefore, in most text systems, a number of lines are displayed, and they can generally be scrolled forward or backward by the operator until the desired line is found. To find one row of spatially related data, where the row may contain up to 100 columns or 1000 actual data byte positions, by scrolling vertically or horizontally would be very time consuming. However, this becomes unnecessary since each row vector LL indicates the beginning position of the next row and each column vector indicates the beginning position of the next column. Thus, if it is desired to display row 10, column 3, it is a relatively simple matter for the microprocessor to find the position in memory of the beginning of row 10. All that is required is to access the LL character positions for row 0 which is in the base position. The beginning of row 1 will be located at the position LL of row 0. Likewise, the beginning of row 2 will be at position in memory LL0+LL1 relative to the base. The microprocessor need only reference memory 9 times to find the 10th line, which is a rather trivial task compared to the searching required in a text data stream. Thus, it will be seen that the vector format, in addition to permitting a decrease in storage requirements relative to some text storage arrangements, provides a considerable improvement in response time when the operator desires to display a selected segment or row of spatially related data in order to check or edit that data. As mentioned earlier, the system is arranged so that both conventional text data and spatially related data are edited by the same process which involves or comprises a prescribed set of operator interactions with the screen and the keyboard. The set of interactions will depend on the specific editing functions, i.e., "delete", "insert", "move", etc., and also on how that particular function has been implemented on the particular text processing system. In some prior art systems, for example, a "move" edit function involves a series of prompts which the operator responds to, while, in other prior art systems, the operator must indicate by cursor control keys controlling the movement of the cursor what is to be moved and to what destination. The term "prescribed set of operator interactions with the screen and keyboard" refers to the sequence of microsteps which occur involving either an action of a human operator followed by a corresponding reaction of a machine operations and vice versa for the edit function to be accomplished. Assume, for example, that after review by the author, the data in the 3-row by 3-column table entered earlier was to be changed so that it would appear as follows:
______________________________________
Pat. No. Ser. No Issue Date
______________________________________
3911418 S.N. 380,002
05-26-79
4001779 S.N. 400,980
07-28-81
3859664 S.N. 221,550
09-11-78
______________________________________
The differences in the tables are that the commas have been deleted in the patent numbers in column 1. In column 2, the letters "S.N." have been added prior to the six-digit number. In column 3, the "/" character separating the month, day and year digits has been changed to a "-" character. In practice, the operator would place the machine in the document update mode, where the header and row 1 would be displayed. The data for row 1 which was stored in the diskette is brought into the display data area where the compact format is expanded to the vector format. The vector format is then decoded by the microprocessor to place conventional text data in the display format buffer, as previously explained. The various detailed steps which occur in editing row 1 are exactly the same steps the operator would follow if the display data was a line of text. For example, the operator would move the cursor to the character 9 following the comma between the "3" and the "9" digits and then key an error correct backspace which would erase from memory the comma. In column 2, labelled "Serial No.", the 6-digit number is moved four spaces to the right automatically when the operator places the cursor on the first digit of the 6-digit number and keys S.N. The substitution of the dash or hyphen character for the slash character in column 3 is achieved by positioning the cursor one character position to the right of the hyphen, hitting the error correct backspace key, and then entering the hyphen. The data as edited (changed) in the display format buffer is again encoded as vector data and transferred to the display data area. From there, it is transferred back to the diskette in compact vector format, and another row of data is processed. Successive rows are then processed in a manner similar to that just described. The following flow chart summarizes the operations of the system described above involving the process of editing conventional text type data and spatially related text type data. ##STR1## In practice, there is a finite number of specific editing procedures which are embodied in text processing systems. Those persons familiar with programming these systems, recognize the amount of programming involved in cursor control, that is, insuring that the spatial position of the cursor on the display screen is translated to the same precise contextual position in memory. Also, considerable programming is involved to interpret specific character keystrokes, control keystrokes, and cursor movement keystrokes to insure the proper system response in displaying the data and adjusting cursor position, both on the display screen and in memory. Lastly, considerable programming is required during editing to insure that space is available in memory to store any data that is entered which involves moving data presently in the memory. Likewise, when data is deleted in an editing operation, its location in storage must be filled by moving the remaining data into the vacant area. The advantages of using one process for editing both types of stored data, therefore, becomes readily apparent when the above factors are taken into consideration. The procedures required to decode the spatially related data to text data to permit editing are relatively simple and involve considerably less storage space than might be required for another set of editing programs which would be unique to vector stored data. The conversion process is also transparent to the operator and, hence, the operator is required to learn only one set of interactive steps to edit data, regardless of whether it is conventional text data or spatially related data. The chances of error, are, therefore reduced and processing efficiency is increased. While the invention has been particularly described with reference to a preferred embodiment thereof, it will be understood by those skilled in the art that various other changes in the form and details may be made therein without departing from the spirit and scope of the invention.
|
Same subclass Same class Consider this |
||||||||||