Hi Bruno and community: I will add my comments to the API proposal (so far).
> 1-) The grammar checker should run in a different thread to not block > OpenOffice. +1 > 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. > 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. > 4-) I think we should create an unified User Interface, for any grammar > checker use it, with grammar checkers common options. +1 > 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 > 6-) The API must know how to split paragraphs into sentences, this was > changed to provide multilingual checking. 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. 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). I understand this imposes a problem with multilingual texts. But I think this is too much fine-grained for this moment. I would prefer to have a simpler API to interact with a grammar checker for my language in the next months, than to wait a couple years to have a more powerful and rich API to handle that kind of documents. A simpler API could have options to "turn off checking for multi-lingual paragraphs" or "split sentences for checking multi-lingual paragraphs", and OOo API would use his sentence boundary detection capabilities to feed a sentence to each grammar checker. > 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). > 8-) Grammar checkers don't interact with details of OOo writer (format, > footnotes, fontsize). This is API work. Yes, I agree with this. And I think is strongly related with point 3). These should be issues handled by OOo API and not by the grammar checker. > 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). > 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. > 11-) There will be two types of grammar-checking: real-time checks, > displayed as wavy lines in the document, and interactive checks > of the whole document via a dialog box. > 12-) (Matthew Strawbridge) It should be possible to have both spell checkers > and grammarcheckers enabled at the same time. If people choose to use > grammar checkers that have built-in dictionaries, they can choose to turn > off the spell checker, but I think the option to have both running should be > there. +1. Best regards, Santiago Bosio. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
