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.
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.
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.
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.).
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.
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]
