Am Freitag, 7. Dezember 2012 um 18:09 schrieb Ariel Constenla-Haile: > On Fri, Dec 07, 2012 at 05:35:59PM +0100, Jürgen Schmidt wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 12/7/12 5:21 PM, Ariel Constenla-Haile wrote: > > > On Fri, Dec 07, 2012 at 05:01:42PM +0100, Jürgen Schmidt wrote: > > > > B. change the existing (not published) API and replace the first > > > > argument "string" to "XTextRange". > > > > > > > > > > > > > Is it a good idea to use a text range? this will allow modification > > > of this text range, unless you make it read-only, if possible at > > > all. I guess that the current approach of using a string instad of > > > the text range has to do with the fact that there might more than > > > one smart tag precessing the same string. If you give the smart tag > > > a text range, you cannot relay on the extension good will not to > > > manipulate it. > > > > > > > > > a good point, do you have another idea? > > mmm no. It just looked dangerous to give a text range in this case, > unless it's read-only. > > > > The point is that Robert has made the evaluation of the document > > already, the recognition if you want, and will use the SmartTag API to > > visualize the results and provide proper actions. > > > > > From the original post, it seems he is misusing the smart tag api: > > "for a Writer extension, we're traversing a document using the Java text > iteration API. The text is extracted and sent to a server backend for > linguistic analysis. This server returns a report containing corrections > for the current document which the extension needs to map back into the > document. All of this is based on XTextRange objects. > > In order to highlight these corrections within document, we are using > smart tags." > > > It looks like he is implementing a grammar checker with the smart tag > API: see css::linguistic.Proofreader > Interesting, I simply hadn't this API on my radar. The question is how it is integrated in the UI when you provide an implementation.
I believe Robert wants to have more control and of course wants to visualize the results with different colors in the document. Depending on the found item the user have different options via context menu or so. > "provides a proofreader (often known as grammar checker) for text > > An implementation of this service will receive text and has to > identify the sentence end and report all errors found. > > An implementation of this service is not limited to grammar checking at > all. It might also check style, used terms etc. Basically it can check > every aspect of a single sentence. Since the text provided is always the > complete paragraph it can also choose to analyze the context of the > sentence currently required to be checked. However error reports need to > be limited to the current sentence." > > Note that also XProofreading::doProofreading gets a string, not a text > range. May be the design was based on the idea that a string is safer > than a text range for concurrent proof reading by different proof > readers, and safe modification are allowed only through XFlatParagraph > of the ProofreadingResult. > > > > I assume he has a list of text ranges already and have to provide the > > markups only and put it in the SmartTag context. > > > > > yes, I understood this too. > > > The idea is to reuse this concepts because you get a lot of features > > for free, context menu, you can define your own action based on the > > SmartTag type, ... > > > > > 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. Juergen > > > > Regards > -- > Ariel Constenla-Haile > La Plata, Argentina > >
