US 5,070,478 AGrant
Modifying Text Data to Change Features in a Region of Text
Issue Date:1991-12-03
•47 Claims
•11 Drawing Sheets
Abstract
A text editing system performs operations that result in text with correct punctuation at textual type boundaries. The system's processor executes a text editor, calling punctuator functions to provide appropriate fix-up data defining a sequence of operations to correct textual type punctuational structure. Fix-up data can be provided after a conventional manipulation operation, such as cut or paste in the cut-copy-paste paradigm, copy or move in the copy-move paradigm, or delete, in which case the defined sequence of operations corrects punctuational errors resulting from the manipulation operation. Fix-up data can also be provided to implement a higher level editing operation, such as changing the textual type of a textual type boundary. The punctuator provides appropriate fix-up data based on the operation currently being performed and on previously obtained data about the current selection. The fix-up data include a starting point, a number of codes to delete, a number to insert, a list of codes to insert, a position to change capitalization, and how to change it. If the current selection is a text unit, the textual types and lengths of the textual type boundaries at each of its ends are used to obtain appropriate fix-up data. To enable the punctuator to obtain data about the current selection in advance of an operation that requires fixed-up data, the text editor also calls the punctuator to handle requests to change the current selection. The punctuator does so and returns the end points of the new selection to the text editor.
Metadata
Assignee
- Xerox Corporation
Inventor
- Curtis Abbott
Application Information
Application Number:US 2742616
Filing Date:1988-11-21
Priority Date:1988-11-21
Art Unit:232
Classifications
IPC:
G06F 15401G06F 1538
Field of Search:
364419;200 MS FIle;900 MS File
Patent Drawings (11 sheets)
Description
Background of the Invention
The present invention relates to data processing techniques for editing natural language text. More specifically, the invention relates to editing techniques that take punctuation into account.
A number of conventional techniques relating to punctuation of natural language text are discussed in copending, coassigned U.S. patent application Ser. No. 07/274,158 filed Nov. 21, 1988, entitled "Processing Natural Language Text Using Autonomous Punctuational Structure" ("the Trollope application"), and incorporated herein by reference.
Text Editing, VP Series Reference Library, Version 1.0, Xerox Corporation, 1985, pp. 47-56, describes features of the ViewPoint Document Document Editor available from Xerox Corporation. Pages 49-52 described the multiple clicking method of selection, in which the number of mouse button clicks indicates the desired unit of text, with one click selecting a character, two clicks selecting a word, three clicks selecting a sentence, and four clicks selecting a paragraph. The editor uses special rules to interpret text as words or sentences. As described at page 49, a selection of a character, word, sentence, or paragraph by the multiple clicking method clicking method can be extended by a select adjust method to includes additional characters, words, sentences, or paragraphs, respectively. Move, copy, and delete operations can be applied to the selection. In the case of move or copy operations, a selection by the multiple clicking method will be positioned between other text units of the same level, so that a word will be positioned between words, a sentence between sentences, and a paragraph between paragraphs. A selection by the multiple clicking method also includes the preceding or following space or spaces; therefore, a word can be moved or deleted from a sentence, for example, leaving the remaining words and punctuation marks in the sentence correctly spaced; similarly, a sentence can be moved or deleted from a paragraph, leaving the remaining sentences in the paragraph correctly spaced.
Various other commercial products have features similar to those of ViewPoint, including selection commands from the keyboard or with a mouse or similar pointer control device. Conventionally, a single click with a pointer control device button selects a region that starts at the character boundary nearest the position of the pointer at the time of the click. In one approach, the region selected by a single click contains no characters, but may be extended one character at a time by moving the pointer over the characters to be added. In another approach, the region selected by a single click contains one character, and may be extended arbitrarily by a single click of a different button with the pointer at the desired ending point of the selection.
It is also conventional to provide selection by double-clicking, or clicking twice in succession with the pointer at the same position. Double-clicking usually selects the word most closely surrounding the pointer position, and subsequent adjustments of the selection are usually made a word at a time. For example, the MacIntosh personal computer from Apple Corporation provides a user interface in which multiple clicking selects a word. Word, a commercial text editor from Microsoft Corporation, provides extension of such a selection to additional full words. Microsoft Word and other text editors, including WordPerfect from WordPerfect Corporation and Emacs available with source code from Free Software Foundation, Cambridge, Mass., allow selection of a sentence and extension of such a selection to additional full sentences. Microsoft Word and Fullwrite Professional from Ashton-Tate Corporation further allow selection by paragraph. Fullwrite Professional also allows the user to provide a quotation mark without indicating whether it is at the open or close of a quote, the software correctly providing an open or close quotation mark based on previous marks.
Text Editing and Processing, Symbolics, Inc., #999020, July 1986, pp. 24-31 and 63-111, describes text editing features of a version of Emacs called "Zmacs." Pages 67-70 describe mouse operations, including clicking on a word to copy the whole word; on a parenthesis to copy it, its matching parenthesis, and the text between them; on a quotation mark to copy it, its matching quotation mark, and the text between them; or after or before a line to copy the whole line. Appropriate spaces are placed before inserted objects, so that spaces are automatically inserted around an inserted word or sentence. Pages 71-75 describe motion commands, including motion by word, meaning a string of alphanumeric characters; by sentence, ending with a question mark, period, or exclamation point that is followed by a newline or by a space and a newline or another space, with any number of closing characters between the sentence ending punctuation and the white space that follows; and by line, delimited by a newline. Page 79 describes motion by paragraph, delimited by a newline followed by blanks, a blank line, or a page character alone on a line; page 80 describes motion by page, delimited by a page character. Chapter 5, pages 83-97, describes deleting and transposing text, with pages 97-89 describing how contents of a history are retrieved. Chapter 6, pages 99-111, describes working with regions, and discusses point and mark.
Kucera et al., U.S. Pat. No. 4,773,009, describe a text analyzer that analyzes strings of digitally coded text to determine paragraph and sentence boundaries. As shown and described in relation to FIGS. 3-4, each string is broken down into component words. Possible abbreviations are identified and checked against a table of common abbreviations to identify abbreviations that cannot end a sentence. End punctuation and the following string are analyzed to identify the terminal word of a sentence. When sentence boundaries have been determined, a grammar checker, punctuation analyzer, readability analyzer, or other higher-level text processing can be applied.
Summary of the Invention
The present invention provides text processing techniques that use information about punctuational structure of a text to provide improved text processing. For example, an editor according to the invention can provide fix-up data defining a sequence of operations that automatically corrects the textual type punctuational structure after a user manipulates the text. Furthermore, the editor can provide fix-up data defining a sequence of operations that implements a higher level operation that improves text processing efficiency.
The Trollope application incorporated herein by reference describes a well-known problem in conventional text editors. After an operation that manipulates a text, the user must typically go over the text to correct numerous punctuational features, including punctuation marks, capitalization, and spacing. For example, moving a word to or from the beginning or end of a sentence can leave the sentence incorrectly punctuated, with incorrect capitalization and spacing. The Trollope application avoids this problem by providing a data structure that includes text data corresponding to the text, with structure data indicating an autonomous punctuational structure of the text. This punctuational structure is autonomous in the sense that it defines the distribution of one or more punctuational features in the text and the dependencies between them without reference to the lexical content of the text. With such a data structure, it is easier to ensure that operations on a text lead from one correct textual type punctuational structure to another. Each operation is performed in a way that maintains the data structure so that the system can supply correct punctuation for the text, such as by algorithmically deriving a character sequence for display from the data structure.
One aspect of the present invention is based on the recognition of problems with the techniques proposed in the Trollope application. The creation, use, and maintenance of a text data structure with structure data indicating an autonomous punctuational structure consumes substantial time and memory, so that the Trollope application techniques are computationally inefficient. Also, the Trollope application techniques, as implemented, limit the available operations to those that correspond to the data structure, so that the user is precluded from simply selecting and manipulating text characters directly as can be done with conventional commercially popular text editors for natural language text. Furthermore, the Trollope application techniques have been implemented with an underlying structure-based editor, SEdit, that is specifically designed to handle data structures resembling those required for the Trollope application techniques. SEdit is fundamentally different than the commercially popular text editors in this respect; the commercially popular text editors cannot be easily extended to include the Trollope application techniques because they do not handle this kind of data structure. Therefore, a user of one of the commercially popular text editors cannot benefit from the Trollope application techniques, but rather must continue to correct numerous punctuational features after manipulating text.
This aspect of the invention is based on the recognition that text can be analyzed into text units, each of which has a specific textual type, such that all punctuational features occur at boundaries between such text units. This aspect is based on the further discovery that errors in punctuation can be analyzed into two fundamental kinds of errors--errors in positioning textual type boundaries and erroneous combinations of punctuational features at textual type boundaries. The second kind of errors, referred to as errors in textual type punctuational structure, can be corrected by performing, after a manipulation operation, a sequence of operations that result in a text with correct textual type punctuational structure, meaning that the punctuational features at each textual type boundary are appropriate to that boundary. In other words, the correcting sequence of operations modifies text data corresponding to a text so that the modified text data corresponds to a modified text that has a correct textual type punctuational structure.
This aspect of the invention is further based on the recognition that a sequence of operations that leads to a correct textual type punctuational structure can be performed with a conventional commercially popular text editor. The text editor can serve as host for a punctuator that includes functions that can be called by the host editor to determine appropriate sequences of operations, which the host editor then performs. The host editor and the punctuator together provide approximately the effect of the Trollope application techniques without the disadvantages set forth above.
Another aspect of the invention is based on the recognition of problems in determining an appropriate sequence of operations leading to correct textual type punctuational structure. A conventional text editor does not provide data explicitly identifying such a sequence of operations. On the other hand, the sequence of operations should be determined without substantially modifying the host editor.
This aspect of the invention is based on the further recognition that the sequence of operations can be determined in parallel with the normal operations of the host editor. This recognition is in turn based on an analysis of the operation of conventional text editors and the discovery that most editors can readily provide data at certain stages of their normal operations on the basis of which an appropriate sequence of operations to correct textual type punctuational structure can be obtained.
A conventional display-based text editor typically includes a keyboard to receive a sequence of codes corresponding to text written by a user and a display to present a text corresponding to previously received text codes to a user for reading. The text editor automatically handles such matters as line breaking, interline and interparagraph spacing, margins, and paragraph indentation, so that the text presented on the display closely approximates the appearance the same text would have a printed page. The user is then able to use the keyboard, and typically a pointer control device such as a mouse, to request revisions to the text.
In a conventional text editor, the user can typically make revisions by requesting operations that fall into two important classes. One class, selection operations, includes those operations by which the user can single out some part of the text, called the "current selection" or simply the "selection, " to become the argument of a subsequent operation. Another class, manipulation operations, includes those operations by which the user can modify the text. The manipulation operations available in a given text editor are typically based on one of two paradigms--cut-copy-paste or move-copy.
In manipulation according to the cut-copy-paste paradigm, there are three basic operations: a copy operation places a copy of the text codes corresponding to the current selection in a temporary data structure, typically called the "cut buffer"; a cut operation performs a copy operation followed by a deletion of the current selection from the text; and a paste operation replaces the current selection with the contents of the cut buffer. In manipulation according to the move-copy paradigm, there are two selections, referred to herein as the "primary selection" and the "secondary selection," and two basic operations: a copy operation positions a copy of the primary selection at the location of the secondary selection; and a move operation performs a copy operation followed by a deletion of the primary selection from its original position. Both paradigms also include an independent delete operation which deletes the current selection or the primary selection without reference to a cut buffer or a secondary selection.
This aspect of the present invention assumes that the host editor uses a conventional text data structure that includes a sequence of codes, including codes for characters, punctuation marks, capitalization, and spaces. This aspect provides techniques by which a host editor that uses such a data structure or a variant of it can be extended with relatively minor modifications. Those techniques include providing punctuator functions each of which is a set of instructions that obtains data from the host editor and uses that data to determine a sequence of operations that would lead to a modified text with a correct textual type punctuational structure. The host editor includes functions each of which is a set of instructions that calls a punctuator function to obtain a sequence of operations and then performs the sequence of operations using conventional host editor operations.
This aspect is further based on the discovery of techniques for obtaining the information necessary for a punctuator function to determine an appropriate sequence of operations. This information can be obtained from the host editor when it completes one of its basic manipulation operations, whether a move or copy operation in the move-copy paradigm or a cut, copy, or paste operation in the cut-copy-paste paradigm, and when it completes an operation making a change to the selection, whether the primary or secondary selection in the move-copy paradigm or the contents of the cut buffer in the cut-copy-paste paradigm. Whenever the host editor receives a request to modify the selection, for example, a host editor function can call a punctuator function, which then provides requests to the host editor in response to which the host editor provides relevant information. The information obtained at this time may include, for example, text codes in the region of each end of the current selection, which the punctuator function can use to find the ends of a new selection. Also, whenever the host editor completes one of its basic manipulation operations, it can call a punctuator function, which can, if the text data has been modified, determine an appropriate sequence of operations based on which of the basic manipulation operations was performed and on the textual type boundaries of the selection on which it was performed.
This aspect is further based on the recognition of a fundamental problem in determining an appropriate sequence of operations. The selection and manipulation operations of the host editor conventionally do not depend on whether the text data corresponds to a text that has a correct textual type punctuational structure. The text codes that indicate punctuational features such as punctuation marks, spaces, and capitalization are conventionally treated like other codes in the sequence of text data, making the host editor blind to the textual type punctuational structure of the text that is indicated by those codes. The host editor does not provide data directly identifying the appropriate sequence of operations.
This problem is especially important in correcting textual type punctuational structure because a given sequence of text codes indicating punctuational features may be correct in some situations and incorrect in others, so that it is not possible to determine whether it must be corrected without additional information. Furthermore, an incorrect sequence of text codes may arise in more than one way, so that a decision about how it should be corrected will require additional information. Therefore, it is necessary to obtain additional information from the host editor in order to be able to determine an appropriate sequence of operations in each of these situations.
The invention solves this problem through punctuator functions that identify certain features of the textual type punctuational structure of a selection using a grammar of textual types; data relating to these features is subsequently used to determine an appropriate sequence of operations to correct textual type punctuational structure. The use of a grammar of textual types in relation to punctuational structure is discussed in greater detail in the Trollope application incorporated herein be reference. In the present invention, the punctuator functions can infer the textual type punctuational structure of the text in the region of each end of a selection based on a grammar of textual types applied to the text codes from those regions. For example, a punctuator function can tokenize the text codes, and then identify textual type boundaries by matching the token stream against a predefined set of token patterns derived from the grammar of textual types.
By identifying textual type boundaries, the punctuator can determine where a new selection's end points should be and obtain other data relating to the new selection to permit a subsequent function to determine an appropriate sequence of operations to correct textual type punctuational structure; it can then store that data, and provide data to the host editor defining the end points of the new selection within the text data structure. The host editor then conforms its selection to those end points and continues its conventional operations. Meanwhile, the punctuator keeps its own data relating to the current selection, including its end points, but also including additional data about textual type boundaries at its ends.
Once an appropriate sequence of operations to provide a correct textual type punctuational structure has been identified, another basic problem arises: It is necessary to provide data defining that operation, called fix-up data, to the host editor in a way that does not necessitate major modifications of the host editor.
The invention solves this problem based on the discovery that a relatively small set of fix-up data can be used to define a sequence of operations that can be performed with conventional host editor functions. The host editor can provide a data structure into which the punctuator loads the fix-up data. The host editor can then perform the sequence of operations based on the fix-up data in the data structure. The fix-up data can, for example, include data defining a starting point within the text data, a number of text codes within the text data to delete, a number of text codes to insert, a list of text codes to be inserted, a position within the text data to change capitalization, and how to change capitalization at the position. The punctuator is able to provide this data based on the data based on the data previously obtained in relation to the selection and also based on which of the manipulation operations was performed by the host editor. Even though the number of possible sequences of operations is large, one or more sets of fix-up data can be used to define any such sequence.
One strength of this technique is that it provides selection operations that act on textual types of the sort described in the Trollope application, identifying selection end points based on textual type boundaries. Another strength is that it provides, for manipulation operations from either the move-copy paradigm or the cut-copy-paste paradigm, automatic correction of punctuational features in the text affected by the operation.
Another aspect of the invention is based on the recognition of another problem in conventional text editing. Conventionally, text editing operations are limited to low level operations such as move, copy, and delete, or cut, copy, and paste which, as noted above, typically require the user to perform a number of corrective operations to complete an editing operation.
This aspect is based on the further recognition that this problem can be solved in part by providing higher level text manipulation operations that modify text codes at selected textual type boundaries within text data. These operations do not require corrective operations and they can use information about a selection obtained with the techniques described above. One such higher level operation is to change textual type of a part of a text. The part can be a unit of text, in which case the punctuational features, including punctuation marks, spaces, and capitalization, at the boundaries of the text unit are changed to those appropriate to the new textual type. The part could also be an insertion point in a textual type boundary, in which case the punctuational features in the textual type boundary are changed to those appropriate to a boundary of that textual type.
This aspect is based on the further recognition that such higher level operations can be provided through a mechanism like that for the operations that correct textual type punctuational structure. When the host editor receives a request for a higher level operation, it calls a punctuator function to obtain fix-up data defining a sequence of operations equivalent to the requested operation. When the punctuator function returns the fix-up data, the host editor performs the sequence of operations to complete the requested operation.
The following description, the drawings and the claims further set forth these and other objects, features and advantages of the invention.
Brief Description of the Drawings
FIG. 1 is a flow chart with parallel text frames showing general steps in a manipulation operation according to the invention.
FIG. 2 is a schematic block diagram showing components of a system that includes a host editor and a punctuator according to the invention.
FIG. 3 is a flow chart showing general steps in a selection operation performed by a system like that in FIG. 2.
FIG. 4 is a flow chart showing general steps in a manipulation operation or other operation involving fix-up data, performed by a system like that in FIG. 2.
FIG. 5 is a flow chart showing host editor steps in modifying a selection.
FIG. 6 is a flow chart showing host editor steps in performing a sequence of operations defined by fix-up data.
FIG. 7 is a flow chart showing steps in retrieving text codes from a host editor's text data structure.
FIG. 8 is a flow chart showing steps in searching the host editor's text data structure for a text code.
FIG. 9 is a flow chart showing steps in scanning text codes to find a token boundary.
FIG. 10 is a flow chart showing general steps in a punctuator selection operation.
FIG. 11 is a schematic representation of a sequence of textual type codes that include a textual type boundary.
FIG. 12 is a schematic representation of a sequence of text codes, showing features of textual type boundaries as determined between adjacent text codes.
FIG. 13 is a sequence of schematic representations of text code sequences, illustrating a change in textual type of the textual type boundaries at the ends of a text unit selection.
FIG. 14 is a sequence of schematic representations of text code sequences, illustrating a change in textual type of a textual type boundary that includes an insertion point.
Detailed Description
1. Glossary
As used herein, the following terms have the meanings indicated: "Text" means an arrangement of written words, ordinarily a sequence. "Written words" means words recorded in the form of discrete elements such as characters, codes or the like. Words recorded in a continuous form such as recorded continuous speech are therefore not written words. A text may thus includes zero or more words, each with at least one discrete element.
"Natural language text" means a text of one of the natural languages, such as English.
A "unit of text" or a "text unit" is a unit into which text can be divided.
A "textual type" is a category of units of text that has syntatic or semantic significance, but not lexical significance, as explained more fully in the Trollope application, incorporated herein by reference. A single token or instance of a textual type is referred to herein as a "textual type unit," to distinguish from more complex units of text that include, for example, a series of textual type units.
A "textual type rule" is a rule whose applicability depends on textual type. In other words, if a text is divided into textual type units, a textual type rule will apply to those units that are instances of certain textual types but not to units of other types.
A "grammar of textual types" is a set of textual types rules in which each rule indicates, for a respective textual type, textual types of textual type units into which a textual type unit of the respective textual type can be divided. In addition, a "grammar of textual types" defines all and only the acceptable divisions of textual type units.
A "punctuational feature" of a text is a feature that relates to one or more textual type units and that depends on the syntatic or semantic significance of the related textual type units. For example, a punctuational feature may indicate a grouping a textual type units, a nesting of one textual type unit within another, a separation between textual type units, a delimiting of a textual type unit, or a highlighting or other emphasis of a textual type unit. Features ordinarily used as punctuational features in English include nonalphanumeric typographical features such as spaces and punctuation marks, including commas, periods, semicolons, colons, dashes, quotation marks, parentheses, brackets, underlining, and so forth; features of alphanumeric elements such as case or font; and features of format such as carriage returns, tabs, centering, and indentation.
A "punctuational structure" of a text is a structure that includes punctuational features of the text. Text, as conventionally presented for viewing and editing, is based on a data structure that includes data indicating punctuational structure, such as character codes indicating punctuation marks, spaces, or capitalization. The text data structure may correspond to text that has an incorrect punctuational structure, in which case the text is incorrectly punctuated. As noted above, errors in punctuation can be analyzed into errors in positioning textual type boundaries and errors in the combination of punctuational features that occurs at a textual type boundary. For example, sentence (1) below illustrates a boundary positioning error, because it is inappropriate to end a phrase after the work "dog" in this particular sentence; sentence (2) illustrates a punctuational feature error, because it is inappropriate to include a comma and a space before the period at the end of a sentence, even if a phrase also ends at that boundary; and sentence (3) illustrates both types of errors in a single sentence, because it is inappropriate to end a clause after the word "dog" and because it is inappropriate to include a command and a space before the semicolon at the end of a clause, even if a phrase also ends at that boundary.
(2) The dog, bit the man.
(2) The dog bit the man,.
(3) The dog,; bit the man.
An error of the second kind, illustrated in sentences (2) and (3), is referred to herein as an error in "textual type punctuational structure " because it can be identified by applying textual type rules to a text. A text with no such errors is described as having a "correct textual type punctuational structure." The present invention can correct textual type punctuation errors. As illustrated by sentence (1), however, a text may have a correct textual type punctuational structure and still be incorrectly punctuated.
In a data structure, "text data" means data corresponding to a natural language text. Text data are often encoded using standard printing or display codes that include character codes such as alphanumeric and punctuation mark codes, capitalization codes, carriage-control codes, and so forth, collectively referred to herein as "text codes." Text data can, however, be encoded in a wide variety of other ways. For example, text data can be encoded as a bitmap.
In a data structure that includes text data made up of text codes, the term "punctuational codes" means text codes used by a system to indicate punctuational features of the natural language text represented by the text data. Punctuational codes typically include text codes indicating punctuation marks, spaces, and capitalization.
A "word unit" is a sequence of text codes that has lexical significance and that, for purposes of a given system, is not divisible into smaller sequences based on punctuational codes. A word unit is thus an atomic lexical unit, and a text code within a word unit is referred to herein as a "character code" even though it may also be a punctuational code. A punctuational code within a word unit may or may not indicate a punctuational feature. A punctuational code indicating a capitalized letter at the beginning of a sentence indicates a punctuational feature, for example, while a punctuational code indicating a capitalized letter at the beginning of a proper noun does not.
A "textual type boundary" is a sequence of one or more punctuational codes that is between word units and delimits a specific textual type in text data that corresponds to text with a correct punctuational structure. A textual type boundary is sometimes referred to herein by textual type, such as "word boundary," "phrase boundary," "sentence boundary," and so forth.
A "natural boundary" occurs at each end of each word unit in text data. A natural boundary may include a textual type boundary or it may include no punctuational codes. A natural boundary with no punctuational codes may nonetheless delimit a specific textual type, and a such natural boundaries are sometimes referred to herein as empty natural boundaries of a specified type. For example, empty natural boundaries of type paragraph typically occur at the beginning and end of a document.
A "manipulation operation" on text data corresponding to a text is an operation that modifies the text data so that it corresponds to a modified text. A manipulation operation is typically specified in terms of an argument, which is a part of the text, and an operation on that argument, such as move, copy, cut, paste, or delete. A "selection operation" is an operation relating to the part of the text that can subsequently serve as an argument for a manipulation operation.
"Fix-up data" is data defining a sequence of one or more manipulation operations that would modify text data corresponding to a text so that the modified text data corresponds to a modified text having a correct textual type punctuational structure. The manipulation operations defined by fix-up data can be performed on text data corresponding to text that has an incorrect textual type punctuational structure or on text data corresponding to text that has a correct textual type punctuational structure--in either case, the result will have a correct textual type punctuational structure.
2. General Features
FIGS. 1-4 illustrate several general features of the invention. FIG. 1 is a flow chart showing general steps in manipulating text and providing fix-up data. FIG. 2 shows the components of a system that includes a host editor and a punctuator for implementing the steps in FIG. 1. FIG. 3 shows general steps in a selection operation using the system of FIG. 2. FIG. 4 shows general steps in a manipulation operation or other operation that includes providing fix-up data, again using the system of FIG. 2.
The steps in FIG. begin when a data processor receives a request for a manipulation operation, in box 10. As shown in text frame 12, this request includes a primary selection, indicated by shaded area 14; the depression of copy button 16; and a second selection of a position, indicated by pointer 18. Therefore, text frame 12 illustrates the move-copy paradigm of text manipulation, although the invention is equally applicable to the cut-copy-paste paradigm, as discussed above.
After receiving the request in box 10, the data processor manipulates the text data corresponding to the text in text frame 12, in box 20, to obtain manipulated text data corresponding to the text shown in text frame 22. The words "To be" and the spaces after each of the words, which were the primary selection in shaded area 14, have been copied to the position indicated by pointer 18, and now appear in shaded are 24. The manipulation operation resulted in three errors in capitalization and spacing, so that the manipulated text data in text frame 22 has an incorrect textual type punctuational structure.
Finally, in box 30, the data processor provides fix-up data defining a sequence of one or more operations to further manipulate the text data so that the corresponding text has a correct textual type punctuational structure. This sequence is then performed, resulting in modified text data corresponding to the modified text shown in text frame 32.
FIG. 1 illustrates how the invention can make text manipulation much more efficient. The user has been saved the effort of requesting the necessary operations to correct each of the errors in capitalization and spacing.
FIG. 1 also illustrates to an extent how fix-up data can be obtained. One aspect of the invention, as described above, is based on the recognition that an appropriate operation can almost always be inferred from the affected natural boundaries, if any, and from applicable textual types. For example, the beginning of shaded area 24 in text frame 22 has an empty natural boundary at the end of a word unit to the left and an empty natural boundary at the beginning of a word unit to the right, leading to the result that a space should be inserted and the capitalized letter that follows should be changed to lower case. Similarly, the end of shaded area 24 has a natural boundary of type word on the left and a natural boundary of type sentence on the left, leading to the result that the space and period should be replaced by a period. Once fix-up data defining these operations are provided, the text data can be changed accordingly to provide a text with a correct textual type punctuational structure, as shown in text frame 32.
FIG. 2 shows how the steps shown in FIG. 1 can be implemented with a conventional commercially popular text editor. System 50 in FIG. 2 includes processor 52, which receive input signals from keyboard/mouse 54 or any other suitable input device and which provides output for presentation by display 56. Processor 52 executes instructions from program memory 60, which includes host editor 62 and punctuation 64. Host editor 62 and punctuator 64 each include a set of routines, but can each be treated as a single entity because of the distinct roles they play. In executing host editor 62 and punctuator 64, processor 52 also accesses various data structures in data memory 70, some of which are shown in FIG. 2.
In executing host editor 62, processor 52 accesses text data structure 72 which, as described above, contains a sequence of text codes. Processor 52 can also access host selection data structure 74, which can, for example, be a cut buffer or other temporary memory for storing one or more selections and other data relating to selections. For purposes of the present invention, the detailed properties of text data structure 72 and host selection data structure 74 and the details of how host editor 62 manages them or not important, provided that host editor 62 is able to provide relevant data to permit punctuator 64 to perform its role. For example, as described below, it may be sufficient if host editor 62 is able to provide codes from text data structure 72 and buffer positions within host selection data structure 74.
Data memory 70 also includes punctuator's selection data structure 76, in which punctuator 64 stores data relating to selections. As noted above, this data can, for example, include information about a textual type boundary in the region surrounding an end of a selection. Patterns 78 are a set of patterns that punctuator 64 uses to identify a textual type boundary. Punctuator 64 provides fix-up data by loading fix-up data structure 80, from which host editor 62 retrieves that data. Upon locating end points of a selection, punctuator 64 provides data defining the end points by loading end-point data structure 82, from which host editor 62 similarly retrieves that data. Additional data structures can be provided as appropriate for additional communication between host editor 62 and punctuator 64.
FIG. 3 shows general steps that can be performed by system 50 in handling a user request for a selection operation. The request could, for example, be a mouse event such as a button click. In response to the user request, processor 52 executes an appropriate routine from host editor 62 to receive the user request, in box 100. As shown in box 100, FIG. 3 illustrates the response to a request relating to the current selection's textual type; selection requests that do not relate to textual type may not follow the steps shown in FIG. 3, if host editor 62 can handle them without calling punctuator 64.
Host editor 62 calls punctuator 64 in box 102, providing data relevant to the request received in box 100. This data could, for example, include a current pointer position and an indication of which mouse button was clicked with the pointer at that position. It could also include a handle for end-point data structure 82. Host editor 62 need not perform any steps relating to its own selection data structure 74 before calling punctuator 64, because it can rely on punctuator 64 to provide an appropriately modified selection.
Upon being called with a selection request by host editor 62, punctuator 64 branches in box 194 based on whether it needs data about additional text codes from text data structure 72 in order to determine new selection end point positions. If not, the current selection is unchanged by the request, so that punctuator 64 exits in box 106 after performing any other appropriate steps.
If it needs data about additional text codes, punctuator 64 requests data in box 110, indicating at which end of the current selection it needs additional codes. In response, host editor 62 provides the additional codes in box 112. Then punctuator 64 determines in box 114 whether the additional codes include a new end point position, which could be done using patterns 78. If not, it returns to request additional codes in box 110. Of, if it has found one end point and needs codes to find the other, it can similarly return to box 110.
When punctuator 64 has received codes that include the new end point positions of the selection, it changes the data in its selection data structure 76 accordingly, in box 116. Then, in box 118, it loads data into end-point data structure 82 to provide the identified end points to host editor 62. When punctuator 64 returns control to host editor 62, the host modifies its selection data structure 74 according to the end points in end-point data structure 82, in box 120. Then, in box 122, host editor 62 displays the new selection appropriately, such as in reverse video.
FIG. 4 shows general steps that can be performed by system 50 in handling a user request for a manipulation operation or another operation that uses the fix-up data technique. In box 140, host editor 62 receives the request, which may specify an argument and an operation on the argument, as described above. The response of host editor 62 to the request will depend on what operation is requested, as indicated by the branch in box 142. If the request is for a copy operation in the cut-copy-paste paradigm (c-c-p), host editor 62 can perform its own copy operation and can call punctuator 64 to copy the data in its selection data structure 76 into a cut buffer data structure (not shown), in box 144. This relatively simple procedure suffices because the copy operation does not require the fix-up data technique.
If the request is for an operation that uses the fix-up data technique, such as delete, cut or paste in the cut-cop paradigm, copy or move in the copy-move paradigm, or another operation such as changing textual type, described below, a more complicated procedure is followed. In box 146, host editor 62 manipulates text data structure 72 according to its conventional operation, if appropriate. Then, in box 148, host editor 62 calls punctuator 64, providing relevant data such as data indicating the operation requested in box 140 and a handle for fix-up data structure 80. In box 150, punctuator 64 obtains fix-up data defining a sequence of operations leading to a correct textual type punctuational structure. It then loads the fix-up data into fix-up data structure 80, in box 152, before returning to host editor 62. Host editor 62 performs the sequence of operations according to the data in fix-up data structure 80, in box 154, and then displays the fixed-up text, in box 156.
FIG. 4 illustrates not only how an editor's conventional manipulation operations can each be extended to provide fix-up data, but also how a conventional editor can be extended to include higher level operations such as changing the textual type of part of a text. To add a higher level operation, host editor 62 is modified so that it can identify a request for the higher level operation and so that when it receives a request for the higher level operation in box 140, it makes a corresponding call to punctuator 64, in box 148. Punctuator 64 then obtains fix-up data defining a sequence of operations that is effective to perform the higher level operation, in box 150, and the steps continue as in FIG. 4.
We turn now to consider an implementation of the features set forth above.
3. An implementation
Appendices A, B, C, and D together provide an implementation of the invention in the C programming language that can be run on a Macintosh workstation, for example. Appendices A, B, and C together are a set of routines called "TIAB", an acronym for "Trollope in a box". Appendix A includes TIAB routines that respond to calls from a host editor. Appendix B includes underlying TIAB routines that are called by routines in Appendix A. Appendix C is code defining a number of variables, data structures, and macros for TIAB. Appendix D is code that provides table lookup to determine whether a text code is in a particular set of codes.
To understand the implementation in Appendices A-D more fully, we will examine the interface between the host editor and TIAB, including the calls that the host editor provides to TIAB, the calls that TIAB provides to the host editor, and the data structures used by the host editor and TIAB to pass data to each other. Then we will examine the internal operations of TIAB, including TIAB calls to TIAB functions that identify textual type boundaries and that provide fix-up data.
A. Host-TIAB interface
The interface between the host editor and TIAB can be conveniently divided into two parts. One part, called the host editor interface, is the interface by which the host editor, in response to a request from the user, calls TIAB with relevant data and by which TIAB returns data to the host editor in response to the call. Another part, called the TIAB interface, is the interface by which TIAB calls the host editor to obtain data it needs to identify a textual type boundary and by which the host editor provides the requested data.
(1) Host Editor Calls to TIAB
As implemented in Appendix A, TIAB includes a number of functions that can be called by a host editor. These functions could be called in any appropriate sequence to provide editing operations based on punctuational structure. The host editor will typically call a TIAB function in order to obtain data relating to a selection operation or to obtain fix-up data defining a sequence of operations that should follow a manipulation operation or that implement a higher level operation.
(A) Selection Operation Calls
A number of TIAB functions can be called in relation to selection operations. FIG. 5 shows general steps that occur when the user requests a selection operation, steps that are consistent with the operations of the host as described above in relation to FIG. 3. FIG. 5 does not, however, show all of the steps performed by the host editor in determining that the user has requested a selection operation, because each host editor has its own techniques for receiving a user request and determining the requested operation. A conventional editor could be readily modified to interpret a subset of its user requests for selection operations of the types available from TIAB.
The sequence in FIG. 5 begins by receiving the request from the user, in box 200. Implicit in this step are the operations by which the host editor determines whether the requested operation is a selection operation, which may include determining which of the available selection operations is requested. The host editor then branches, explicitly or implicitly, between two type s of selection operations, as shown in box 210. One type of selection operation involves modifying as selection that is a text unit, while the other involves changing a selection that is an insertion point. If the operation changes an insertion point without changing a text unit selection, it need not involve punctuational structure, so that the assistance of TIAB in determining the end points of the new selection is not necessary. If the operation changes a text unit selection, however, TIAB is called to determine appropriate end points for the selection, based on textual type boundaries.
For an operation that changes an insertion point, the host editor performs steps in box 212 to determine the new insertion point and to load a description of it into the host editor's selection data structure, typically without calling TIAB. Then, the host editor calls the TIAB function setSeln in Appendix A, providing relevant data, such as data based on the description of the new insertion point. The function setSeln loads this data into TIAB's selection data structure, a data structure of type TiabSeln, defined in Appendix C. When setSeln returns, the host editor displays the text with the new insertion point, in box 216.
For an operation that changes a text unit selection, the host editor calls an appropriate TIAB function to determine the end points of the new selection, in box 220. Therefore, the selection operations that relate to text units need not be based on or constrained by the conventional selection operations of the host editor, but rather can be defined in a way which facilitates their performance by TIAB. In the implementation of Appendix A, several distinct types of selection operations relating to text units can be performed by TIAB functions, including extendSelnKeys, extend SelnDrag, decrType, and incrType.
TIAB function extendSelnKeys changes the current selection to include or exclude one instance of the current selection's textual type on the left or right of the current selection, leaving the current textual type unchanged. Therefore, extendSelnKeys is called with data indicating whether the change should be made on the left or right of the current selection and in which direction. It could be called in response to a specially defined user request.
TIAB function extendSelnDrag extend the current selection to include the instance of the current selection's textual type that contains a current character position in the text, such as the one derived from the current mouse position, as well as all instances of that textual type that are between the current selection and that instance. The function extendSelnDrag can be called when the user invokes a conventional mouse-based adjust function, for example by dragging the pointer from the current selection to neighboring text units while holding a mouse button down or by clicking a designated mouse button to adjust the selection. A call to extendSelnDrag that results from dragging the pointer includes, in addition to the current mouse position, data indicating an anchor point in the text, in which case the selection is extended either forward or backward from the anchor point to the current mouse position.
TIAB function incrType changes the textual type of the current selection to the next higher textual type and may, if appropriate, extend one or both ends of the current selection to include any additional text codes necessary to reach the closest surrounding textual type boundaries of the new textual type. It is appropriate to call incrType in response to multiple mouse clicks with the pointer in the same position. TIAB function decrType, on the other hand, changes the textual type of the current selection to the next lower textual type and may, if appropriate, drop text codes from the right end of the current selection to reach a textual type boundary of the new textual type.
In making a call to any of these functions, the host editor includes a pointer to a data structure for returning a description of the new selection, such as a data structure of type TextRegion as defined in Appendix C. The description includes the end points of the new selection, for example, an offset and a length. Each TIAB function then returns a description of the new selection in that data structure, in box 222. The host editor then loads this data into its selection data structure and displays the new selection, in box 224.
The host interface can thus call TIAB functions to obtain end points of a new text unit selection. We turn now to calls made by the host interface in response to which TIAB provides fix-up data.
(B) Calls for Fix-up Data
The host editor can also call a TIAB function as part of the response to a request for an operation that requires fix-up data, such as one of the manipulation operations. As discussed above in relation to FIG. 4, the copy operation in the cut-copy-paste paradigm is different than other manipulation operations, because it does not require that TIAB provide fix-up data, so that the only necessary TIAB function is to copy TIAB's selection data to its cut buffer data, through a call to copySeln. For other manipulation operations, however, the host editor calls a TIAB function to provide fix-up data, after which the host editor can perform the sequence of operations defined by the fix-up data. In addition, the host editor can be extended with additional operations, for each of which it similarly calls a TIAB function to provide fix-up data defining a sequence of operations effective to perform the additional operation.
The portion of the host interface that calls TIAB functions to provide fix-up data can be structured so that the host editor first performs its own appropriate operation, such as a manipulation operation. Then the host editor clears TIAB's token and character caches through a call to the function tiabFlushCashe in Appendix A, which is necessary whenever the host changes its text buffer because TIAB's caches are no longer valid. At this point, the host editor calls the appropriate TIAB function to provide fix-up data defining a sequence of operations for a position in the text data or sequences of operations for both ends of a text unit.
The implementation of Appendix A provides several functions that provide fix-up data, including cutSeln for a cut operation in the cut-copy-paste paradigm; pasteSeln for a paste operation; deleteSeln for a delete operation; changeCategory to change the textual type of a selection; toggleCapitalization to change capitalization; and addBrackets and removeBrackets to add and remove brackets, respectively, When one of these TIAB functions returns with fix-up data, the host editor performs the sequence of operations defined by the fix-up data and may then conclude with appropriate calls to such TIAB functions as tiabFlushCache, innitFixup, setIpt, and getSeln.
FIG. 6 shows general steps that can be followed by a conventional host editor upon receiving fix-up data returned by a TIAB function. These steps could alternatively be implemented as part of TIAB, but they depend on the underlying functions available in the host editor so that including them in TIAB specializes TIAB to the host editor. The data structure RegionFixup, defined in Appendix C, is used to provide data structure steps in FIG. 6. In addition, RegionFixup, as defined in Appendix C, includes some data to permit a host editor to undo a sequence of operations defined by fix-up data. In general, RegionFixup could include other data to enable the host editor to perform other appropriate functions, but the data included in RegionFixup as defined suffices to define a basic sequence of operations instances of which can be combined to produce any necessary modification of a text. The basic sequence is illustrated in FIG. 6.
The sequence in FIG. 6 begins by receiving the fix-up data in RegionFixup, in box 250. The TIAB function that provides the fix-up data could return a handle, such as a pointer, for an instance of RegionFixup containing the fix-up data. The host editor routine that called the TIAB function could then include that handle in a call to another host editor function to perform the steps in FIG. 6.
The test in box 252 determines whether the field deletelength contains a value greater than zero, indicating that one or more characters should be deleted. If so, the step in box 254 selects a sequence of codes from the text data of length deletelength, beginning at offset. The step in box 256 calls tiabFlushCache. The step in box 258 then deletes the selection made in box 254.
The test in box 260 next determines whether the field insertlength contains a value greater than zero, indicating that one or more characters should be inserted. If so, the step in box 262 selects the position offset to establish the insertion point. The step in box 265 calls tiabFlushCache. The step in box 266 then inserts the codes in the field insertchars from the selection made in box 262 to the position offset+insertlength.
The test in box 270 determines whether the field newoffset contains a value less than zero, indicating that the insertion point should go at the end of the inserted codes, in any. If so, the step ion box 272 loads the position offset+insertlength in the field newoffset. Alternatively, TIAB could provide the correct value of newoffset.
The test in box 274 determines whether the field capchar contains a value equal to zero, indicating that capitalization need not be changed. If capchar is less than zero, a character should be changed to lower case, but if greater than zero, to upper case. The step in box 276 selects and deletes the text code at the position indicated by capoffset. Then, the step in box 278 inserts at capoffset a text code of the appropriate case. An alternative approach to capitalization would be to perform a deletion and insertion as described above.
Finally, the host editor sets its selection to the position indicated by newoffset. At this point, the host editor may perform further operations before concluding the requested operation, as noted above. These further operations may include calling setSeln so that TIAB keeps track of the host's current selection.
Although the fix-up data defines a sequence of operations that result in a correct textual type punctuational structure, the user may find the result undesirable. Therefore, the host editor could also permit the user to select an operation undoing a sequence of operations that has been done in the manner shown in FIG. 6. Undoing the sequence of operations would include changing the capitalization back, deleting the inserted characters, and inserting the deleted character, at which point the text data will be restored to its state before the fix-up data was obtained. To permit this, RegionFixup includes fields for storing the necessary data, redochars and nRedochars, as shown in Appendix C.
This also permits a two-stage approach to certain requests for manipulation operations. For example, in the cut-copy-paste paradigm, a deletion can be made by deleting and typing over or by deleting and moving the insertion point to another position. The fix-up data in these two options may be different because the modifications made are different. Therefore, the host editor can initially handle a deletion request as if it were one of these two options and, if it turns out to be the other, undo the sequence of operations it has performed and then obtain fix-up data for an appropriate sequence of operations for the other option.
The host interface to TIAB can be extended to provide additional selection operations or additional operations that provide fix-up data. In each case, a TIAB function is added to handle the additional operation.
We turn now to examine the TIAB interface to the host, through which the TIAB functions obtain the data necessary to identify a textual type boundary or to identify an appropriate sequence of operations to provide a correct textual type punctuational structure. Compared to the host interface, the TIAB interface is relatively simple.
(2) TIAB Calls to Host
The primary purpose for which TIAB calls the host editor is to obtain data about the host's text data structure. Therefore, the TIAB interface to the host includes a few host functions that TIAB can call for that purpose. Although the implementation of these functions depends on the manner in which the host editor is implemented, each is a relatively simple function if the host editor uses a conventional text data structure containing a sequence of text codes.
The function getchars1 in Appendix B is the TIAB function that calls a host editor function tiabGetPointer to obtain a pointer to a position in the text data structure and a length of a string text codes that begins at that position. The host editor function tiabGetPointer can in turn be implemented by appropriate calls to its underlying functions. For instance, if the host editor on a Macintosh workstation is using the routines in the ROM conventionally known as Text Edit, it could obtain the pointer by calling *((**TEH).hText), and could obtain the length by calling (**TEH).teLength. Then, tiabGetPointer returns the getchars1 a value indicating the actual offset.
In general, TIAB requires the host editor to do the memory management on text blocks. The general approach to obtaining text codes for TIAB is as follows: tiabGetPointer provides a means by which the host editor may indicate a range of text codes within its internal data structure that may be read (but not changed) by TIAB. If the host editor represents its internal data in such a way that this is inconvenient or impossible, then the host must provide a different set of functions that manage memory blocks and fill them with characters that are copied by the host editor from its internal data structure. This includes the following functions; tiabGetTextBlock, which returns a pointer to a text block using the host editor's preferred memory management scheme, and also returns the number of text codes actually copied; tiabFreeTextBlock, in response to which the host editor frees a text block allocated with tiabGetTextBlock; tiabFreeAllBlocks, in response to which the host processor frees all text blocks allocated with tiabGetTextBlock; tiabLastCharPosn, which returns the index of the last text code in the host editor's text buffer, indicating the number of text codes in the buffer; and tiabCopyChars, which copies a specified number of text codes beginning at a specified offset into a specified text block, and which also returns the number of text codes copied. In freeing text blocks, TIAB can use tiabFreeAllBlocks or can loop through its array calling tiabFreeTextBlock on each iteration.
Although the TIAB interface to the hose is relatively simple, some TIAB functions that make use of the data obtained from the host perform complex computations. We turn now to examine the inner workings of TIAB.
B. TIAB Calls to TIAB
The high level TIAB functions that are called by a host editor fall into two groups, as described above in relation to the host interface to TIAB, one for providing end points of a new selection and another for providing fix-up data. Yet the TIAB interface to the host editor has one primary low-level function, getchars1, which calls the host to obtain codes from the host's text data structure. In between the high level functions and getchars1 are several intermediate levels of TIAB functions.
The first level above getchars1 includes the functions getcharsForward, getcharsBackward, and charAt, which can be called respectively to access codes extending forward from a give position in the host editor's text data structure, to obtain codes extending backward from a given position, or to obtain the code at a given position, This level also includes several functions that can search for a given code or for a code in a given set, including charSearchFwd, charSearchBkwd, charSetSearchFwd, and charSetSearchBkwd. These functions are found in Appendix B.
TIAB does not make use of the meanings or other differences between words in text except those differences that relate specifically to punctuational structure. Therefore, TIAB ignores most of the differences between words by tokenizing the text codes that make up the text so that each word is represented by a token of one of a small number of types, including word, capitalized word, abbreviation, capitalized abbreviation, and, when fine-grained words are being distinguished, word internal, meaning an punctuational code that is part of a word and that would otherwise be represented by a punctuational token but is treated differently when it occurs as part of a word. TIAB treats other codes that relate to punctuational structure as tokens of other types, such as punctuational tokens of types comma, quotation mark, colon, space, period, multiple dashes ellipses, and so on.
Some of the TIAB functions at the next level, tokenScanFwd and tokenScanBkwd in Appendix B, scan through the text code sequence, finding each token boundary and returning the appropriate token code. Other functions can be called to find a token boundary, including tokenBndryRight, tokenBndryLeft, tokenBndryLeft1, and tokenBndryAt in Appendix B, and some of these functions use tokenScanFwd and tokenScanBkwd. These tokenizing functions rely on a number of subsidiary functions to manage a token cache that they share, so that tokenizing is performed dynamically and stored in the token cache to the extent possible.
The high level TIAB functions that identify new selection end points, including extendSelnKeys, extendSelnDrag, incrType, and decrType, rely on two intermediate functions that find textual type boundaries, boundaryBefore and boundaryAfter, to identify the end points of a selection. These boundary-finding functions are also in Appendix A.
The high level TIAB functions that provide fix-up data include addBrackets, removeBrackets, change Categories, cutSeln, deleteSeln, pasteSeln, and toggleCapitalization. Of these functions changeCategories, cutSeln, deleteSeln, and pasteSeln, rely on an intermediate function, getFixupInfo, which is specialized to the task of obtaining information about a natural boundary for use in providing fix-up data. Other TIAB functions relating to natural boundaries include scanNatBndryFwd, scanNatBndryBkwd, nbStartPosn, nbEndPosn, propagateNatBndry, natBndryHere, and checkNBQuotesBrkts, all in Appendix A.
We turn now to examine the operations of some of these functions in greater detail. After considering representative functions that illustrates the roles played by functions at the lower levels, we will consider the main features of the intermediate and higher level functions.
(1) Code Access and Search
FIG. 7 shows steps within getcharsForward, which retrieve text codes forward from a specified position in the host editor's text data structure. FIG. 8 shows steps within charSetSearchFwd, which searches the text data structure for a text code in a specified set of codes.
The function getcharsForward is called in box 300 with a position in the host's text data structure, called the offset, and with pointers to two locations, into one of which it loads a pointer to a starting code and into the other of which it loads a length indicating the number of valid codes beginning with the starting code. The test in box 302 determines whether the offset received in box 300 in less than zero, indicating a position before the beginning of the host editor's text buffer or other text data structure. If so, getcharsForward returns FALSE in box 304, indicating failure to retrieve any codes.
If the offset is greater than zero, the test in box 306 determines whether the offset is greater than or equal to the offset of a block of codes called the excluded block. The excluded block is a text region that getchars1 ignores; the excluded block thus makes it possible in a paste operation to operate on the text codes as they would have been after a delete operation and before an insert operation, without performing a delete operation, then calling TIAB, then performing a paste operation, and then calling TIAB again. If the offset is as great or greater than the excluded block offset, the excluded block's length is added to the offset, in box 308.
The steps beginning in box 310 relate to a cache that includes an array of entries, each corresponding to a block of text codes. Each block's cache entry includes data defining the block, as shown in Appendix C, including the block's offset, length, and a pointer to the first code in the block. Within the cache, the entries are sorted by offset. The steps necessary to setting up the cache include checking whether the cache includes valid data, in box 310; if not, a call to flushBlockCache clears it, in box 312, after which the cache block to be loaded with retrieved text codes is selected and the offset and length of the text codes to be retrieved are set, in box 314. If the cache has valid data but the offset is above or below the cache limits, as determined in box 316, the cache block to be loaded, the offset, and the length for retrieval are similarly set in box 314 to retrieve a block of text codes that will not overlap with the highest or lowest previously cached block.
In the case where the offset received in box 300 falls within the cache limits, the step in box 320 begins an iterative loop that goes through the previously loaded cache blocks, searching for the cache block which either includes the offset or has a cache block offset greater than the offset received in box 300.
The test in box 322 determines whether the offset is in the next cache block and, if so, the step in box 324 loads the code pointer to the appropriate code within the cache block and the length of the code sequence following that code in the cache block, taking into account the excluded block if necessary. The test in box 326 then determines whether the length of the code sequence is greater than zero. If not, FALSE is returned in box 304, as above. But if so, TRUE is returned in box 328, indicating success.
If the offset is not in any of the cache blocks, but falls before the offset of a previously loaded cache block, as determined by the test in box 330, the step in box 332 sets the starting offset and length of the text codes to be retrieved, where possible making them contiguous with a previously loaded cache block.
When the offset does not point to a position in any of the previously loaded cache blocks, whether outside or within the cache limits, the step in box 334 calls getchars1 with the starting offset and length of the text codes to be retrieved. First, getchars1 sets up a cache block header for the text codes to be retrieved. By a call to tiabGetPointer, getchars1 requests the pointer to the codes and the length, loading the pointer to the codes into the appropriate cache block field. If the length is zero, getchars1 calls tiabCopyChars to obtain the text codes. Otherwise, getchars1 sets the cache block length equal to the length from tiabGetPointer and adjusts the limits of the cache block to include the block of text codes, finally returning TRUE. Then, getcharsForward branches in box 336 based on the result returned by getchars1. If the result is FALSE, getcharsForwar also returns FALSE, in box 304. If the result is TRUE, indicating retrieval of text codes, the step in box 324 loads the code pointer and length, as above, and the test in box 326 determines whether to return TRUE or FALSE.
The function getcharsBackward is similar to getcharsForward, except that it retrieves codes going backward from the offset. The function charAt uses getcharsForward to retrieve the code at a specified position.
The function charSetSearchFwd, as shown in FIG. 8, is called with two pointers, one to data indicating a position in the text data structure and the other to a bitset identifier indicating a set of text codes, in box 350. The step in box 352 calls getcharsForward, providing the position as the offset. The branch in box 354 is based on the result returned by getcharsForward, with charSetSearchFwd returning FALSE in box 356 if getcharsForward returned FALSE. If getcharsForward succeeded in retrieving a sequence of text codes, however, the step in box begins an iterative loop that goes through the codes. The test in box 362 determines whether each code is in the set indicated by the bitset identifier, calling the macro BITSET, defined in Appendix C. Upon finding a code in the set, charSetSearchFwd changes the position to the position of that code and returns TRUE to indicate that it found a code in the set. If none of the codes is in the set, charSetSearchFwd returns to the step in box 352 to retrieve another sequence of text codes.
Appendix B includes several other functions resembling charSetSearchFwd, including charSearchFwd and charSearchBkwd to search forward and backward for a specified code, and charSetSearchBkwd to search backward for a code in a specified set.
(2) Token Scanning
FIG. 9 shows general steps in the function tokenScanBkwd in Appendix B. This function checks for patterns of text codes and converts recognized patterns into token codes. Numerous patterns can be recognized, so that tokenScanBkwd includes complicated pattern matching operation, but the steps in FIG. 9 do not shown the details of pattern matching.
In box 370, tokenScanBkwd begins by receiving a pointer to a scan record, a data structure defined in Appendix C that contains a record of a scan for token. The scan record includes a pointer to a boundary within the text data structure. The test in box 372 determines whether the token boundary that precedes that boundary in the text has already been scanned. If so, the step in box 374 retrieves the previous result from a token cache and returns it.
If the preceding boundary has not been previously scanned, the step in box 376 calls getcharsBackward to retrieve a sequence of text codes to be scanned, and similar calls are made elsewhere within tokenScanBkwd as necessary. If one of these calls returns FALSE, the scan fails, and a value is returned indicating a scan failure.
The test in box 380 begins a sequence of steps that scan backward through the text codes to find the next token boundary. The test in box 380 detects whether the next code is one of the punctuational codes that correspond to a token code. If so, the test in box 382 determines whether it is a punctuational code that occurs within a word. If it is not within a word, the step in box 384 returns the appropriate code for the punctuational code.
When a word has been detected, the step in box 390 begins a short iterative loop that goes through the codes in the word, obtaining any information about abbreviations, capital letters, numbers, or other characteristics of the word that have a bearing on which token code should be assigned to it. This continues until a word break is detected in box 392. Then the appropriate token code for the word is returned.
The details of tokenScanBkwd are complex because the rules for word formation that it applies are relatively complex. They are adapted to conventions of the English language, but could alternatively be adapt to conventions of another language. As implemented in Appendix B, tokenScanBwkd permits words that contain internal hyphens and apostrophes, and, under certain conditions, words that contain commas, periods, and colons. For example, the following would be treated as words:
it's
10:30
$1,000.00
real-time
The implementation in Appendix B also allows word boundaries to be detected at word-internal punctuation marks, because it is sometimes convenient to be able to select parts of words in this way.
Appendix B includes several other functions resembling tokenScanBkwd, including tokenScanFwd, which scans forward rather than backward; tokenBndryRight, which determines whether the current position is a token boundary and, if not, moves forward to the next token boundary; and tokenBndryLeft, which moves backward to the next token boundary if the current position is not a token boundary. The functions tokenBndryRight and tokenBndryLeft are useful to start a scan on a token boundary.
Table I shows the relationship between text codes and token codes that result from token scanning.
The text codes in Table I form a sentence, as indicated in the title. The token codes, on the other hand, include codes that indicate each occurrence of several types of punctuational codes, including left quotation mark (LQ), comma (C), right quotation mark (RQ), space (Sp), and period (P). In addition, the token codes include codes for types of word units, including capitalized word (W-Cap) and ordinary word (W).
The functions in Appendix A perform various operations on a stream of token codes in order to find end points and provide fix-up data. We turn now to consider some of those operations.
(3) End Points
The functions in Appendix A that respond to host editor calls relating to modification of a selection include extendSelnKeys, extend SelnDrag, incrType, and decrType. Each of these TIAB selection functions responds by providing end points of a new selection. FIG. 10 shows general steps followed by these functions.
The sequence of FIG. 10 begins when one of the TIAB selection functions is called by the host editor. As shown in box 400, this call includes a pointer to an end point data structure. When the TIAB selection function returns, the host editor retrieves the new end points from the end point data structure and uses them to define the new selection. The call to the TIAB selection function may also include other data. For example, a call to extendSelnDrag includes a position and an anchor point within the host editor's text data structure, and a call to extendSelnKeys includes a code indicating which way the selection should be extended and from which of its old end points.
The TIAB selection function may begin in box 402 by determining whether it has been appropriately called. The functions extendSelnDrag and extendSelnKeys, for example, are not appropriate if there is no currently selected text unit. Similarly, incrType is not appropriate if the type of the currently selected text unit is the highest textual type, which is the type paragraph in Appendix A. If not appropriately called, the TIAB selection function returns the value FALSE in box 404, to which the host editor can respond with an appropriate error message or signal, such as by flashing the current selection.
If the TIAB selection function has been appropriately called, it proceeds to obtain the data for providing the end points and also for enabling subsequent functions to provide fix-up data, in box 410. In the implementation of Appendix A, this data is held in a TiabSeln data structure, defined in Appendix C. As shown there, the data can include data indicating end points of the new selection, such as an offset and length; data indicating one or more textual types relevant to the new selection, such as the type of the selection itself and, if the selection is of type bracket, the underlying type; data indicating features at the end points of the new selection, such as the token, token length, and textual type of the natural boundary at an end of the selection; and data indicating whether the selection is capitalized. Each of the TIAB selection functions obtains this data in its own way.
The simplest of the TIAB selection functions, decrType, is implemented in Appendix A so that it adjusts the right end point of the current selection to obtain the new selection, and then only if it is appropriate to adjust the right end point. For instance, if the current selection is of type bracket or dashes, decrType does not adjust the right end point, but decrements the underlying type of the selection fi the underlying type is greater than type character. But if the selection is of a type greater than type character, and if it has a natural boundary on its right of length greater than zero, decrType drops the tokens in the natural boundary, adding one back if it is one of the closing brackets before decrementing the type of the selection.
In contrast to decrType, the TIAB selection functions incrType, extendSelnKeys, and extendSelnDrag all depend on the intermediate TIAB functions boundaryAfter and boundaryBefore to find textual type boundaries as necessary. These intermediate functions are called with a pointer to a ScanRecord data structure, as defined in Appendix C, through which each function returns the positions at the ends of a textual type boundary. Each function also returns a value indicating the textual type of the boundary.
As described above, a textual type boundary always includes at least one token, and boundaryAfter and boundaryBefore each operate by matching the token stream against token patterns that are included implicitly in the operations they perform. The patterns used in the implementation of Appendix A include the following: a comma token, optionally followed by a space token, is a textual type boundary of type phrase; a semicolon, dash, or three-dot ellipsis token, optionally followed by a space token, is of type clause; a period, question mark, or exclamation mark token followed by at least two spaces tokens (or alternatively by only space token according to an option flag that is intended to be set by the host editor in response to a user request) is of type sentence. In these patterns, a comma or period token could be followed by a right single or double quote mark token, and a textual type boundary of type sentence could include any number of right quote and parenthesis tokens preceding the space tokens. These patterns are appropriate for the English language, but similar patterns could be formulated for other natural languages. Upon identifying the textual type of a textual type boundary, boundaryBefore and boundaryAfter load the data defining its ends and return its type. As a special case, the function boundaryAfter preliminarily determines whether its beginning is just after a token of type abbreviation, in which case it returns the type of the boundary immediately following the abbreviation.
Table II illustrates the relationship between an excerpt from a stream of token codes and the textual type codes returned by the function boundaryAfter.
The textual type codes in Table II include character (Ch), word (W), phrase (F), clause (Cl), and sentence (S), while the token codes include those introduced above in relation to Table I and semicolon (SC).
As can be seen from Table II, the textual type code for each token code indicates the textual type of the preceding text unit, so that where a series of punctuation token occur, each of them may have the same corresponding textual type code. The each one of the series of token codes corresponding to a comma, a quote mark, and a space, for example, has the textual type code for a phrase, while each of the series corresponding to a semicolon and a space has the code for a clause, and each of the series corresponding to a period and two spaces has the code for a sentence. A series of token codes with the same textual type can, as a result, be treated as a unit with that textual type and with specified ends and a length when appropriate.
Each of the three TIAB selection functions that rely on boundaryAfter and boundaryBefore has a distinct sequence of operations. The function extendSelnKeys calls the appropriate one of four functions, each of which in turn calls the appropriate one of boundaryAfter or boundaryBefore; the four functions are extendRightFromRight, extendRightFromLeft, extendLeftFromRight, and extendLeftFromLeft. The function extendSelnDrag determines whether to call boundaryAfter or boundaryBefore based on whether the position in the call is before or after the anchor. The function incrType, after incrementing the type of the current selection, calls both boundary After and boundary Before in a loop that repeatedly extends the selection until an appropriate bracketed selection, as determined by checkBracketIncr, or an appropriate unbracketed selection is reached; incrType thus responds to multi-clicking in which each successive click increments the active textual type and selects the minimum surrounding region of that type, from character to word, phrase, clause, sentence, and paragraph; if a selection begins within a bracket-delimited structure, such as a parenthetical or quotation, multiclicking selects that structure at an appropriate point in the sequence; but if a bracket-delimited structure is part of the surrounding text that should be selected as a result of a clock, the structure is selected in its entirety.
After obtaining the end points of the new selection, each of the TIAB selection functions also obtains other relevant data such as boundary features and capitalization. This data is stored in the TiabSeln data structure described above.
Each of the TIAB selection functions concludes by loading the end points of the new selection into the end point data structure, in box 412, and then returning TRUE in box 414. The host editor can then retrieve the end points of the new selection and use them to determine the new selection which is then displayed, as described above in relation to FIG. 3.
(4) Fix-Up Data
The functions in Appendix A that provide fix-up data include addBrackets, removeBrackets, changeCategories, cutSeln, deleteSeln, pasteSeln, and toggleCapitalization. Of these functions, cutSeln, deleteSeln, and pasteSeln are called by the host editor after performing a manipulation operation in the cut-copy-paste paradigm; as note above, the function copySeln is also called as a result of a manipulation operation, but rather than providing fix-up data, copySeln merely copies TIAB's selection data structure into another TiabSeln data structure that serves as TIAB's cut buffer data structure. The other functions, addBrackets, removeBrackets, changeCategories, and toggleCapitalization provide higher level operations by providing fix-up data defining how the higher level operations can be performed.
In general, the TIAB functions that provide fix-up data are based on the conventions of the English language, so that each function implicitly includes a set of rules that it uses to obtain appropriate fix-up data. Other natural languages with different conventions might require different rules and hence different functions to provide fix-up data, but the general approach of providing fix-up data defining a sequence of operations that leads to a correct textual type punctuational structure should be applicable to other written natural languages.
The functions addBrackets, removeBrackets, and toggleCapitalization involve relatively simple rules, and apply those rules using such functions as scanNatBndryFwd, scanNatBndryBkwd, token ScanFwd, and tokenScanBkwd. These scanning functions scan through the text data and provide appropriate information by returning textual types of natural boundaries and by loading a ScanRecord data structure as defined in Appendix C. The functions changeCategories, copySeln, deleteSeln, and pasteSeln, on the other hand, involve much more complicated rules, and rely on the intermediate function getFixupInfo to obtain data for their fix-up operations, and getFixupInfo in turn calls the scanning functions as necessary.
The scanning functions tokenScanFwd and tokenScanBkwd were discussed above in relation to FIG. 9. The scanning functions scanNatBndryFwd and scanNatBndryBkwd, as implemented in Appendix A, begin at a token boundary in the text data and identify the textual type of a natural boundary that includes the following token in the given direction, applying a set of rules most of which are implicitly included in scanNatBndryFwd. These two functions are also called by some of the TIAB selection functions discussed above, but they play a more significant role in the TIAB fix-up functions.
Although the TIAB fix-up functions differ widely among themselves, they follow a general pattern that includes several similar steps. All of them are called with at least one pointer to a fix-up data structure, and most of them are called with two pointers, either to fix-up data structures for the two ends of a selection or two alternative fix-up data structures. Before beginning to load a fix-up data structure, each fix-up function calls the function initFixup to initialize that data structure with an appropriate offset indicating where the sequence of operations is to be performed. Then, each fix-up function obtains fix-up data and loads it into the fix-up data structures, modifying the TIAB selection data structure as appropriate in the process. Finally, each fix-up function returns control to the host editor function that called it, which then retrieves the fix-up data and performs the indicated sequences of operations as described above in relation to FIG. 6.
FIG. 11 shows graphically the nature of data provided by getFixupInfo when called in relation to a natural boundary, illustrating how it provides data about the natural boundary. The technique illustrated by FIG. 11 makes use of the observation that a sequence of textual type codes corresponding to token codes includes codes of type character, between each adjacent pair of which is a run of another type appropriate to a break between words, such as a run of type word, phrase, clause, sentence, or paragraph, as shown in Table II, above. Therefore, textual type frame 430 in FIG. 11 includes six textual type codes, the first and last of which are of type character, shown as T.sub.ch, and the second through fifth of which are of another type appropriate to a break between words, shown as T.sub.br.
Position 432 in FIG. 11 indicates a position within textual type frame 430 at which getFixupInfo starts. When starting position 432 is within a natural boundary that is a run of a type appropriate to a break between words as in FIG. 11, getFixupInfo finds the left end 434 and the right end 436 of the natural boundary. It then can obtain all the information it needs to load a fixupinfo data structure as defined in Appendix A. It loads the textual type of the codes between starting position 432 and left end 434 as pdnbL and the textual type of the codes between starting position 432 and right end 436 as pdnbR. It loads the number of token codes between starting position 432 and left end 434 as pdnbLlen and the number of token codes between starting position 432 and right end 436 as pdnbRlen. It loads the token code of the token to the left of starting position 432 as pdnbLtoken and the token code of the token to the right as pdnbRtoken. Where appropriate, it sets sentInitFlag to indicate that starting position 432 is immediately before a word and follows a natural boundary whose textual type codes are of type sentence of paragraph, indicating that the following word must begin with a capital letter.
FIG. 12 shows some of the results of applying getFixupInfo at each position within text frame 450, including the values for pdnbL, pdnbLlen, pdnbR, and pdnbRlen at each position. The text codes in text frame 450 correspond to the following string:
a string like this could occur, for example, at the end of a parenthetical that contains a quotation and that is nested within a clause in a sentence.
Result box 452 shows the result of calling getFixInfo at a position between character codes within a word unit--the type in each direction is character (CH), and the length is zero. Similarly, in result box 454, the type to the left is character and the length is zero; to the right, however, the type is right bracket (RB), and the length is one. Result box 456 shows type right bracket to the left and length one and type phrase to the right and length two. Result box 458 shows type phrase in both directions, and length one; if the current TIAB selection were of length greater than zero, however, the type to the right would be type word, because the text code at this position is a space. Finally, result box 460 shows type phrase and length two to the left, but type character and length zero to the right.
The function changeCategories uses the data provided by getFixupInfo, as can be understood from FIGS. 13 and 14. FIG. 13 shows steps in a sequence of operations to change a text unit selection from type word to type phrase, while FIG. 14 shows steps to change an insertion point selection from type sentence to type clause.
Text frame 480 in FIG. 13 shows a shaded text unit selection of type word. In order to change it to type phrase, changeCategories calls getFixUpInfo at each end of the text unit selection to determine the length of the natural boundary of type word, and then loads data into the fix-up data structures that will lead to deletion of the text codes in the natural boundaries, as shown in text frame 482. Then, changeCategories determines what text codes should be inserted at each end of the text unit to provide natural boundaries of type phrase, and loads data into the fix-up data structures that will lead to the appropriate insertion, as shown in text frame 484. When the fix-up data structures are returned to the host editor, the operations at each end of the selection are performed separately, of course, but the same result as shown in FIG. 13 is achieved.
Text frame 490 in FIG. 14 shows an insertion point selection within a natural boundary of type sentence. In order to change to type clause, changeCategories calls getFixupInfo at the insertion point selection to determine the length to each end of the natural boundary. Then, changeCategories determines what length must be deleted to eliminate the natural boundary, as shown in box 492, and what text codes should be inserted to provide a natural boundary of type clause, in this case a semicolon and space as shown in box 494, and loads data indicating the deletion and insertion into the fix-up data structure. In addition, changeCategories includes fix-up data indicating a change of capitalization after the new natural boundary, also shown in box 494.
The other TIAB fix-up operations that call getFixupInfo perform similar steps. The function deleteSeln, which is also called by cutSeln, calls getFixupInfo for data about the natural boundaries to the left and to the right of the text unit selection being deleted; deleteSeln then applies an implicit set of rules to determine, for example whether to delete one or both of the natural boundaries, whether to insert another natural boundary in their place, and whether to change capitalization of the subsequent word.
Upon receiving a user request to perform a paste operation in the cut-copy-paste paradigm, the host editor can, if there is a current selection, delete the current selection and inset the contents of its cut buffer at the post-delete insertion point; then, the host editor calls pasteSeln which first calls getFixupInfo to obtain data about the natural boundaries adjacent to the post delete insertion point in a manner similar to delete Seln, using the excluded block described above; then pasteSeln uses this data and the natural boundary data about the ends of the cut buffer contents obtained at the time of a cut or copy operation to obtain the fix-up data, applying slightly different rules on the left and right of the insertion.
In addition to calling getFixupInfo, pasteSeln calls a number of other functions to assist in obtaining fix-up data and, where appropriate, modifying the TIAB selection data structure. In general, however, pasteSeln follows the same general steps as the other TIAB fix-up functions.
4. Miscellaneous
Various modifications, extensions, and variations of the disclosed implementations are apparent and are within the scope of the invention. A conventional host editor could be modified to accommodate TIAB by providing routines to call TIAB selection functions and TIAB fix-up functions for higher level operations, by modifying the routines that perform manipulation operations so that they call TIAB fix-up functions, and by providing routines to respond to calls from TIAB for data. Alternatively, of course, the invention could be implemented without a separate host editor, but by including these functions within TIAB.
The implementation of Appendices A-D is appropriate for the cut-copy-paste paradigm of text editing. It could easily be extended to handle the move-copy paradigm of editing or to handle other appropriate paradigms.
In general, the rules and patterns applied by the implementation of Appendices A-D are implicit in the functions, but the rules and patterns could alternatively be included in separate data structures as shown for the patterns in FIG. 2, if that would be convenient. The rules and patterns in Appendices A-D resolve all ambiguities in punctuation in a predetermined manner, but it would alternatively be possible to prompt the user to resolve certain troublesome ambiguities.
In the implementation of Appendices A-D, TIAB assumes that positions in the host editor's character buffer can be described by a 32-bit integer. This could be generalized by using a more abstract notion of buffer position, so that it would be more easily adaptable to a greater diversity of host editors.
If the host editor had access to functions like spell checking or search and find, the results of calling such functions might have implications for punctuational structure. Therefore, additional fix-up functions could be added to TIAB to handle such operations.
Although the invention has been described in relation to various implementations, together with modifications ,variations and extensions thereof, other implementations, modifications, variations and extensions are within the scope of the invention. The invention is therefore not limited by the description contained herein or by the drawings, but only by the claims. ##SPC1##
Claims
Certificate of Correction present
The claims shown below may not include correction changes. Use the corrected PDF for authoritative text.
What is claimed:
1. A method of operating a system that includes a processor; the method comprising: a first step of operating the processor to obtain text data defining a text, the text including a first word and a first set of at least one punctuational feature in a region at a first end of the first word; the first step comprising substeps of: receiving a request for a manipulation operation on a selection within the text to produce the text; and in response to the request, operating the processor to perform the manipulation operation and to obtain manipulation operation data indicating the manipulation operation; the manipulation operation producing the text data; and a second step of automatically operating the processor to use the text data and the manipulation operation data to obtain operation-defining data, the operation-defining data defining a sequence of at least one operation of the processor that would modify the text data to produce modified text data, the modified text data defining a modified text including the first word and a second set of at least one punctuational feature in the region at the first end of the first word, the second set of at least one punctuational feature being different than the first set of at least one punctuational feature.
2. The method of claim 1, further comprising a third step of operating the processor to perform the sequence of at least one operation defined by the operation-defining data.
3. The method of claim 2 in which the operation-defining data includes data defining a starting point within the text data, a number of text codes within the text data to delete, and a list of text codes to be inserted, the third step comprising substeps of: deleting the number of text codes beginning at the starting point; and inserting the list of text codes at the starting point.
4. The method of claim 1 in which the text defined by the text data has an incorrect textual type punctuational structure.
5. The method of claim 4 in which the manipulation operation affects the first word, the operation-defining data defining a sequence to correct a punctuational feature at the first end of the first word.
6. The method of claim 5 in which the second step further comprises a substep of determining whether a region that includes the first end of the first word includes a textual type boundary for a textual type and, if so, determining the textual type of the textual type boundary.
7. The method of claim 5 in which the first word has a second end in addition to the first end, the operation-defining data further defining a sequence of at least one operation of the processor to correct a punctuational feature at the second end of the first word.
8. The method of claim 4 in which the first step further comprises a substep of operating the processor to perform a selection operation relating to a selected part of the text prior to the substep of operating the processor to perform the manipulation operation, the substep of operating the processor to perform a selection operation comprising a substep of finding an end point of the selected part of the text.
9. The method of claim 8 in which the substep of finding an end point of the selected part comprises a substep of identifying a textual type boundary.
10. The method of claim 9 in which the substep of identifying a textual type boundary further comprises a substep of performing pattern matching on a set of text codes in the text data.
11. The method of claim 1 in which the requested manipulation operation relates to a position in the text, the second step further comprising a substep of identifying a textual type boundary that includes the position in the text.
12. The method of claim 11 in which the requested manipulation operation relates to a text unit in the text, the position being an end of the text unit, the second step obtaining the operation-defining data based on the textual type boundary's textual type.
13. The method of claim 12 in which the requested manipulation operation changes the text unit to a new textual type, the second step further obtaining the operation-defining data based on the new textual type.
14. The method of claim 11 in which the requested manipulation operation changes the textual type boundary to a new textual type, the second step obtaining the operation-defining data based on the new textual type.
15. The method of operating a system that includes a processor and text data defining a text, the text including a first word having a first end; the method comprising steps of: operating the processor to perform a selection operation relating to a selection within the text; operating the processor to perform a manipulation operation on the text data to produce manipulated text data and manipulation operation data indicating the manipulation operation performed, the manipulated text data defining a manipulated text, the manipulated text including the first word and a first set of at least one punctuational feature in a region at the first end of the first word; the first set of at least one punctuational feature being incorrect; automatically operating the processor to use the manipulated text data and the manipulation operation data to obtain operation-defining data defining a sequence of at least one operation on the manipulated text data that would modify the manipulated text data to correct the first set of at least one punctuational feature; and in response to the operation-defining data, automatically operating the processor to perform a sequence of at least one operation defined by the operation-defining data on the manipulated text data, the sequence modifying the manipulated text data to produce modified text data defining a modified text, the modified text including the first word and a second set of at least one punctuational feature in a region at the first end of the first word, the second set of at least one punctuational feature being different than the first set of at least one punctuational feature; the second set of at least one punctuational feature being correct.
16. The method of claim 15 in which the step of operating the processor to perform a selection operation comprises a substep of obtaining and storing data related to the selected part of the text; the step of automatically operating the processor to perform a sequence of at least one operation on the manipulated text data further comprising a substep of performing the sequence based on the data related to the selected part of the text.
17. The method of claim 15 in which the manipulated text data includes a first set of at least one text code defining the first set of at least one punctuational feature and the modified text data includes a second set of at least one text code defining the second set of at least one punctuational feature, the step of operating the processor to perform a sequence of at least one operation comprising a substep of replacing one of the first set of at least one text code to produce the second set of at least one text code.
18. The method of claim 15 in which the manipulated text data includes a first set of at least one text code defining the first set of at least one punctuational feature and the modified text data includes a second set of at least one text code defining the second set of at least one punctuational feature, the step of operating the processor to perform a sequence of at least one operation comprising a substep of deleting one of the first set of at least one text code to produce the second set of at least one text code.
19. The method of claim 15 in which the manipulated text data includes a first set of at least one text code defining the first set of at least one punctuational feature and the modified text data includes a second set of at least one text code defining the second set of at least one punctuational feature, the step of operating the processor to perform a sequence of at least one operation comprising a substep of inserting an additional text code into the first set of at least one text code to produce the second set of at least one text code.
20. The method of claim 15 in which the manipulated text data includes a first set of at least one text code defining the first set of at least one punctuational feature and the modified text data includes a second set of at least one text code defining the second set of at least one punctuational feature, the step of operating the processor to perform a sequence of at least one operation comprising a substep of changing one of the text codes in the first set of at least one text code by changing capitalization to produce the second set of at least one text code.
21. A method of operating a system that includes a processor; the method comprising: a first step of operating the processor to obtain text data defining a text, the text including a first word and a first set of at least one punctuational feature in a region at a first end of the first word; the first step comprising substeps of: receiving a request for a selection operation on a selection within the text; and in response to the request, operating the processor to perform the selection operation and to obtain selection operation data indicating the selection operation; and a second step of automatically operating the processor to use the text data and the selection operation data to obtain operation-defining data, the operation-defining data defining a sequence of at least one operation of the processor that would modify the text data to produce modified text data, the modified text data defining a modified text including the first word and a second set of at least one punctuational feature in the region at the first end of the first word, the second set of at least one punctuational feature being different than the first set of at least one punctuational feature.
22. The method of claim 21 in which the substep of operating the processor to perform the selection operation and to obtain selection operation data comprises a substep of determining a textual type relating to the selected part of the text; the second step obtaining the operation-defining data based on the textual type.
23. The method of claim 22 in which the substep of determining the textual type comprises a substep of identifying a textual type boundary.
24. The method of claim 23 in which the substep of identifying a textual type boundary further comprises a substep of performing pattern matching on a set of text codes in the text data.
25. The method of claim 22 in which the selected part is a text unit, the substep of determining the textual type comprising substeps of: identifying a textual type boundary at an end of the text unit; and determining the textual type boundary's textual type.
26. The method of claim 25 in which the text data includes a text code corresponding to a punctuational feature at the text unit's end, the substep of identifying the textual type boundary comprising a substep of identifying the textual type boundary based on the text code.
27. The method of claim 26 in which the textual type boundary includes a plurality of text codes at the text unit'end, the plurality of text codes including the above-mentioned text code, the substep of operating the processor to perform the selection operation and to obtain selection operation data further comprising a substep of obtaining a length of the plurality of text codes, the second step obtaining the operation-defining data based on the length.
28. The method of claim 22 in which the selected part is a position within a textual type boundary, the substep of determining the textual type comprising a substep of determining the textual type boundary's textual type.
29. The method of claim 21 in which the substep of operating the processor to perform the selection operation and to obtain selection operation comprises substeps of: obtaining data related to the selected part of the text; and operating the processor to store the data related to the selected part of the text; the second step obtaining the operation-defining data based on the data related to the selected part of the text.
30. The method of claim 29 in which the selected part of the text is a text unit, the substep of obtaining data related to the selected part comprising a substep of identifying a textual type boundary at an end of the text unit.
31. The method of claim 30 in which the substep of obtaining data related to the selected part further comprises a substep of determining the textual type boundary's textual type.
32. The method of claim 30 in which the text data includes a text code corresponding to a punctuational feature at the text unit's end, the substep of identifying the textual type boundary comprising a substep of identifying the textual type boundary based on the text code.
33. The method of claim 32 in which the textual type boundary includes a plurality of text codes at the text unit's end, the plurality of text codes including the above-mentioned text code, the substep of obtaining data related to the selected part further comprising a substep of obtaining a length of the plurality of text codes.
34. The method of claim 29 in which the selected part is a position within a textual type boundary, the substep of obtaining data related to the selected part comprising a substep of identifying the textual type boundary's textual type.
35. The method of claim 1, further comprising a third step of operating the processor to perform the sequence of at least one operation defined by the operation-defining data.
36. The method of claim 35 in which the operation-defining data includes data defining a starting point within the text data, a number of text codes within the text data to delete, and a list of text codes to be inserted, the third step comprising substeps of: deleting the number of text codes beginning at the starting point; and inserting the list of text codes at the starting point.
37. The method of claim 21 in which the requested selection operation relates to a position in the text, the second step further comprising a substep of identifying a textual type boundary that includes the position in the text.
38. The method of claim 37 in which the requested selection operation relates to a text unit in the text, the position being an end of the text unit, the second step obtaining the operation-defining data based on the textual type boundary's textual type.
39. The method of claim 38 in which the requested selection operation changes the text unit to a new textual type, the second step further obtaining the operation-defining data based on the new textual type.
40. The method of claim 37 in which the requested operation changes the textual type boundary to a new textual type, the second step obtaining the operation-defining data based on the new textual type.
41. A system comprising: memory, the memory storing first and second sets of instructions; and a processor, the processor comprising: means for executing from the first set of instructions to perform an operation on text data defining a text and to obtain performed operation data indicating the operation performed; the text including a first word and a first set of at least one punctuational feature in a region at a first end of the first word; and means for automatically executing from the second set of instructions to use the text data and the performed operation data to obtain operation-defining data defining a sequence of at least one operation of the processor that would modify the text data to produce modified text data, the modified text data defining a modified text including the first word and a second set of at least one punctuational feature in the region at the first end of the first word, the second set of at least one punctuational feature being different than the first set of at least one punctuational feature.
42. The system of claim 41 in which the means for executing from the first set of instructions comprises means responsive to the operation-defining data for performing the sequence defined by the operation-defining data.
43. The system of claim 42, further comprising a display, the means for executing from the first set of instructions comprising means responsive to the modified text data for presenting the modified text on the display.
44. The system of the claim 42, in which the means for executing from the first set of instructions further comprises means for providing a pointer to a fix-up data structure, the means for executing from the second set of instructions comprising mean for loading the operation-defining data into the fix-up data structure.
45. The system of claim 42 in which the operation-defining data includes data defining a starting point within the text data, a number of text codes within the text data to delete, a number of text codes to insert, a list of text codes to be inserted, a position within the text data to change capitalization, and how to change capitalization at the position.
46. The system of claim 41, further comprising means for receiving a selection signal relating to a selected text unit within the text, the means for executing from the first set of instructions comprising means for calling the second set of instructions with data relating to the selection signal, the means for executing from the second set of instructions comprising means responsive to the data relating to the selection signal for determining an end point of the selected text unit.
47. The system of claim 46 in which the means for executing from the second set of instructions further comprises means for returning data indicating the end point of the selected text unit, the means for executing from the first set of instructions further comprising means for providing a selection data structure including data defining the selected text unit based on the data indicating the end point.
Patent Citations (8)
Non-Patent Literature (6)
- Leibowitz, M. B., "A Process for Automated Logic-Syntatic Analysis of Natural English Sentences", presented to Graduate Committee of Lehigh University, 1970, pp. 58-101.
- "Getting It Right", Macworld, Aug. 1988, pp. 145, 147.
- Rosenthal, S., "Yes PC Fans, They Still Make Typewriters", San Francisco Examiner, Mar. 27, 1988.
- Text Editing, VP Series Reference Library, Version 1.0, Xerox Corporation, 1985, pp. 47-56.
- Inside Macintosh, Apple Computer, Inc., 1985, pp. I-1373 through I-391.
- Text Editing and Processing, Symbolics, Inc. #999020, Jul. 1986, pp. 24-31 and 63-111.