On 5/24/06, Joan Moratinos <[EMAIL PROTECTED]> wrote:
As we discussed before, letting the OO determine the end of sentences is difficult. I think the right time to start checking is after every Return Key press. Letting the grammar checkers analyse blocks is more secure, the grammar checker can commit few mistakes when we act like it.
hum... I think API can deal with it, my idea is not letting grammar checkers deal with these details, only analyse and suggests corrections. It could be difficult letting a grammar checker deal with indexes, text positions, underlining etc.
We have discussed it before, there is a problem, today every grammar checker uses its own user interface, now imagine if you want to use two or more grammar checkers in the same time, each grammar checker should have its own UI? I think its not good. I know if we create a single user interface it cannot allow a fine tuning in each grammar checker but I'm proposing a unified UI with most common options. We are open to discuss here ok?
Can be for future API =). I'll remeber this...
Yes, You are correct, the users may in several times just correct the sentences, but the process of analysing the Paragraph is processed just once per change (after a change or a return key press, as I told before). And a single check should provide all information regarding the block analysed, IT not means that everything will be showed to the user, it will just be stored in some place (an object in memory) for the User Interface deal with it.
En/na Bruno Sant'Anna ha escrit:
> Hi,
>
> Talking about this program with Carlos Menezes, we started to think
> about summarizing the topics open in previous e-mails. Feel free to
> comment ok?
>
> 1. Grammar Checker API, now:
>
> 1. It makes sense working with just one language now; so, foreign
> words in the text should be ignored.
> 2. The grammar checker should run in a different thread to not block
> OpenOffice.
> 3. The grammar checker should be able to check inside table cells,
> text headers and footers, enumerations and text boxes (Drawing
> Objects).
> 4. The grammar checker should determine end of the sentences, because
> it is not so trivial (e.g., abbreviations). So, OpenOffice should
> just provide to the grammar checker an entire block of text, like
> a paragraph.
For the automatic checking in the background:
I have noticed that the Spanish grammar checker for MSWord tries to
check everytime the user types a character that is a "candidate" for
ending a sentence (for example, a dot). If the user goes on typing on
the same paragraph, eventualy some fragments are checked again (it seems
like there are "hard" ends, that can't be changed by the following text,
and "soft" ends, that depend on the text that follows (for example, an
abbreviation can appear at the end of the sentence or in the middle)). I
think that we should check the grammar as soon as possible, not when all
the paragraph has been typed.
As we discussed before, letting the OO determine the end of sentences is difficult. I think the right time to start checking is after every Return Key press. Letting the grammar checkers analyse blocks is more secure, the grammar checker can commit few mistakes when we act like it.
> 5. OpenOffice should be able to replace the wrong sentences.
The checker should preserve formating, footnotes, etc. Ideally these
things should not be passed to the checker (the footnotes and the like
could be passed when the paragraph or the sentence that includes them
has been checked, for example), but if the user chooses to accept a
suggestion, the format (i.e. italics), the footnotes, etc. should remain
in the original places. Perhaps we could pass "markers" embedded in the
paragraph text and then return them in the corrected text to "align" the
original and the checked sentences.
hum... I think API can deal with it, my idea is not letting grammar checkers deal with these details, only analyse and suggests corrections. It could be difficult letting a grammar checker deal with indexes, text positions, underlining etc.
> 6. I think we should create an unified User Interface, for any
> grammar checker use it.
I think that this user interface should be optional. A grammar checker
is a candidate for great complexity and we should not be constrained to
a predefined UI. For example, the grammar checker I'm developing
(http://www.einescat.org) uses its own UI, and can be eventually used
from clients other than OOo. For me (in my particular case) it would be
better not being bound to any user interface.
We have discussed it before, there is a problem, today every grammar checker uses its own user interface, now imagine if you want to use two or more grammar checkers in the same time, each grammar checker should have its own UI? I think its not good. I know if we create a single user interface it cannot allow a fine tuning in each grammar checker but I'm proposing a unified UI with most common options. We are open to discuss here ok?
> 7. Automatic checking should run in background and marking the wrong
> sentences with a wavy line. It could be enabled and disabled, like
> Spell Checker.
We should consider different colors for different usages (grammar
mistakes, style recommendations, etc.).
Can be for future API =). I'll remeber this...
> 8. 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:
> 1. Where is the mistake in the paragraph (initial index + final
> index).
> 2. A list of suggestions to correct that mistake (this list can
> be empty if checker is not prepared to guess).
> 3. A comment about mistake, e.g. what a grammar book should say
> about it.
A paragraph can contain several mistakes. We should proceed as in the
spell checker. First the checker could return only the limits of the
mistakes, so that OOo marks it. Only when the user asks for suggestions
or explanations, should the checker provide it. Often the user will
correct the mistakes without asking for suggestions nor explanations.
Yes, You are correct, the users may in several times just correct the sentences, but the process of analysing the Paragraph is processed just once per change (after a change or a return key press, as I told before). And a single check should provide all information regarding the block analysed, IT not means that everything will be showed to the user, it will just be stored in some place (an object in memory) for the User Interface deal with it.
>
>
> 2. Grammar Checker API, future:
>
> 1. Let's suppose it's possible to manage several languages in a text
> and there is a Language Guessing API. Then, when OpenOffice
> discover language of a sentence, it automatically loads grammar
> checker to correspondent language.
> 2. Optimize memory allocation, input/output and processing.
> 3. Correct possible bugs.
>
>
> Bruno Sant'Anna
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
