Hi Santiago, >> 2-) The API must provide text placed inside table cells, text headers and >> footers, enumerations and text boxes (Drawing Objects). > > I don't disagree here. But my experience shows that generally, text > found in tables (mostly in headers), and drawing objects, completely > disregards grammar rules; sometimes because of space restrictions, or > because this kind of texts are used to summarize info. > It will be good if you can have options in UI to turn these checkings on > or off, as spellchecking does.
+1 for the UI option. >> 3-) OpenOffice should be able to replace the wrong sentences without >> losing format. > > This will be ideal. But can be a little tricky because the grammar > checker will check a text portion that possibly includes varying > character formats and styles. > So, the standard replacement method provided by OOo must be used. Also, > this is what happens with spellchecking. As prove of concept, write an > incorrect spelled word, and make some of the chars bold, when you > spellcheck and replace the word, this format is lost. It works if all characters in the word are bold. Asking for every single characters attribute to be kept is asking too much. ^^° >> 5-) Automatic checking should run in background and marking the wrong >> sentences with a wavy line. It could be enabled and disabled, like Spell >> Checker. > > +1 Well, not the whole sentence but the wrong parts only. > AFAIK the API knows about sentences (service XSentenceCursor), but it's > probably a fair simple implementation, that needs to be re-worked and > extended for what you expect it to be; and more: it has to be language > specific. In the end the XSentenceCursor uses the i18n breakiterator as well. And that one will not cross paragraph borders. (At least in it's current implementation.) > I think OOo must send complete paragraphs to the grammar checker. That's > because the paragraphs are conceptual units. All sentences in paragraphs > are, by definition, related to the same subject. And in many languages > there MUST be inter-sentence checkings. In my language for example > (Spanish) one of the most useful tests is to check for mistakes in > gender or number correspondences (and this correspondences could be > inter-sentence). Just curious: But even though is the UI to display a single sentence at a time when doing interactive grammar checking? I wonder if, even though a whole paragraph is passed along, the iteration will still advance in steps of sentences... It may not be necessary to process the whole paragraph at once. It could be done step-by-step. It would instead be required that the grammar checker can keep that state-information obtained from the previous sentences. Also it would have to associate that information with the specific paragraph. (Similar to what seemed to be the consense about the need to identify the document a text belongs to.) Otherwise the implementation would always have to start at the beginning of the paragraph and step through until the current sentence to be checked is found. This would work as well. But maybe we can do it more cleverly... >> 7-) We are supposing that the smallest unit to be considered (for a >> language) is a sentence. > > This would be true for the grammar checker, not for the API, unless > handling multilingual paragraphs. But the grammar checker's suggested > corrections could involve the replacement of one or more words (perhaps > even a complete sentence, in extreme cases). I'm sorry but I think I did not completely understood the message of the above paragraph. Are you saying if we provide paragraphs in the API but still call the grammar checkers for a single sentence only to (to have it check and displayed in the UI if necessary) you are fine? >> 9-) The API should provide a paragraph (for example) to grammar checker >> and this one should return a list. If there is no mistake in this paragraph, >> the >> list should be empty, else the list should contain ... > > Again, OOo must provide a paragraph to the grammar checker. The grammar > checker should return nothing when there is no error, or return a list > of wrong sentences inside the paragraph with his associated replacements > (if they exists). I think returning all errors for all sentences in a paragraph is too much. Especially if you also want to provide the suggestions for correction. Providing all errors for a single sentence with one call is the most should be done with one call. Maybe even this should be broken up in several iterations... >> 10-) (Matthew Strawbridge) UI Language could be passed as a parameter to >> grammar checker, which could choose to ignore it or to return comments >> in that language if it knows how. > > This seems correct to me, but again too much fine-grained for this > moment. Sure it is fine-grained. But it is easy to ignore since it is not a 'must be'. ^_~ Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
