Hi Matthew, > On 6 Jun 2006 at 12:40, Thomas Lange wrote: >> Passing the paragraph will only allow the grammar checker to see some >> of the context of the text to be checked and is readily available from >> the document because it is the unit internally used. >> >> I do not know if the grammar checker can actually take advantage of this >> but it will be possible and not already be impossible because of the >> API. >> The main advantage would be that we can provide the grammar-checker with >> a suggested end-of-sentence and allow him to overrule this and to point >> out that the atual end-of-sentence is behind the one we suggested in the >> API. And as was said elsewhere it is a requirement for Asian checkers to >> allow them to determine the end-of-sentence on their own, because it may >> be context dependend. >> >> The errors reported by the grammar checker however should remain within >> the bounds of the sentence that was suggested/detected. >> This is of course because the interactive checking will display only the >> sentence currently being checked. > > Can't the grammar checker return values for the new suggested start > and end of the sentence, so OOo can use these to pick out the > sentence to display? This way, all errors found in the whole sentence > can be returned together. It will also make more sense to the users, > rather than having sentence fragments displayed.
Well I think it would be possible as well. But why would there be such use? Since checking starts at the beginning of the paragraph and end-of-sentence-detection is probably to be done by the grammar checker (maybe by providing a suggestion for it). The detection should have been done properly. Especially if the paragraph was already in one language. Then the end-of-sentence for the previous sentence was detected by the very component that should now should check for the start-of-sentence. (Which should be the same as the previous end-of-sentence apart from following white spaces.) And having the grammar checker detect the start-of-sentence looks like assuming the prior end-of-sentence detection has failed. If that were the case the end-of-sentence detection should be fixed. Also allowing to 'go backwards' to the suggested start seems to introduce a slight possibility for loops. > In particular, some of the grammar errors that the checker would like > to report may span several of the detected fragments. Suppose a > grammar checker wants to discourage the use of abbreviations in the > body text. Consider the following sentence: > >> There are e.g. problems. > > If the grammar checker wants to change this to >> There are, for example, problems. > then it would be no good if the API supplied the text as 'There are > e.', 'g.' and 'problems.' in three separate calls! Of course breaking up the sentence this way should not happen! But for one I can assure you that the breakiterator will be fine with such basic abbreviations (and if not it needs to be fixed). And second if the grammar checker is allowed to overrule the suggested end-of-sentence it can do the end-of-sentence detection on it's own and everything should be fine. Also I would guess that most grammar checker will come along with some means of end-of-sentence detection on their own because it is such a critical issue. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
