Malte Timmermann wrote:
I suppose that this is only inefficient for very large AccessibleText blocks, which with our preferred "object == paragraph" model should be very rare.My comments on this: Even with OOo being a word processor application, we have the sentence detection (or guessing) problem Aaron is describing below. So if a word processor can't handle that, how could text edit, label, ...? Of course OOo should probably have more knowledge in this area than some AT, but if AT does it, it helps all ATK implementations, and it's done consistently. I don't agree with Bills comment about inefficiency when implemented by AT. AT doesn't have to get by line/words/etc, but get get the full accessible text and work on that directly.
I think a reasonable case has been made for this, but I still am concerned about the impact of removing such a piece of API. I'd like to wait for feedback from Will and Mike.
It's also not really true that "if the AT does this, it all happens in one place." If the AT does it, it happens in every AT. If ATK defines it, it happens in every ATK implementation - in both cases a multiplicity of implementations are required.
Bill
Malte.