Hi, sorry for the long delay, we're currently very busy finalising our next big release.
I hope I can address all the different concerns raised here: 1) Why XTextRanges? As Jürgen already guessed, we are iterating over a document's content (via XEnumerationAccess) to extract the text and get associated styling information. This extraction is necessary since users can define filters (based on fonts and styling) that determine whether text is extracted at all or if its text that needs to be handled in a different way. Examples could be code snippets (set in a monospace font; linguistic analysis of code doesn't make much sense unless you're a compiler) or auto generated text which needs to be marked as readonly. All suggestions that our tool provides are based on the extracted text, we need a mapping between XTextRanges and the extracted text to be able to highlight the respective part of a document. When authors start to edit issues and accept suggestions from our tool, original text positions start to move. Fortunately enough, positions of XTextRanges are updated automatically. In general, Ariel is right in saying that we're abusing the smart tags API. We decided to use Smart Tags since we get highlighting for free and can use the existing context menu to add our actions. In other editors, we always need to do this ourselves. 2) Proofreading API We did look at the Proofreading API but it does not fit our use case properly. As far as I can tell, it is more geared towards a "check as you type" kind of functionality whereas our software is designed to process entire documents or topics. In terms of an author's workflow, our tool is intended as a separate and conscious step. There are two more points that speak against this API from our point of view: * you can't trigger it independently (needed as mentioned earlier) * the notion what a sentence comprises and will differ between the API and our tool. I hope I could clarify our approach a bit more. In case I missed something or you need more detail, just let me know. I'll do my best to answer in a more timely fashion this time. Thank you and best, Robert On Dec 7, 2012, at 8:06 PM, Ariel Constenla-Haile <arie...@apache.org<mailto:arie...@apache.org>> wrote: On Fri, Dec 07, 2012 at 07:56:12PM +0100, Juergen Schmidt wrote: Yes, but it look like the design was not to give access to the text range, but a string; I tend to think the underlying reason was that giving a text range is not safe. I tend to agree, but in related Smarttags actions you will get the text range object anyway. But this is the intended design: concurrent smart tag processing, while I assume that actions are not invoked concurrently: the user can select only one menu item at the time with one action. Concerning the proof reader, I don't have any at hand right now, but IIRC the text is underlined with a dotted light blue line. I'll have to try the LanguageTool to see what offers the context menu in this case. Regards -- Ariel Constenla-Haile La Plata, Argentina
