Hi Santiago,
On 6/2/06, Santiago Bosio <[EMAIL PROTECTED]> wrote:
> 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.
Yes, I think you are completelly right, this rule will be sent to "nice to have" session, every opinion I read about it was the same as yours =).
> 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.
I think here we can do the best effort to not lose format, for e.g. preserving font and size. For sure it will be tricky but at least this two thinks need to stay intact when we replace...
> 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.
Thomas was talking about I18n breakiterator, he told that is a pretty good service provided by uno, we can use it as well.
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).
Yes, in portuguese we have this kind of analysis too, yes its too limited to left just one or other method, we decided to provide both of them, (yes sentence and paragraph) the grammar checker will ask for methods like:
getNextParagraph()
getNextSentence()
Now the question is, who decide which method is used? The grammar checker or the API?
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",
This is a nice idea =), I was talking about it with Menezes this Thursday.
> 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.
I think this is easy, grammar checker could ask a method like
getUserInterfaceLocale()
who choses to use it is grammar checker, we just provide it
Best regards,
Santiago Bosio.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Cheers
Bruno Sant'Anna
