FIELD OF THE INVENTION
The present invention relates generally to computer devices, and more particularly computer devices arranged to receive handwritten input.
BACKGROUND OF THE INVENTION
Contemporary computing devices allow users to enter handwritten words (e.g., in cursive handwriting and/or printed handwritten characters) and symbols (e.g., a character in Far East languages). The words and symbols can be used as is, e.g., to function as readable notes and so forth, or can be converted to text for more conventional computer uses. To convert to text, for example, as a user writes strokes representing words or other symbols onto a touch-sensitive computer screen or the like, a handwriting recognizer (e.g., trained with millions of samples, employing a dictionary, context and other rules) is able to convert the handwriting data into dictionary words or symbols. In this manner, users are able to enter textual data without necessarily needing a keyboard.
However, contemporary recognizers are too processor-intensive to use continuously, particularly with small hand-held (pocket-sized) personal computers. Instead, the devices are configured such that users can request recognition when desired, or such that the recognizer operates only in the background so that the users do not have to wait for recognition on a word-by-word basis. Moreover, some recognizers are configured to use the context of surrounding words or symbols to help determine other words or symbols, and thus waiting to recognize groups of words often provides more accurate recognition.
At the same time, however, the user may wish to edit words and symbols before they have been recognized, e.g., delete a word, insert a word between two others, format a word, move words around, and so forth, such as by cutting and pasting. Also, the system needs to know when to wrap handwritten data to the next line, and needs to maintain this information as the user zooms the display in and out. As such, some relatively lightweight, initial ink processing is performed to parse the input data into various segments, without involving the recognizer. This initial processing may be orders of magnitude faster than full recognition, but has problems, however, in that because it only looks for limited characteristics via some fuzzy rules, the distinct segments initially determined may not actually correspond to the distinct words or symbols that the user intended. Thus, as a user edits words and zooms in and out, the user may undesirably find that what was intended to be one word is treated as two, two words treated as one, and so forth.
SUMMARY OF THE INVENTION
Briefly, the present invention provides a method and system that corrects for parser segmentation errors by sending an entire line of ink to a recognizer, and then comparing, on a word-by-word basis, the initial segmentation guesses of the parser with the more-thoroughly recognized segmentation results of the handwriting recognition engine. In the correction process, the ink words are efficiently adjusted with relatively little data manipulation. More particularly, the recognizer is fed a series of strokes on a line, in order, from which the recognizer returns its segmentation information. For ink word breaks that are the same between the ink parsing and the recognizer for any given set of data, the existing ink word is unchanged. For ink words that are recognized differently, a new ink word is created and the handwriting (including stroke) data of the parser's ink word is manipulated to create a new ink processor word (or words) to match the recognizer output.
The present invention thus retains the desirability of rapidly grouping sets of strokes into segmented ink word units as they are written, without first requiring complete recognition, for example for word processing (editing and zooming) purposes, and so forth. However, once recognition is performed, the segmentation performed by the lightweight parser, which is generally not as accurate as the segmentation performed by the recognizer, is efficiently and flexibly corrected by a data manipulation process to match the recognizer's output.
Other advantages will become apparent from the following detailed description when taken in conjunction with the drawings, in which:
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram representing one exemplary computer system into which the present invention may be incorporated;
FIG. 2 is a block diagram generally representing components and data structures for handling electronic ink handwritten into a computer system and capable of implementing the present invention;
FIG. 3 is a representation of how handwritten data and text data is generally maintained by the ink processor;
FIG. 4 is a representation of the contents of an example text buffer and how it is displayed to a user;
FIG. 5 is a representation of handwritten data as entered by a user and initially segmented into ink words after parsing by a ink processing mechanism;
FIG. 6 is a representation of the handwritten data of FIG. 5 after parsing and zooming to emphasize the need for correcting the segmentation in accordance with one aspect of the present invention;
FIGS. 7 and 8 are representations of data structures used by the present invention to analyze and correct for segmentation differences in accordance with one aspect of the present invention; and
FIGS. 9 and 10 comprise a flow diagram generally describing a process for analyzing and manipulating the data structures to correct for segmentation differences in accordance with one aspect of the present invention.
DETAILED DESCRIPTION
Exemplary Operating Environment
FIG. 1 illustrates an example of a suitable operating environment 20 in which the invention may be implemented. The operating environment 20 is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Other well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures and so forth that perform particular tasks or implement particular abstract data types. Typically the functionality of the program modules may be combined or distributed as desired in various embodiments.
Computing device 20 typically includes at least some form of computer readable media. Computer-readable media can be any available media that can be accessed by the computing device 20. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by the computing device 20. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.
FIG. 1 shows functional components of one such handheld computing device 20, including a processor 22, a memory 24, a display 26, and a keyboard 28 (which may be a physical or virtual keyboard). The memory 24 generally includes both volatile memory (e.g., RAM) and non-volatile memory (e.g., ROM, PCMCIA cards, and so forth). An operating system 30 is resident in the memory 24 and executes on the processor 22. The handheld personal computer 20 includes an operating system, such as the Windows® CE operating system from Microsoft® Corporation or other operating system.
One or more application programs 32 are loaded into memory 24 and run on the operating system 30. Examples of applications include email programs, scheduling programs, PIM (personal information management) programs, word processing programs, spreadsheet programs, Internet browser programs, and so forth. The handheld personal computer 20 may also include a notification manager 34 loaded in the memory 24, which executes on the processor 22. The notification manager 34 handles notification requests, e.g., from the application programs 32.
The handheld personal computer 20 has a power supply 36, which is implemented as one or more batteries. The power supply 36 may further include an external power source that overrides or recharges the built-in batteries, such as an AC adapter or a powered docking cradle.
The exemplary handheld personal computer 20 represented in FIG. 1 is shown with three types of external notification mechanisms: one or more light emitting diodes (LEDs) 40 and an audio generator 44. These devices may be directly coupled to the power supply 36 so that when activated, they remain on for a duration dictated by a notification mechanism even though the handheld personal computer processor 22 and other components might shut down to conserve battery power. The LED 40 preferably remains on indefinitely until the user takes action. Note that contemporary versions of the audio generator 44 use too much power for today's handheld personal computer batteries, and so it is configured to turn off when the rest of the system does or at some finite duration after activation.
Matching Ink Processor and Recognizer Word Breaks
FIG. 2 represents general components and data structures of the computing system 20 when configured for handwriting recognition in accordance with one aspect of the present invention. In FIG. 2, as a user enters data such as by typing or by handwriting data on the touch screen display 26, input circuitry and/or other components 50 pass the information to the operating system 30. Depending on the state of the system and/or where the screen is contacted, the user input may be converted to text by the operating system or treated as handwritten data. For example, when the screen has a representation of a keyboard displayed thereon and that keyboard is touched, the coordinates may be converted to an ASCII or Unicode character, or an editing command, and sent to an appropriate component (e.g. word processor) to use. Alternatively, if the user is writing in a handwriting input area, the input circuitry 50/operating system 32 passes the data to an ink processor component 54 to process and otherwise handle the electronic ink data. Note that a user may enter the handwritten data (electronic ink) in another manner, such as via a tablet connected to a personal computer. As described below, one of the operations performed by the ink word processor is to initially segment the handwritten data into separate ink words for display on the display 26 via output circuitry/components 56.
As is understood, the handwritten data may be in the form of coordinates, and may include other information, e.g., pressure data, timing data and so forth. The ink processor component 54 may comprise an application program, or alternatively may be a subcomponent of or integrated into the operating system 30. The ink processor 54 may also be arranged to pass characters, (e.g., Unicode), whether typed or recognized from words or symbols, to conventional applications that can only deal with characters. For purposes of the present description, the ink processing component 54 will also perform the operations of a conventional word processor, e.g., handle both recognized text and unrecognized ink, allow the editing of words, both text words and handwritten words, update the display 26 (e.g., to word-wrap, mark or insert text or words, delete words) as appropriate, and so forth.
To initially segment the handwritten data into separate ink words, the ink processor 54 includes (or is otherwise associated with) an ink parsing mechanism 58. This segmentation is performed in an initial pass, before the ink data (and/or ink feature information) is passed to a handwriting recognizer 60 for conversion to recognized text or symbols. Segmentation enables the system to rapidly (relative to the time it takes for handwriting recognition) treat the data as separate words, including for editing and display (e.g., word wrapping) purposes.
As generally represented in FIG. 2, the ink processor 54 maintains one or more text buffers 62 1-62 m. Each text buffer (e.g. 62 1) is a data structure storing some or all of the contents of a document, such as individual letters, spaces, inked words, and drawings. For example, a text buffer can store the entire contents of a document, or each of a plurality of text buffers can represent one paragraph in a document.
To indicate an inked word, the text buffer (e.g., 62 1) also contains special codes that indicate the locations of ink words 64 1-64 n relative to text and other items in the text buffer 62 1. Each such code is directly followed by a pointer to the ink word data structure (sometimes referred to as a scrawl) that contains the ink data for that word.
By way of example, FIG. 3 represents a text buffer (e.g., 62 1) with memory (e.g., bytes) for text, possibly other items, and special ink word codes (IW1 and IW2), each code followed by its respective pointer to ink words 64 1-64 2. As shown in FIG. 3, the pointers are two bytes in length, but of course pointers of other sizes are feasible. FIG. 4 shows how the text buffer 62 1 (shown in FIG. 4 as a linear array) and its ink word data structures 64 1-64 2 may be interpreted by the ink processor to result in a particular display, prior to the two ink words 64 1-64 2 having been recognized as text by the recognizer 60.
As generally represented in FIG. 3, each ink word, such as the ink word 64, is a data structure having a header 66 which describes the ink data section 68 following it. In addition, other fields are possible, such as an other data field 70 followed by a tail structure field 72 that describes the other field 70. For example, the other field may include a list of alternates and probability information associated with those alternates returned by the recognizer 60 following recognition. Note that alternates are only described herein for completeness, and as will be understood, are not necessary to the present invention. The maintenance and use of the alternates, and the tail structure, are further described in related copending U.S. patent applications Ser. No. 09/644,002 entitled “Method and System for Handling the Selection of Alternates for Recognized Words”Ser. No. 09/643,414 entitled “Method and System for Maintaining Alternates in Association with Recognized Words”; Ser. No. 09/643,617 entitled “Method and System for Searching for Words in Ink Word Documents”; and Ser. No. 09/643,997 entitled “Method and System for Extending Ink Word Data Structures while Maintaining Version Compatibility” filed concurrently herewith and hereby incorporated by reference.
The following table sets forth an ink word data structure (scrawl) including the tail structure:
|
// The Ink Word Structure |
typedef struct TXT_SCRAWL |
{ |
|
U8 |
flags; |
|
|
U8 |
candidateChoice; |
//index of chosen candidate |
|
|
|
//zero based |
|
INK_STYLE |
inkStyle; |
|
COORD16 |
width; |
|
U16 |
strokeCount; |
|
U16 |
bufferSize; |
|
U8 |
buffer[2]; |
//padded for alignment |
|
// first comes the array of strokes |
|
//then comes a double null terminated list of strings |
|
//at the very end is a TXT_SCRAWL_TAIL struct |
} TXT_SCRAWL, FAR * P_TEXT_SCRAWL; |
// this buffer is appended onto the scrawl to optimize |
// getting to strings. For compatibility reasons, it grows |
// from the beginning, not the end of the tail structure, |
// since a negative addressing scheme from the text scrawl |
// end is used to get to its members |
typedef struct TXT_SCRAWL_TAIL |
{ |
|
U32 |
tailStructVersion; |
//starts at 1 and grows |
|
|
|
//upwards; |
|
U32 |
stringAreaOffset; |
//offset from beginning |
|
|
|
//of TXT_SCRAWL to the |
|
|
|
//start of the double |
|
|
|
//null terminated string |
|
|
|
//list. |
|
U32 |
chosenStringOffset; |
//offset from beginning |
|
|
|
//of TXT_SCRAWL to the |
|
|
|
//chosen string. |
|
U16 |
wchFirstXlateChar; |
//first char of the |
// ADD ANY NEW MEMBERS AT THE END |
} TXT_SCRAWL_TAIL * P_TEXT_SCRAWL_TAIL; |
|
For purposes of simplicity herein, the present invention will primarily be described with respect to handwritten cursive words, using the English language for various examples. However, as will be understood, the present invention may operate with printed characters and symbols, and provides numerous benefits regardless of any particular language.
As generally described above, one of the things that the ink processor 54 does is to rapidly segment handwritten data into words so that prior to recognition, (if any) the words can displayed and manipulated as separate items, e.g., for word wrapping and editing purposes. By way of example, consider a user writing a note on the computing device stating, “We need to find out which flight to be on. This is critical to the timing of . . . ” As represented in FIG. 5, two lines of the display are shown, representing the user's ink (“ . . . be on. This is . . . ”), wherein in FIG. 5, the circled numerals correspond to separate strokes as determined by the ink processor 54, starting at number one for this second line. In a typical case, the ink parsing mechanism 58 will get the word breaks correct, whereby the user can select individual words or groups of words (e.g., for formatting cutting and pasting) that agree with what the user intended. One suitable ink processor that performs parsing is described in U.S. Pat. Nos. 5,517,578 and 5,613,019, hereby incorporated by reference.
However, in this example, because of the way in which this particular user has written the words, the ink parsing mechanism 58 incorrectly treats the two intended words “This is” as three distinct words, the first word being made up of strokes numbered one (1) and two (2), the second word being made up of strokes numbered three (3) through six (6), and the third word being made up of strokes numbered seven (7) through nine (9). Thus, the ink processor 54 creates three distinct ink word data structures to store the ink data for these three sets of ink. Note that the ink processor 54 has no concept of what the words mean, only that it has determined that there are three distinct words (symbols) for this set of ink. This will, for example, lead to incorrect word wrapping (relative to what the user intended) when re-zoomed, as generally represented in FIG. 6. Also, the user will be able to separately edit each of the three words, even though only two were intended.
Because the recognizer 60 uses far more complex processing, typically including dictionary checking, language models and so forth, the recognizer 60 is more accurate in determining the correct words, and thus the correct word breaks, that is represented by the ink. One suitable recognizer is described in U.S. Pat. Nos. 5,313,527 and 5,467,407, hereby incorporated by reference. However, as will be understood, the present invention will operate with any type of recognizer, including a speech recognizer.
In accordance with one aspect of the present invention, the ink processor 54 feeds the ink data to the recognizer 60 for recognition, such as one line at a time, with the line length being defined at the time the writing was entered by the user, i.e., prior to any zooming in or out. More particularly, the recognizer 60 is fed a series of strokes by the ink processor 54. The strokes on one line are fed at the same time into the recognizer 60, with a stroke identifier, in roughly the order in which it was written. The identifiers of the ink words used for recognition are saved for later. An application programming interface (API) call is used to pass the data, although as can be appreciated, other mechanisms for communicating the data to the handwriting recognizer 60 are feasible. Note that it is feasible to have another set of data passed (e.g., two lines of ink), and the size of the set can vary depending on circumstances such as how much the user was zoomed in while writing, user preferences, and so forth. It is also feasible to pass ink data to the recognizer more frequently, e.g., each time a pen up is detected, and also to pass two lines if the user writes a hyphen at the end of the line. Also, the ink processor 54 may pass its segmenting and other information to the recognizer 60, to assist it in its recognition, although this is generally not necessary.
In response, the recognizer 60 returns a series of ink word-break (scrawl break) structures representing what it thinks the word boundaries are, complete with a list of stroke identifiers. Since recognizers are not perfect, the recognizer may also return a list of probability-ranked alternates for the word, along with the probability information. Thus, a scrawl break is a data structure used to represent a word as determined by the recognizer 60. The following table describes the ScrawlBreak data structure:
|
// The ScrawlBreak structure includes the translation |
// results information that is needed to break up a scrawl |
// into multiple scrawls, one for each recognized word. |
// There is a contract of use/freeing - basically, it |
// will be filled in from xlate.c, and is completely |
// freed by the caller in txtBuf.c |
typedef struct tagSCRAWL_BREAK |
{ |
|
U32 |
strokeCount; |
|
|
HLOCAL |
hStrokeMem; |
|
P_U16 |
pStrokeIDs; |
// malloced array of length |
|
|
|
// strokeCount |
|
U32 |
xlateStrLen; |
|
HLOCAL |
hStringMem; |
|
P_U16 |
pXlateStr; |
// malloced string of length |
|
|
|
// xlateStringLen |
} SCRAWL_BREAK, FAR * P_SCRAWL_BREAK; |
|
The following table set forth the API and an interface used for describing the alternates for a word break
|
The api is described in this .idl file fragment |
|
uuid(10F294B0-D01F-11D2-870B-0000F8756F16), |
|
helpstring(“HwxPhraseTree Class”) |
|
] |
|
coclass HwxPhraseTree |
|
{ |
|
[default] interface IHwxPhraseTree; |
|
object, |
|
uuid(10F294A7-D01F-11D2-870B-0000F8756F16), |
|
helpstring(“IHwxWordGuess Interface”), |
|
pointer_default(unique) |
|
] |
|
interface IHwxWordGuess : IUnknown |
|
{ |
|
[id(1), helpstring(“Null seperated, double null |
terminated list of alternate translations”)] |
|
HRESULT GetAltList([out] long* pAltListLen, [out] |
|
[id(2), helpstring(“returns an array of stroke IDs |
|
HRESULT GetStrokeIDList([in, out] long* |
pnNumStrokes, [out, size_is(*pnNumStrokes)] short |
StrokeList[]); |
|
[id(3), helpstring(“scores for the alternates, in |
the same order as returned by GetAltList”)] |
|
HRESULT GetScores([in, out] long* pnNumScores, |
[out, size_is(*pnNumScores)] long Scores[]); |
The following table describes a way to walk the results tree for the first choice of phrase breaks:
|
object, |
|
uuid(10F294AF-D01F-11D2-870B-0000F8756F16), |
|
helpstring(“IHwxPhraseTree Interface”), |
|
pointer_default(unique) |
|
] |
|
interface IHwxPhraseTree : IUnknown |
|
{ |
|
[helpstring(“returns an array of addref-ed pointers to |
|
IWordGuesses for each word break”)] |
|
HRESULT GetWordGuesses([in, out] long* pnWords, [out, |
|
size_is (*pnWords)] IHwxWordGuess* WordGuesses[]); |
|
}; |
|
|
In accordance with one aspect of the present invention, and as generally represented in FIG. 7, the ink processor 54 includes a work break matching process 76 that compares the scrawl break structures (e.g., 78 X and 78 Y) returned by the recognizer 60 with its own word breaks, (as represented in the ink word data structures), to correct any segmentation errors. In general, if a scrawl-break structure has exactly the same strokes as an ink word data structure, then the existing ink word data structure is used as is, with any information (e.g., the list of alternate guesses returned by the recognizer in the scrawl break structure) ordinarily added to the to the existing ink word data structure. If instead the scrawl break structure is different than an existing ink word data structure, a new ink word data structure is created, with the strokes that compose this word taken from the existing ink word data structure or structures that make up this word. Note that in general, this requires keeping track of the absolute and relative location of each stroke in the document. During the process, once the set of strokes are removed from an existing ink word data structure, the existing ink word data structure is deleted, as are any spaces following it. Whenever a new ink word data structure is added, a new space object is calculated and inserted into the text buffer 62 to represent the space between this word and the following word.
FIGS. 7 and 8, along with the flow diagrams of FIGS. 9 and 10 further illustrate the matching process 76 generally described above. In the example shown in FIG. 7, the line of data of FIG. 5 corresponding the strokes that make up the phrase “This is” has been fed to the recognizer 60, which correctly recognizes the two words, and returns two scrawl break structures 78 X and 78 Y. As represented in FIG. 7, the scrawl break structure 78 X returns with information indicating that strokes one (1) through six (6) make up what the recognizer 60 has guessed as being the most likely choice for a first word, along with the text of the translated word and any other alternate candidates, generally ranked by and associated with probability information. Similarly, the scrawl break structure 78 Y returns with information indicating that strokes seven (7) through nine (9) make up what the recognizer 60 has guessed as being the most likely choice for a second word, along with its other translation information.
The flow diagrams of FIGS. 9 and 10 describe the matching process, beginning at step 900 of FIG. 9 wherein an array 80 of stroke match information data structures is generated. As will be described, the array 80 is used during the matching process to track the state of handling the strokes that were fed to the recognizer. The array 80 holds, for each stroke sent (e.g., in a single line to the recognizer), the ID of the ink word where it originally came from (A, B or C) in FIG. 7, a flag indicating whether it has been used yet, and the left and right boundaries of the ink word. As also represented at step 900, a pointer to the array 80 is moved to the first stroke, generally represented in FIG. 7 by the arrow pointing to “Stroke 1” of the array 80.
At step 902, the first scrawl break returned by the recognizer (representing the recognizer's first recognized word) is selected. In the present example of FIG. 7, this is the scrawl break 78 X. Then, step 904 checks to see if the ink word data structure matches the scrawl break strokes. In the present example, this is not currently the situation, (e.g., the strokes in ink word data structure 64 A are not the same as the strokes in the scrawl break structure 78 X), and thus the process branches to step 1000 of FIG. 10.
At step 1000 of FIG. 10, a new ink word data structure (64 D in FIG. 7) is created. Step 1002 represents the selecting of the first stroke in the scrawl break structure 78 X. For this stroke, the corresponding stroke data is moved from the existing ink word data structure 64 A into the new ink word data structure 64 D. Note that the array 80 tracks in which existing ink word data structure this stroke is found, 64 A in the present example. Then, the stroke is marked as handled in the array 80, e.g., its used flag is set.
Step 1008 tests whether all of the strokes have been removed from the existing ink word data structure 64 A. If so, then this data structure is no longer needed, as its information has been moved into a new structure, and it is removed (e.g., from the text buffer, along with any space character following it) at step 1010. If not, as in the present example wherein only the first stroke has been moved, the process continues to step 1012, which repeats the process until the strokes in the scrawl break have been handled in this manner. Thus, as can be appreciated, strokes one (1) through six (6) are moved into the new ink word data structure 64 D in the present example before step 1012 branches to step 1014. Note that after stroke two (2) was handled, the existing ink word data structure 64 A was removed via step 1010, as was existing ink word data structure 64 B after stroke six (6) was handled, as generally represented by the crossed lines “X-ing out” those structures in FIG. 7.
Once the scrawl break structure's strokes are handled in this manner, steps 1014 and 1016 are executed to calculate the rightmost boundary of the new ink word, and the leftmost boundary of the following ink word, and insert a space object representing the space between the two words. Note that the last space object on a line is never removed since it is important to the new line. Step 1018 represents the copying of alternate (text) information from the scrawl break into the new ink word data structure. The process then returns to step 910 of FIG. 9.
At step 910, the pointer into the array 80 is advanced to the earliest ink word with any strokes remaining. Note that this handles the situation where strokes might have been removed non-consecutively from several existing ink words. Step 912 then tests whether another scrawl break structure needs to be handled. If not, the process ends, otherwise step 912 branches to step 914 to select this next scrawl break structure (e.g., 78 Y) before returning to step 904 to handle it.
This time, when step 904 checks to see if the ink word data structure 64 C matches the strokes in scrawl break 78 Y, a match is found. As a result, the existing data structure is valid, although the list of alternates and other information returned by the recognizer can be efficiently copied from the scrawl break structure 78 Y into the existing ink word data structure 64 C at this time (step 906). Also, the strokes in the existing ink word data structure 64 C have been handled, and thus step 908 marks their used flags as such in the array 80. Steps 910, 912 (and possibly 914) operate as described above to continue the process, although in this simplified example, there are no more scrawl breaks to handle and thus the process ends.
The example of FIG. 8 is presents the matching process when the recognizer returns more words (three) than the initial guess of the ink processor (two), which is essentially the opposite of FIG. 7. Thus, three scrawl break structures 78 Q, 78 R and 78 S are returned by the recognizer 60, while the ink processor begins with two ink word data structures 64 F and 64 G. Because the steps of FIGS. 9 and 10 have been described above, they will not be again described herein with reference to FIG. 8. However, it should be noted that in general in this example, the first original scrawl 64 F is not emptied (steps 1008 and 1010) until sometime after the strokes of the first scrawl break 78 Q have been handled and the strokes of the second scrawl break 78 R are being evaluated. Also, as a result of the process, three ink word data structures 64 H, 64 I and 64 J are created. The pointer to the array 80 keeps everything straight, as each stroke in the original ink word data structure 64 F is processed, and each of the original ink word data structures 64 F and 64 G are maintained until emptied of strokes, at which time they are removed via steps 1008 and 1010.
When the ink processor 54 has completed the matching process, the ink processor can update the display 26 to reflect the modified ink data structures. The ink processor can also replace handwritten data with recognized text if desired.
As can be seen from the foregoing detailed description, there is provided a method and system that corrects for parser segmentation errors by efficiently manipulating stroke data to match data returned from a recognizer. For ink word breaks that are correct, the process is extremely rapid.
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.