Script character processing method and system6499043Abstract A pen-based processor needs to be usable to input and edit script like a text-based computer but retain a resemblance to the user of a pad and pencil. The disclosed system and method implement input, editing and other manipulation of glyphs including handwritten script, ASCII test, bit-mapped images and drawings in a common document, using a compatible internal representation of the data and a simple, consistent set of user control functions. These functions are invoked using an intuitive and interactive set of user gestures which do not distract the user from the task of inputting or editing the document. A two-step gesture method avoids confusion between strokes and command gestures and allows use of similar gestures for different functions within the same and different contexts. The system infers from customary user writing conventions that certain relationships of data are to be preserved, including delineation of words and paragraphs, and maintains the relationships, subject to user override, during editing. The display document is formatted to contain lined or unlined areas of glyphs that can be edited, including insertion of a moving space into pre-existing document text and word wrapping. Adjoining drawing areas are unaffected by editing of text data. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
1 This is an example document which has a
2 total of nine lines.
3
4 A list can help one remember:
5 --do this
6 --then this
7
8 Signed,
9 Signature
Line 1: Insert BOL marker because this is the first line in the document. Line 2: Do not insert BOL marker because no space was available at the end of the preceding line for the first word on this line. Lines 3, 7: Insert BOL marker because lines are blank and are followed by non-blank lines. Line 4: Insert BOL marker because this is the first line following a blank line. Lines 5,6: Insert BOL marker because preceding line does not contain text (has blank space) for a statistically significant distance prior to the right margin. Lines 8,9: Insert BOL marker because text is substantially indented. The example document could have been a scanned or FAXed document that was converted to script/text processor document format before being "statically" formatted by the processor. A method of converting the scanned or FAXed document, i.e., a bit-mapped image, into a script compatible format is described herein below in the section entitled "Converting a Bit-Mapped Image." It could have also been a document that was dynamically formatted as the user entered script and/or text. Situations like the following might then have occurred: Line 2, having been left blank while the text on the following lines was entered, had a BOL marker inserted. The user then decided to enter text on line 2. Having done so, line 2 would have its BOL marker removed for the same reason that a BOL marker was not inserted in the first example. Now if the user wanted a BOL marker to be inserted at the beginning of line 2, the insert BOL gesture could be used at the end of line 1 (see FIG. 4C). Because this would be an explicit insertion of the BOL marker, automatic line formatting would not remove the BOL marker--the user would have the option of removing it with the delete space/BOL marker gesture (see FIG. 4B). Any time the user touches the pen to the document portion of the screen, ink will be available for writing/drawing. If a character/word translation process is enabled and the user writes in the text area, translation of script to ASCII text will occur in the background. The translated characters will replace the script and can be edited in the same way as the script. Editing features for script/ASCII text and drawings are available to the user through gestures, icons, and menu choices. TEXT PROCESSING IN SCRIPT/TEXT DOCUMENT For illustration, let us assume that user wants to write a mixed script/ASCII document using the processor of the invention. Starting with a blank piece of "paper," as shown in FIG. 7, a user will typically construct a script/ASCII document by entering the script text (cursive or printed) and having it translated to ASCII in the background. Another way is if the user manually edits a pre-existing ASCII document by insertion of script. Edits can be made to either the script or ASCII text as further described below. In order to be able to perform word-oriented editing operations on both script and ASCII text with a single gesture set, the script and ASCII portions of a document both need to be represented as a series of words. In both handwritten and printed ASCII documents, words are separated by a larger amount of space than that which separates the characters within a word. The larger amount of space between words is the basis upon which the processor decides where a word begins. The script/text processor could decide how much space to look for between script words by watching how the user spaces words as writing occurs, basically learning what type of spacing to expect, but a simpler approach is used effectively in the present invention. The present method provides the user with a default word spacing value which can be determined by watching the user write a line (e.g., the first line of text.) This value specifies a default break point gap (BPG) or spacing which defines a space between words of script, and thereby defines "words," per se. Unlike the space in typed text (e.g., produced by an ASCII space-bar character) the break point gap is defined by the physical word spacing in script, which is variable in length. The processor enables the user to adjust the word spacing value (i.e., the processor's BPG) to his personal script word spacing (i.e., to the user's own BPG). The processor orders strokes/ASCII character images within a line by their left-most point (pixel) position. Accordingly, the word spacing value (BPG) specifies the amount of space that must exist between the left-most point (pixel) of a stroke or ASCII character image and the right-most point of all the preceding strokes and/or ASCII character images on the line in order for the stroke/ASCII character being examined to be recognized as the first stroke/ASCII character of a word (see example in FIG. 5A). The user can increase this value if it is found that partial words are being recognized as words. Or the user can decrease this value if it is found that multiple words are being recognized as a single word. This approach has been found to be highly reliable once the user finds a good personal word spacing value. Keep in mind that the word spacing value is used for recognizing where a word begins (and thus where the preceding word must have ended). The spacing that the user gives words while writing is maintained although inter-word space compaction or expansion could be applied to position words on a line. Word spacing within ASCII text is far more consistent than within script. The word spacing is usually different from that of script, depending upon differences in the relative size of the script and ASCII text. The processor maintains a separate word spacing value for ASCII text. This value is essentially determined by looking at the ASCII character size values resulting from the font+point size selection. The use of multiple font+point sizes in a document will require that a word spacing value exist for each font plus point size combination. Within a string of text of a particular font plus point size, only the appropriate word spacing value will be used to determine word boundaries. As script is translated into ASCII, the processor assigns a word spacing that is appropriate for the font plus point size. This does not restrict the user from inserting additional space between words by using the space insertion gesture, nor does it restrict the user from removing space between words by using the space deletion (erasure) gesture. Space inserted between script or ASCII words can only help the word recognition process, whereas space deletion can hinder the process. When an ASCII document is downloaded into the processor, it must be converted to the processor's internal document format in order for it to be manipulated using the edit gestures. Paragraph boundaries are easily determined in ASCII documents because they are typically demarcated by explicitly-used carriage-return line-feed characters. Word boundaries are also easily determined in ASCII documents because the ASCII space character is used to separate words. When a scanned or FAX document is downloaded into the processor, it must also be converted to the processor's internal document format, as described below. The techniques used to determine word boundaries described above are also used to determine word boundaries once line boundaries have been recognized within the input document. EXAMPLE 1 Assuming the following BPG values: script word spacing value: 9 units; ASCII word spacing value: 6 units. FIG. 5A shows a line of cursive and printed script and ASCII text created by the user in which the processor recognizes word boundaries using the following criteria: (A) First stroke/ASCII character image is always recognized as the beginning of a word. (B) 10 units exist between left-most point of "P" and right-most point of all preceding strokes/ASCII character images on the line. Since 10 is greater than or equal to the script word spacing value, "P" is recognized as the beginning of a word. (C) Not enough blank space for "N" to be recognized as the first letter in a word. (D) Whether script or ASCII word spacing value is used for comparison depends on the ratio of the ASCII character image dimensions when compared to the script dimensions. (E) 6 units exist between left-most point of the ASCII character image "t" and the right-most point of all preceding strokes/ASCII character images on the line. Since 6 is greater than or equal to the ASCII word spacing value, "t" is recognized as the beginning of a word. Note: Proportionally spaced ASCII characters would require a word spacing value specific to each adjacent ASCII character pair. The next three sections describe a preferred implementation of this aspect of the invention in further detail. GESTURE-BASED EDITING A context-sensitive gesture set is provided for editing text and drawings. The user is free to write or draw anywhere on a page, but should keep in mind that large drawings in a text (ruled) area might be broken up during word wrap and text in a drawing area cannot word wrap. Gestures are pen movements used to tell the processor control program to do something. This invention uses a two-part gesture. The first part initiates gesture control; the second part is the gesture itself. The processor allows the user to perform a pen action within the document to indicate that a control gesture is going to be made that should not be interpreted as an additional text/drawing stroke. The pen action stimulates feedback by causing display of a gesture prompt. The three primary ways (although there are many more) to get a gesture prompt are: (1) touch the tip of the pen (stylus) to the digitizer surface and hold it in this position for a split second; (2) tap the digitizer surface with the tip of the pen and then touch the tip of the pen to the digitizer surface at approximately the same position as the tap; or (3) in a system in which pen angle is sensed, a particular pen position (e.g., vertical) can be used to initiate a gesture prompt. Note that a specific pen action need not be tied to a specific gesture prompt. The user can be provided with a way of mapping pen actions to gesture prompts (and thus gesture classes). This would, for instance, allow the user to use the most efficient and/or comfortable pen actions to perform the gesturing tasks currently at hand. The user could then remap the pen actions to a different gesture class and proceed to use those same pen actions to efficiently and/or comfortably do something else. When one of the above actions occurs, a visible gesture prompt symbol will be presented to the user. The gesture prompt symbol can take a form associated with the class of gestures that it represents. For action (1) above, the preferred prompt is a filled circle 50 at the pen down location as shown in FIGS. 4-4I. Action (2) can be used to get a selection gesture prompt in the form of a vertical bar 52 (FIG. 4I). So, in addition to being context sensitive, gestures are "prompt sensitive." The particular shape of the prompt displayed to the user can be varied (see FIG. 4I) and it is not essential to display a prompt symbol although very much preferred. After seeing the prompt, the user moves the pen in a selected direction 51 (FIG. 4) to invoke a desired function. For the prompts and associated gestures described within this patent application, the tip of the pen is held to the digitizer surface beginning with the prompt and continuing through the gesture. For other prompts and gesture classes, the pen may not need to remain in contact with the digitizer surface. For instance, an "object drawing" prompt could be followed by the entry of multiple line segments, with the gesture recognition algorithm examining each line segment until a particular geometric shape (e.g., square, triangle, circle, etc.) was recognized. At that point in time, the user would be presented with a high quality representation of the recognized shape and the gesture would be complete (unless the object drawing prompt was used to enter a mode (drawing mode) that must be explicitly exited using another gesture). For many gestures, gesture recognition can occur before the gesture is completely drawn. The gestures described in this application were chosen for many reasons, one being that they can be recognized as they are being made. This allows gesture feedback to be provided to the user at the earliest possible time. When the user makes a gesture, immediate feedback that corresponds to the type of gesture being made will be provided. For example, a selection gesture can cause the selected line space and strokes/words to be highlighted in some way, such as by drawing a transitory line that follows the gesture as shown in FIG. 7D, or by inverse video or bolding the selected line space and script or text. With sufficient computing speed, the selected command function can be executed as the gesture is being made. For instance, a line insertion gesture could cause blank lines to be inserted and displayed as the user makes the gesture. This sort of feedback is highly desired by the user. Following is a description of the preferred gesture set as shown in FIGS. 4A-4H and the control and edit functions for each gesture. Insert Space Gesture 54 (FIG. 4A) This gesture inserts (opens up) an amount of space on the gesture line equivalent to the length of the gesture stroke. Words pushed off the end of the line wrap to the next line. Delete Space Gesture 56 (FIG. 4B) This gesture deletes (collapse) space/strokes underneath the gesture stroke. Words from following lines may wrap back to the gesture line if it is permissible to remove words from the following lines (i.e., no intervening BOL marker). If this gesture follows all strokes on a line, words will be allowed to wrap back to the gesture line from the following line even if they previously were disabled from doing so by a Beginning of Line marker. Insert Beginning of Line (BOL) Marker Gesture 58 (FIG. 4C) All strokes (words) following this gesture are wrapped forward to the next line. No words from preceding lines will be allowed to wrap onto this "protected" line unless the Beginning of Line marker is removed. The number of markers inserted depends on the distance of the gesture stroke. Multiple BOL markers will appear to the user as blank lines. Delete Line Contents Gesture 60 (FIG. 4D) This gesture deletes the text (ruled) area contents of each line touched by the gesture stroke. Mark Block Gesture 62 (FIG. 4E) Two separate gestures are required after the gesture prompt to mark a block of text. The first gesture marks the beginning/end of the block and the second gesture marks the end/beginning of the block. The mark block gesture line must stay within the confines of the ruled line lest it be recognized as an Insert BOL marker gesture. Ink dribbling, paging, scrolling, etc. can occur between the beginning and end mark gestures. Insert/Collapse Moving Space Gesture (FIG. 4F) The insert moving space gesture consists of lifting the pen out of contact with the digitizer surface without moving it laterally, after the gesture prompt. This gesture is used to open up an indefinite or moving amount of space within a line of script or text so the user can insert additional script or text. About 1.5 inches (6 cm.) of space will be opened immediately to the right of the pen down position initially upon recognition of the gesture. After the space opens, the user lowers the pen and begins writing. As the user writes, additional space will automatically be provided in order to accommodate continuing strokes. This method can be called "auto-insertion." Any words pushed off the end of the initial pen-down line by the auto-insertion will be wrapped to the following line. Repeating this gesture (i.e., prompt plus lift pen) collapses the moving space. Note that actions resulting from the foregoing gestures, when located in the lined area of the document display, will in no way affect drawings in the unlined drawing areas surrounding or adjoining the gesture-modified text. The gesture set is context-sensitive, however, so that the same gesture can be used in the unlined areas to perform either different editing functions or similar functions only in the drawing area, i.e., without affecting contents of adjoining lined area. Line Insertion Gesture (see FIG. 7Q) The Line Insertion Gesture is like the Insert BOL gesture 58 (FIG. 4C) but is located in the unlined margin alongside a line. A whole line (text area+drawing area) or multiple lines will be inserted in the lined area laterally adjoining the gesture location shifting all lines below it downward within the document. This will cause the last line on each affected document page to be shifted over the bottom and top margins (if any) to the first line of the next document page. The inserted line takes on the characteristics (ruled area margins, etc.) of the line/ruler that precedes it. Multiple lines can be inserted by extending the distance that the gesture covers. Line Deletion Gesture (see FIG. 7S) This gesture is like gesture 60 (FIG. 4D) but performed in the margin. A whole line will be deleted from the document, shifting all lines below it upward within the document. This will cause the first line on each succeeding document page to be shifted up over the top and bottom margins (if any) to the last line on the preceding document page. Multiple lines can be deleted by extending the distance that the gesture stroke covers. This gesture can also be used to delete the contents of a top/bottom margin line, although the margin line itself will not be deleted. The gesture can be used to delete a ruler, causing the lines following the deleted ruler to be formatted according to the ruler preceding the deleted ruler. Stretching Box Gesture 64 (FIG. 4G) The Stretching Box Select gesture (which might also or alternatively be represented by an icon) selects all drawing area strokes touched/enclosed by the rectangular area. Rope Select Gesture 66 (FIG. 4H) The Rope Select gesture (might also be represented by icon) selects all drawing area strokes touched/enclosed by roped area. Prompt-Specific Gesture Sets Multiple unique gesture prompts allow for the classification of gestures. Each specific gesture motion can be associated with one or more prompts (pen actions). In FIG. 41, two unique prompt images are shown, each with a set of gesture pen motions. Note that the first five gestures in each set is unique in function although the gestures are identical motions. The last three gestures in each set are similar in both motion and function. Another interesting aspect of the gesture set shown in FIG. 4I is that, with the exception of Pen Up and Mark Block, all of the gesture motions can be recognized as specific gestures (given the context in which they are currently supported) even before the gesture is completed! This allows dynamic feedback to be provided to the user as the user performs the gesture (e.g., showing increasing amounts of whitespace and word wrapping as the user inserts space). The current implementation of the software waits for the user to complete gestures before acting upon them. Future versions will utilize multi-tasking to provide dynamic feedback that is highly responsive to the pen. Selected Strokes A variety of functions can be applied to selected strokes in text or drawing area. These functions are available through menu selection: delete, cut, copy, paste, highlight (bold, outline, etc.), translate (from script into ASCII), evaluate (math expressions), etc. In addition, selected strokes can be dragged by touching the pen to the selected strokes and dragging. Strokes can be selected by invoking the I-beam gesture prompt 52 (FIG. I) and dragging it through the stroke(s) to be selected. Additional editing tools can be provided and represented by suitable icons. All tools are picked up, used one or more times, and then returned to their original places. A preferred set of tools and examples of corresponding icons are shown in FIG. 8. Ruler 70 The user picks up the ruler icon in order to insert a ruler. A ruler will be inserted at the pen down position within the document. Highlight 72 The highlight marker is used to highlight strokes. The highlight remains on the strokes until it is explicitly removed by the user through repeat (inverse) highlighting or SELECT, choose new highlight. Multiple highlight markers or a single "multicolored" highlight marker may exist to accommodate different highlighting needs. Pointing Finger 74 The pointing finger is used to select text. It can be used in place of the drag select gesture if desired. It is different from the drag select gesture in that it allows the user to select more than one piece of text. Eraser 76 The eraser erases pixels within text or drawing areas without collapsing blank space. The eraser can come in different sizes to erase pixel swaths of different widths. Rubberband Line 78 The rubberband line is provided so that the user can draw straight lines within the text or drawing area without the use of a template or straightedge. Circle The circle allows the user to draw variable sized circles within the text or drawing area without the use of a template. Open Drawing Space Left 82, Full-Width 84 and Right 86 These icons are invoked to change line lengths to increase the available unlined drawing space in an adjoining margin, or to extend the drawing space all the way across the page. Stroke Eraser 88 The stroke eraser will erase only the pixels of strokes, not affecting any ASCII text. This is quite useful when annotating documents that exist primarily in an ASCII text form. Conversion of Strokes to Internal Stroke Format Following is a description, with reference to FIGS. 6A-6D, of how strokes go from being input glyphs to residing within the software system as meaningful data in accordance with another aspect. For simplicity, the following description assumes that lines are stored at screen (raster) resolution. As shown in FIG. 6A, the document exists in a window (a bit-mapped display area having its origin in the lower left corner) having a series of logical lines, the first line being numbered 1 and succeeding lines having increasing line numbers (through line N). The document is displayed with lower document line numbers (e.g., lines 4, 5, 6) appearing at the top of the window and document line numbers increasing as document lines are displayed toward the bottom of the window (e.g., line N+3). At any point in time the window represents a viewport onto a certain number of document lines. The exact location of the viewport onto the document is maintained by keeping track of the first (topmost) document line (e.g., line 4) that will be viewable in the window. When a stroke is stored into the document, the document line into which the stroke will be rooted must be determined. A number of methods exist for mapping a stroke to a certain window line. The two discussed below are "pen-down targeting" and "dynamic targeting." The preferred of the two is a function of the user's writing style. Pen-Down Targeting The first method "roots" the stroke in the line where the pen tip is first touched down. This method is simple and generally effective. The corresponding window line is then determined using the following equation: WLN=((FRR-PDYV)/RRPL)+1 in which: WLN=Window Line Number; FRR=First Raster Row; PDYV=Pen Down Y Value; and RRPL=Raster Rows Per Line. Now that the window line number has been determined, the document line that the stroke belongs to can be determined by the following equation: DL=(TDL+WL)-1 in which: DL=Document Line; TDL=Topmost Document Line; and WL=Window Line Once the document line is determined, the document line needs to be retrieved from the document line database. Dynamic Targeting Pen down position rooting or "targeting" works very well as long as the user begins each stroke in the line where the text being written resides. Unfortunately pen down targeting is too restrictive for most writers. "Dynamic targeting" allows writers to be more sloppy about where their strokes begin. If the user started a stroke in the line preceding or following the intended line, the stroke should still be rooted in the intended line. The method is labeled "dynamic" because it determines where strokes are rooted as soon as enough information about the stroke is available. Dynamic targeting does not wait for the user to perform a specific action, e.g., changing the input context or lifting the pen out of proximity, before rooting the stroke. Dynamic targeting initially roots long strokes in a line space in which the vertical `center of gravity` position, i.e., a y coordinate, resides. Short strokes, however, such as a comma, are initially rooted in their pen down line. This initial rooting of strokes occurs until a current input line is determined using a predetermined number of strokes or by an insertion of a moving space, as described below. Once the current input line is determined, the predetermined number of strokes that were used to determine the current input line are moved to the current input line. Dynamic targeting can, therefore, uproot strokes from their initial line space and reroot the strokes in the current input line, if the current input line differs from the initial rooting line space. A current input line can be established in two ways. First, a current input line is always established when a moving space is opened. In this case, the moving space is the current input line. In addition, if a current input line has not been determined, but a moving space is open, the moving space is assigned the current input line if a stroke enters the moving space. Second, during the initial rooting, if a predetermined number (N) strokes are proximately located, a current input line is established according to the positions of the N strokes, as described further below. Referring to FIG. 13, a portion of the display including three lines is shown. In a middle line, which is defined as a current input line, two words are shown: "word1" and "word2". The current input line contains a user-definable input area beginning at a input area left border and spanning to an input area right border, as shown by a bracket in FIG. 13. The user-definable input area has a default width equal to the current input line length divided by two. The temporal order in which the strokes are entered is recorded in order to perform the dynamic targeting. In the example shown at FIG. 13 "word2" is entered after "word1." Further, the "2" in "word2" is the latest stroke entered in the current input line. The significance of the temporal order of the strokes will become apparent when the method is further described herein below. The dynamic targeting method begins by capturing the most recent stroke, as shown in FIG. 14A. In step S100, the method determines whether a current input line is defined or not. If a current input line is defined the method proceeds to step S102, otherwise the method proceeds to step S118 in FIG. 14C. If a current input line is defined, the method determines whether any portion of the current stroke touches the current input line. If so, the method transitions to step S104. If not, the method transitions to step S116 in FIG. 14B. If the current stroke touches a portion of the input line, step S104 determines whether a portion of the current stroke extends beyond the two lines adjacent to the current input line. As long as the stroke does not extend beyond the three line window defined by the current input line and the two adjacent lines, the method transitions to step S106. If the stroke exceeds the bounds of the three line window the method transitions to step S116. Next, in step S106, the method determines whether a right-most point of the current stroke is to the right of the input area left border. If so, the method then determines whether a left-most point of the stroke is to the left of the right border of the current input area in step S108 (FIG. 14B). If either of these two determinations are negative a method transitions to step S116, which sets the current input line to an undefined state. If the determinations in steps S106 and S108 are affirmative, the method roots the current stroke in the current input line in step S110. The dynamic targeting method then determines the new input area borders for the current input line in step S112, which is described further with respect to FIG. 16 below. Referring now to FIG. 14C, if the current input line is undefined, the current stroke is compared to a user-definable length value in step S118. If the stroke is equal to or longer than the user-definable length the vertical center of gravity is determined for the stroke in step S120. The stroke is then rooted in a line in which the vertical center of gravity resides in step S122. The vertical center of gravity is equal, for example, to the average Y-coordinate value for the stroke. If, however, the stroke is shorter than the user-definable value the stroke is rooted in the line in which the pen -was first put down, i.e., the "pen down" position. In either case, the dynamic targeting method detects the input line in step S126. Referring now to FIG. 15A, the detect input line method is shown. The detect input line method begins in step S130 by recording the latest stroke in a circular list of N (user-definable) strokes. The circular list is a data structure known in the art of computer programming. The circular list typically consists of a linked list having a tail pointing back to a head of the list. If there are remaining entries in the list, i.e., N strokes have not been entered, the method returns in step S140. If N strokes have been detected, step S134 determines whether the N strokes are within a user-definable horizontal distance. If so, a compute common line function is called in step S136. Otherwise, the method returns in step S140. Following the compute common line step, described below, step S138 determines whether all N strokes touch the common line computed in step S136. If so, referring now to FIG. 15B, the method that determines whether all N strokes are contained within the vertical three line area in step S142 is performed. Otherwise, the return step S144 is performed. If all of the strokes are contained within the vertical three line area the current input line is set to the common line calculated in step S136. Once the current input line is determined, the N strokes which are not rooted in the current input line are rerouted into the current input line in step S148. Next, the input area borders of the current input line are determined in step S150. The circular list is then emptied in step S160 and the detect input line procedure is complete. Referring now to FIG. 16, the determine input area borders method is shown. In step S164, the input area borders method first finds the word that contains the latest stroke. The left border of the input area is then set equal to the word's left-most point position in step S166. The right border of the input area is determined in step S168 by adding the user-definable input area width value to the input area left border determined in step S166. Referring now to FIG. 17, the compute common line method is shown. First, a vertical center of gravity is determined for each stroke in the list. In the preferred embodiment, the vertical center of gravity corresponds to the average y-coordinate value for the stroke. In step S174, each vertical center of gravity is mapped to a line on the display wherein the center of gravity resides. If one of the lines in which the center of gravities reside has a high percentage of the center of gravity points, the common line is set equal to the line in which a high percentage of the center of gravity points resides. In the preferred embodiment, the "high-percentage" is a user-definable percentage. If there is no such line containing a high percentage of the center of gravity points, an average of the center of gravity values is computed in step S180. The average center of gravity value is mapped to a line in which the average center of gravity resides. The common line is then set equal to the line in which the average center of gravity resides in step S182. The following example demonstrates the center of gravity calculation in step S180. For example, assume N=3, as in the preferred embodiment. For strokes having center of gravities equal to 51, 55, 62, the average of these three values is 56. Therefore, the common line is the line space that contains the points having a y coordinate of 56. In addition to the method described above, when a moving space is opened the current input line is set equal to the line in which the moving space is open, as shown in FIG. 18A. If the current input line is set equal to the moving space line, the left border of the input area is set equal to the moving space left x variable in step S188 and the right border of the input area is set equal to the moving space right x variable in step S190. The circular list is then emptied in step S192 and the method is complete. Additional steps are required, however, when the moving space is collapsed, as shown in FIG. 18B. If the input area was equal to the moving space, the current input line is set to be undefined in step S200. Once a current input line is established, subsequent strokes are examined to see if the current input line has changed. As long as subsequent strokes are contained at least partially in the current input line space and the horizontal positions of the strokes are at least partially within a predetermined horizontal area (the input area), the strokes will be rooted in the current input line. When a subsequent stroke does not touch the current input line or is not within a predetermined horizontal area, the current input line becomes undefined. Once the current input line becomes undefined, the dynamic targeting method resorts back to the initial rooting method. With the document line established, the relative position of the stroke within the line must be determined. Due to the nature of the stroke compression method used to store strokes (it stores points within a stroke relative to the first point of the stroke), only the first point of a stroke needs to be assigned a position within the document line. The position will be relative to the line's left margin for the X-axis and relative to the bottom-most "raster" row owned by the document line for the Y-axis. This position can be identified by relative coordinates X' and Y'. The actual X and Y values used to anchor the stroke within a document line are determined using the following equations: X: window X coordinate for first point in stroke Y: window Y coordinate for first point in stroke X'=X-left margin window X coordinate for the document line Y'=Y-((FRR+1)-(WL*RRPL)) in which: FRR=First Raster Row; WL=Window Line; and RRPL=Raster Rows Per Line Now that the coordinates used to anchor a stroke within a document line have been determined, the next step is to compress the remaining points of the stroke. Any compression algorithm used must retain the point-to-point directional information inherent in strokes if those strokes are to be translated into ASCII text or used to characterize handwriting at some point in the future. The basic assumption behind the processor compression algorithm is that strokes have momentum--a stroke is more likely to continue moving in a specific direction than it is likely to move in a dramatically different direction. This allows compression of a stroke by representing point increments within the stroke with predefined values that reveal any change in direction. For instance, the binary value 1 would mean: continue forward one point in the current direction. The binary value 00 would mean: move forward and to the left of the current direction by one point, causing the current direction to be redefined by the new direction. The binary value 01 would mean: move forward and to the right of the current direction by one point, causing the current direction to be redefined by the new direction. Visually it might look like FIG. 6B. EXAMPLE 1 The arrows in FIG. 6B represent the current direction after the point at each arrow position has been encoded. The initial direction from starting point "x" is encoded per the binary values shown in FIG. 6C. The actual encoding of the circle shown would be a concatenation of the following binary directional data:
01011 Point count in stroke less 1 (Note: This is the binary length
of the stroke; it can be up to, e.g., 32 data points)
000 Direction from starting point "x" to point 2
(Note: the starting point is recorded as an X-Y coordinate. This
is the "root" point of the stroke. This direction is the
current direction at point 2.)
01 Direction change needed to get to point 3
(Note: 01 shows a change to the right; 00 would be to left.)
1 Continue in current direction to get to point 4
01 Direction change needed to get to point 5
01 Direction change needed to get to point 6
1 Continue in current direction to get to point 7
01 Direction change needed to get to point 8
01 Direction change needed to get to point 9
1 Continue in current direction to get to point 10
01 Direction change needed to get to point 11
01 Direction change needed to get to point 12
25 bits
This algorithm requires that all points in a stroke be adjacent. There can be no gaps or adjacent points having the same coordinates (duplicate points). In order to assure that there are no gaps, a line drawing algorithm is employed to fill any gaps in a stroke (typically due to moving the pen too fast) with a straight line before any attempt is made to compress the stroke. To remove duplicate points, which typically result from digitizing at high resolution and translating to a lower resolution, any duplicate points exceeding one are discarded at each position. In order for this type of compression to be most efficient, the digitized strokes need to be smoothed. For instance, extraneous points, which result from digitizing at high resolution and translating to a lower resolution, need to be removed before the compression algorithm is applied. These extraneous points can be detected by searching through each stroke for formations that give the appearance of an "L" (two lines meeting at right angles. This search uses the matrix shown in FIG. 6D. An "L" formation in FIG. 6D would be any series of points that fall into a 1, 2, 3 sequence. As a stroke is compressed, each point of the stroke (actually each point that is retained after the "L" formation lookahead) takes its turn in the "1" position. If the following 2 points make an "L" formation, then one of them must be discarded. The point to be discarded is determined by examining the position of a 3rd point following the point in the "1" position. This third point is not shown in FIG. 6D but could appear anywhere within the matrix (except in the "3" position because duplicate points have been removed) or a surrounding ring of points around the matrix. Of the points in the "2" and "3" positions, the one farthest from the third point (i.e., the point requiring the largest change in X and Y coordinate values to reach the third point) is discarded. The compression algorithm as described requires that strokes exceeding 32 points (only 5 bits in point count) be broken into a series of "ministrokes." It also requires strokes having too radical a change of direction for direction change encoding to be broken into ministrokes, as in the case of a script "M." The resulting ministrokes are compression encoded as described above. Alternatively (or also), the stroke length could be set at 64 points (6 bits) or more for higher resolution digitizers. These encoded ministrokes are then concatenated to form the whole stroke, the last point of each ministroke being the `start point` of a succeeding ministroke. The main drawback of the original method is that it usually does not compress as well as the patented method. The extra bit used to indicate `no change in direction` combined with the 2 bits used to indicate the end of the stroke will usually exceed the number of bits required to encode the stroke length required by the patented method. Another drawback is that the entire compressed stroke must be traversed in order to determine its length and thus its storage requirement. Its is easier to compress a stroke `on the fly` using the original method because there is no need to backtrack and store a point count. If a fixed number of bits are allocated for the point count in the patented method, the original method might be able to encode as a single stroke as series of ministrokes that were encoded using the patented method. This would only occur if the ministrokes could not be represented as a single stroke because the point count overflowed. A variation on this stroke compression method allows for compression of strokes having less momentum (i.e., many closely spaced direction changes). An expanded set of encoding values is employed: EXAMPLE 2 1: Move forward one point in the current direction 000: Move 1 point counterclockwise from the current direction and forward. The new direction becomes the current direction. 001: Move 2 points counterclockwise from the current direction and forward. The new direction becomes the current direction. 010: Move 1 point clockwise from the current direction and forward. The new direction become the current direction. 011: Move 2 points clockwise from the current direction and forward. The new direction becomes the current direction. After bridging gaps within a stroke, removing duplicate points and discarding extraneous "L" pattern points, the circle used in the first compression example would be compressed and encoded as follows: 01011 Point count in stroke less 1
000 Direction from starting point to point 2
010 Change direction to right to get to point 3
1 Continue in current direction to find point 4
010 Change direction to right and down to get to point 5
010 Change direction to down to get to point 6
1 Continue in current direction to get to point 7
010 Change direction left and down to get to point 8
010 Change direction to left to get to point 9
1 Continue in current direction to point 10
010 Change direction to up and left to get to point 11
010 Change direction to up to get to point 12
32 bits
As can be seen, the first compression method compresses the example stroke much more than the second compression method. This will not always be the case. Certain strokes will be compressed more using the second method rather than the first, for instance a stroke that varies more widely in direction than the example stroke. The point is that the program can analyze the stroke characteristics before applying a certain compression method to the entire stroke or a ministroke constituting a portion of the entire stroke. What have been described are single pass methods for compressing strokes. A second compression pass can be applied to the compressed strokes, thus obtaining greater compression at the cost of additional compute time. In the examples shown, the repeating patterns of directional change can be compressed, using any of a variety of known pattern compression techniques. The program would determine whether any additional compression passes would be warranted.Returning to the original task of describing how strokes are processed and stored in the software system, let us review what has been covered: Mapping a stroke on the screen to a document line; Determining the line relative coordinates of the stroke within the document line; and Compressing the stroke. What remains is a description of the approach used to store strokes within the document line data structure. A document line consists of two distinct writing areas--the lined area and the unlined or margin areas. Within the margin areas, word wrapping is not supported; as such, strokes need merely be appended to a growing list of strokes associated with the document line. That is, the strokes are ordered by time. Strokes within the lined area are stored differently due to the word wrapping nature of the lined area. See the discussion below on Break Point Gap Analysis: The Leftmost Positioning Method for details of the stroke ordering and storage. Representation of ASCII Characters in a Format Compatible with Strokes Binary encoded characters (e.g. ASCII characters) by definition are graphically defined elsewhere. There is no need for the processor to duplicate this information by storing it in a compressed stroke or bitmap format within the data structures comprising a line. The pieces of information that the processor needs in order for it to represent ASCII characters in a format compatible with strokes are: The ASCII character code; The position of the ASCII character within the document window; Font and point size information. The position of the ASCII character is determined by the processor using standard text spacing algorithms for downloaded ASCII text. For ASCII text that resulted from the translation of script, the processor replaces the script with ASCII text as the translation takes place. This typically results in a shrinkage of the script since the ASCII text characters will usually be smaller than the script characters and the user normally requests that consistent and standard spacing exist between characters within a word and between words within a sentence. The position of the ASCII character, its font, and its point size are used to determine the character's starting point (origin), left-most point, and right-most point positions relative to the lined area beginning points along the left margin. This is the same sort of information that is maintained for strokes. Because strokes, ASCII characters and bit-mapped images are ordered by left-most point position, ASCII characters can be interleaved with strokes within the processor data structures, allowing for the consistent application of editing functions to the mixed data types. The processor must be aware of the distinction between data types when it must display the data. The stroke visual data will be derived from the compressed strokes and the ASCII character image will be extracted from a table addressed by ASCII character code. FIG. 9 shows that an "o" could exist in a pen-based system according to the invention as a stroke, an ASCII character, or a bitmap. At the simplest level, data within the system exists as a series of glyphs, each having a starting point (origin), a left-most point position, and a right-most point position. The starting point (origin) is used to position the glyph within the line space. Since the left-most and right-most point positions are encoded relative to the starting point position, they are automatically moved whenever the starting point position is moved, i.e., the stroke/character is shifted left/right. The left-most and right-most point positions are used to determine the breakpoints within a line (the word boundaries) as described above. The only time that the processor is (and needs to be) aware of the specific type of glyph (stroke, ASCII, or bitmap) is when it stores the glyph, when it determines word boundaries, and when it displays the glyph. At these times, glyph-specific data is required. Note in FIG. 9 that the starting point is not really glyph-specific even though it varies with glyph type. It still represents the anchor position for all glyphs and among all glyph types it is the point that moves. In FIG. 9, all glyph types have the same left-most and right-most point positions (1 and 6 respectively). For purposes of determining word boundaries and word wrapping, these are the important variables. Break Point Gap Analysis: the Left-most Positioning Method In both hand printed and typed (or computer processed) documents, words are separated by a larger amount of space than that which separates characters within a word. The larger amount of spacing between words is the basis on which the invention determines word breaks, and accordingly, word wrap. The invention employs a novel method for determining stroke-character word breaks. This method is referred to as the Left-most Positioning Method (LPM). LPM orders stroke images within a given line according to their left-most point position. Once a text line has been detected, LPM relies exclusively on a single axis for acquiring stroke positioning data. Therefore, strokes are ordered left to right in a stroke database. The time order of strokes entered can be maintained by time-stamping the strokes. The Break Point Gap (BPG) value is predetermined at the outset of stroke position data capture. The BPG is calculated as a predetermined two dimensional area of points (a parallelogram such as a rectangle). For highly slanted text, a user-modifiable angle for the parallelogram can be determined from the user's writing. As stroke data is captured, LPM relies on the BPG value for determining a word break. LPM performs a comparison between the (white space) value of the space between the right-most point position of the preceding stroke data, and the left-most point position of the current stroke data, with the BPG value. If the white space value is greater than or equal to the BPG value, then the LPM has detected a word break. Accordingly, LPM inserts a break point marker B (see FIG. 5B) at a location adjacent to the left-most point of the current stroke data. If a user-modifiable slanted parallelogram is used, the LPM, the right-most and left-most point positions are determined according to the angle of the break point gap detection parallelogram. This implies that the left-most and right-most point positions maintained for each glyph will have to be recomputed if the detection parallelogram being used with the glyphs undergoes a change in slant. Word Wrapping: Employing the Break Point Marker Word wrapping is the process of filling lines of text and/or script and moving text/script that overflows the line space contents automatically to the succeeding line space. Word wrap is not mandatory until a text/script manipulation event occurs. When the system detects a text/script manipulation event, then word wrapping is invoked. The word wrapping detection method involves "re-flowing" the text/script across line breaks. This is preferably done by comparing locations of break point markers (B in FIG. 5) with line delimiters (beginning and ending points 36, 38). If a stroke is detected as crossing the address of a line delimiter (or margin boundary), a word wrap is required. To wrap, the system parses backward searching for the last break point marker. Upon finding said marker, the system moves all text immediately following the marker to the succeeding line, and recursively applies the check for a margin boundary violation and again wraps the text/script until all text/script has been reflowed within the lines such that no strokes violate a margin boundary. An alternative implementation would function as follows: Stroke data would continue to be added to the database, while the system compares the amount of data captured with the amount of line space allocated. As soon as stroke data is captured which, if placed on the current line, would exceed the margin boundary, a word wrap would be required. The actual wrapping would be triggered by some event or action that indicated the user had finished writing on the line. To wrap, the system would employ the recursive process described above. WrapGap Analysis: The WrapGap Monitoring Method Another of the many problems addressed by the invention involves maintenance of designated space between words. When editing script text, a means is required for adding and/or deleting white space to accommodate additional stroke data (more handscribed text). To facilitate managing the white space between words, a variable called WrapGap is maintained that records the amount of white space between the left-most point of the first stroke of a word on a line and the right-most point of all strokes composing words on the preceding line, whenever the current line is viewed as an extension of the preceding line (i.e., no intervening BOL). By default, each line is assigned a WrapGap value that is equal to the BPG value. When word wrapping forward occurs, the WrapGap value shown graphically in FIG. 5B indicates the amount of space that must exist between the right-most point of the first word wrapping to a line and the left-most point of the first word currently on that line. The WrapGap must then be changed to reflect the spacing between the left-most point of the left-most wrapped word on a line and the right-most point of its former neighboring word on the preceding line. When the user deletes space or strokes, causing words to wrap backwards, the WrapGap value indicates the amount of space that must exist between the right-most point of the last word on the line where words will be wrapped back to and the left-most point of the first word that will wrap back to that line. The WrapGap must then be changed to reflect the amount of space between the right-most point of the last word wrapped back to a line, and the left-most point of the newly positioned first word on the succeeding line (where the words wrapped from originally). Another common case in which this feature is apparent is when changing line lengths (side margin widths). This case is shown in FIG. 5B, in which a line of script is shortened in successive steps and then returned to its original length. There are two additional cases where the WrapGap value can be modified. Whenever a word wraps, a new WrapGap value for the line is computed. In the first case, a word may wrap because a significant amount of space is allocated preceding the word. Subsequently, a new word may be added on the preceding line within the previously allocated white space. Therefore, the actual (desired) space or gap between the word beginning on the subsequent line and the word on the preceding line, has changed. This value is no longer the original value allocated between the last right-most point position of a preceding word and the left-most point position of the wrapped word. Rather, it should now be the value between the right-most point position of the added word and the left-most point position of the wrapped word. In this way, if a margin is subsequently increased, and/or some other editing function forces the wrapped word to return to the preceding line, or the added word to wrap onto the subsequent line, the actual space between the added word and the originally wrapped word will be properly maintained because the WrapGap value has been updated to reflect the modification. The user will have the option of disabling this WrapGap adjustment feature. Another case for WrapGap value modification occurs when the user employs a "delete-space" gesture (refer to the discussion on "Gesture-Based Editing" below) following all strokes on a line space. With this gesture, the user causes words from the next line space to wrap back to the current line space. If there is a "Beginning of Line" (BOL) marker on the next line space, it will be removed. The system then determines whether the space consumed by the first word on the next line plus the break point gap (BPG) value represents an amount of space less than or equal to the open space available at the end of the line where the gesture was made. If so, then the system detects that at least one word can be wrapped-back and, therefore, proceeds to reduce the WrapGap for that word only enough (if at all) to ensure that such word will wrap backwards (e.g., return to the preceding line space.) A variation on this method would use the pen-up X-coordinate position of the Delete-Space gesture as the target position (or location) to which the left-most point of the first wrapped-back word should be "anchored." In such case, the WrapGap value for the first word to be wrapped back could be ignored. Only the space consumed by the strokes at the first word would be considered in determining whether the word can be wrapped back. If the word will fit within the space existing between the pen-up location and the right margin, the WrapGap value for the first word effectively becomes equivalent to the space existing between the right-most point of all strokes on the wrap-back line and the pen-up location. EXAMPLE 3 FIGS. 7A through 7U show a series of screen displays for an operative example of the invention as implemented in a computer system arranged as in FIG. 1 with a stylus and contact and proximity-sensitive digitizer as the graphics input device. The document display is shown on a conventional graphics CRT monitor and the computer is a conventional Intel 386-based personal computer. The following figures show a basic subset of the operations that can be performed on a document display in accordance with the invention. This example shows the interactive manipulation of printed script, cursive script and small sketches within the lined area of the document display, and of drawings and script within the unlined or drawing areas and margins of the display. Although not shown in this example, ASCII text placed in the lined area will be handled and will behave during manipulation in essentially the same manner as script, and can be considered as represented in this example by the printed script. FIG. 7A is a view of an initial screen display in which printed and cursive script have been manually entered by writing on the digitizer with a stylus. The document display 30 itself includes a top display margin, bounded by a pair of closely-spaced lines, containing title and command or menu lines. All actions in these areas are treated as commands and do not result in the entry of script. Besides, or instead of menu titles "edit" and "services," the command line can include icons (not shown). Below the double line is the display document itself, which is organized in pages. As shown in FIGS. 7 and 7A, the default structure of each page of the display has a series of parallel horizontal lines 34, each having vertically aligned beginning points 36 and end points 38. The lines themselves each define line spaces 39 of equal vertical width. The beginning and end points of the lines are spaced inward from the sides of the display to define the lengths of the lines (which can be varied) and width of left and right margins 40, 42 (which are likewise variable). The first line is spaced three line spaces below the top of the document display space defined by the double line. The spacing of the first line below the double line is sufficient to provide a single line space above the first line into which script or text can be entered and two additional line-space widths to serve as a top margin 44. A bottom margin 46 having a width of two line spaces is also provided. The top and bottom margins 44, 46 are treated as unlined space in the same manner as the left and right margins 40, 42. The top, bottom and left and right margins define an unlined drawing area which surrounds the lined script area. The margin areas can be slightly shaded to help distinguish them from the script lines. Referring to FIG. 7B, the "insert space" gesture command has been performed in the first line of the script, immediately after the printed script. This was done by placing the cursor between the printed script and the first word of the cursive script, holding the stylus momentarily in one place in contact with the digitizer surface; then moving the stylus tip rightward to an end point spaced inward from the ending point of the line, and lifting the stylus. This action has opened a length of line space defined by the length of the gesture in the first line. The computer document display has also responded to this action by pushing the script to the right of the insert point of the gesture toward the right in the first line, wrapping down into the second line and rightward in each successive line. After completion and execution of the insert space gesture, the user drew/wrote a large dot with a rightward-directed arrow, followed by the words "Insert Space Gesture" in printed script, into the space that had been opened by the gesture. FIG. 7C shows editing of the text inserted in FIG. 7B. This is done by performing a "delete space" gesture, commencing after the word "insert" in FIG. 7B and extending leftward to the beginning of the arrow shown in FIG. 7B. This was followed by an "insert space" gesture to reopen space that the "delete space" gesture consumed. Then, a leftward-directed arrow was drawn in place of the rightward-directed arrow and the word "delete" was written where "insert" previously appeared. Operation of the delete space gesture is further illustrated in FIG. 7D. When this gesture, or any gesture is performed, placing and momentarily holding the stylus in place on the digitizer causes the display to show a filled circle at the pen down location (after "gesture" in line 1). The filled circle serves as a "gesture prompt" to provide feedback to the user that the input device is now operative in the gesture mode. As soon as this gesture prompt is displayed, the user then drags the stylus leftward along the line space to be closed. The version of software operated in the present example actually draws a line through the space to be closed (and across the text to be deleted). This illustrates the principle of the two-part gesture prompt/gesture command structure, but display of the gesture is not essential. Alternatively, the command can be executed as the gesture is being made, as soon as the gesture's direction is determined. After executing the delete space gesture, the system closed the line space between the gesture prompt and the end point of the gesture, obliterating the text contained in the line space between such points. A variation on the Delete Space gesture has the strokes following the gesture on the line (if any) being left-justified at the pen up position for the gesture. Another variation has the strokes following the gesture on the line (if any) being left-justified at the left-most point position of any deleted strokes (i.e., the following strokes take the place of the deleted strokes). These variations enable easy maintenance of word spacing. FIG. 7E shows the operation of the "insert BOL marker" gesture and its corresponding editing function. This editing gesture and function was performed after the word "script" in line 1. It has the effect of adding a beginning of line (BOL) marker at the insert location, that is, at the location where a gesture prompt appears upon commencement of the gesture, and then moving the affected text to the beginning (left margin) of the next line. Actually, all text on the line following the gesture prompt position is wrapped forward to the next line, that line then being prefixed with a beginning of line (BOL) marker. As the user continues to move the stylus downward across additional lines, the affected text moves with the stylus, leaving BOL-marked blank lines to fill the gap created by moving the text downward within the document. This can be seen by comparing FIGS. 7D and 7E. FIG. 7F shows the same line, after doing a sketch of the gesture and a brief description of the gesture's function. FIG. 7G illustrates what will be done to close the added line. As the edited display of FIG. 7G states, the user executes a delete line contents gesture by placing the stylus on the point of the digitizer corresponding to a point on the second line of the display and, after receiving the gesture prompt, moves the stylus upward toward the first line. FIG. 7H shows the screen display after execution of the delete line contents function. The third line of script is moved up into the second line, obliterating the script contents of the second line, and is followed by an upward shift of the contents of each subsequent line space. This editing function can be used on multiple lines of text. As mentioned above, the document display preferably includes multiple pages. The pages are not isolated from one another, however, but permit script to be moved freely back and forth across page break boundaries. This is shown in FIG. 7I. To illustrate the point, the previously-entered script has been shifted downward (using the insert blank line function) to the bottom of the first page. Then, an insert moving space gesture was carried out in the third line of script immediately preceding the word "principles" to cause the last few words of script to word wrap off the end of the last line of the first page. In word wrapping, these words were pushed over the bottom margin, page break and top margin onto the first line of page 2 of the document display. FIG. 7J shows the effect of entering additional script commencing at the point of the insert moving space gesture in the third line of script on page 1. The user has entered additional printed script, much as one would do in editing a document. Rather than filling a space of fixed length, however, using the insert moving space function causes space continually to be added to the lines ahead of the user's entry of script. Thus, the user has entered nearly two lines of script, extending over the page break onto the first line of page 2. Note that a length of open line space remains immediately preceding the word "principles," which space is the moving space defined by this function. Thus, the moving space as well as the text downstream from it is wrapped not only around ends of lines but across page breaks and margins. In doing so, the contents of the margins (none shown) are unaffected. FIG. 7K shows closure or collapsing of the moving space, accomplished in the current implementation by attempting any gesture, including another insert moving space gesture. When a moving space is collapsed, the spacing between the left-most point of the strokes following the moving space and the right-most point of the added strokes will be the space that existed between the initial strokes that were separated by the moving space. This means that if the space is opened within a word the open moving space will be collapsed to a smaller whitespace gap than if the space had been opened between words. A variation on the moving space concept has the moving space sensitive to proximity. After moving space has been opened with the Insert Moving Space gesture, the moving space would collapse on pen-out-of-proximity and reopen on pen-in-proximity. This would allow the user to make multiple edits using moving space without having to explicitly open and close the moving space. When the moving space reopens, the position of the moving space within the text would reflect the position of the stylus in proximity. In this way the user could move the stylus around to preview various insert positions within words or lines. When pen down occurs, the moving space would shift according to the user's entered strokes. The Collapse Moving Space gesture (same as Insert Moving Space gesture) would end this process. Another variation on the moving space gesture has the action of moving the pen to a vertical orientation causing a Moving Space Gesture prompt. The prompt would be an open space that would move with the pen (pen-in-proximity but not touching) as the user previewed moving space insertion positions within text. (The user need not hold the pen vertical once the prompt appears.) Pen-down would be the gesture that actually created a moving space. Until pen-down, insert positions would be previewed at varying degrees of resolution. Fast pen movement would preview insert positions between words and slow pen movement (over words) would preview insert positions within words. Returning the pen to the vertical position (after having been not vertical) would cause the moving space to be collapsed. If the pen tip had not been within (over) the moving space when the pen was positioned vertically then a new moving space would preview at the pen position. As mentioned above, drawings can also be included in unlined areas of the document display and are not affected by editing functions performed on the contents of the lined area. To illustrate this point, FIG. 7L shows the previously-entered script moved back to the top of page 1. The "services" menu item has been invoked, followed by selection of the "insert ruler" command. FIG. 7L shows use of this command to cause two rulers to be drawn across the document display at about mid-screen. The rulers are shown as black horizontal bands across the document display. The final version of the product will have rulers containing graphics depicting the current margin settings. The top ruler is always present (although it may be hidden) and contains margin settings which can be set by the user wider or narrower than the default margins. The lower two rulers are placed by the user at locations designated by contacting the stylus to the digitizer at user-selected points. Next, referring to FIG. 7M, using the stylus, the user selects a new line length within the area defined vertically between the lower two rulers. In the present software version, the user affirmatively selects the line length by drawing a gesture on the ruler from the left or beginning point of the line to a desired end point of the line. This procedure could be reversed, to define the margin or drawing area width between the rulers. Alternatively, an icon representative of this function could be provided which the user selects and simply draws a line vertically from top to bottom at a desired location along the lines to define the height and width of the lined space (or conversely the unlined space). This approach would automatically insert and position rulers where the user starts and stops the vertical line. Reinvoking the "services" menu and selecting "hide rulers," leaves the document display of FIG. 7N. To illustrate subsequent points, the user has drawn a diagram of a pen-based computer in the unlined drawing area and has labeled the diagram "pen-based computer." FIG. 7O shows the document display of FIG. 7N as the user makes a delete space gesture across some of the script in the second line of the display. FIG. 7P shows the display after execution of the delete space function. This causes the contents of subsequent lines to word wrap or reflow upward to fill in the space occupied by the deleted line space contents. Note that reflow of the line contents has no effect at all on the drawing and script labeling within the unlined drawing area. As mentioned above, the gesture commands are context sensitive, dependent on where they are located, and will cause different things to happen if located in the unlined area than if located in the lined area. FIG. 7Q shows an "insert lines" gesture performed i | ||||||