Hi, this is a wonderful extension, I would like to take a look, how can I get it?
在 2013-03-13 21:30:26,"Jürgen Schmidt" <jogischm...@gmail.com> 写道: >On 2/7/13 5:30 PM, Jürgen Schmidt wrote: >> On 2/7/13 5:08 PM, Kai Labusch wrote: >>> Hi everyone, >>> >>> I'm a colleague of Robert Barbey at Acrolinx and I'm working on the >>> OpenOffice >>> Writer integration of our client-server text-processing solution. >>> Currently, we already have a working writer extension that has been >>> implemented in java and provides the functionality we need. >>> For the implementation, we had to modify the AOO sources and add/change >>> some >>> API-functions/interfaces. >>> >>> Robert already posted a call-for-review for a modification of the >>> XSmartTagRecognizer interface ("[Call-for-Review] Extension to >>> XSmartTagRecognizer interface", >>> https://issues.apache.org/ooo/show_bug.cgi?id=121391). We modified this >>> patch >>> request according to suggestions of Ariel and Jürgen and submitted a new >>> patch >>> request that is also mentioned in this post. >>> >>> During development of our writer extension we stumbled on a number of >>> issues >>> where we felt the need to modify something within AOO. >>> The purpose of this post is to provide a summary of these changes and to >>> ask >>> for comments and input since there might be better ways to solve the >>> problems >>> we had without the need to change something within AOO. >>> >>> We splitted all the modifications in five different patch-sets where each >>> patch-set contains a number of changes that belong to a common aspect. >>> We submitted the patch-sets via bugzilla and I will refer to them in this >>> post >>> later on. >>> >>> First, as a motivation, I would like to describe the most important aspects >>> of >>> what our writer extension does: >>> >>> The extension adds a toolbar and menu to the writer application. The menu >>> and >>> toolbar have a "check"-button/entry that can be used in order to >>> simultaneously check the document for different types of issues. >>> >>> Among others, issues can be: >>> - spelling errors >>> - grammar errors >>> - style rules (like "Don't use Future tense", "Don't use passive voice") >>> - reuse (use a different/better phrase that already has been approved due >>> to >>> some reason) >>> - terminology (use a different word) >>> - sentence break missing >>> - broken link >>> - sentence too long >>> - wrong capitalization >>> >>> If the user clicks the check-button, the writer extension would extract the >>> text of the document and send it to a server application. >>> The server application performs a linguistic analysis of the document and >>> creates a report of all issues that have been identified. >>> The writer extension then receives the report and marks the issues within >>> the >>> writer document. >>> >>> For each issue, a smarttag is shown where its type is depicted by the color >>> of >>> the smarttag line (colors can be configured, for instance: spelling -> red, >>> grammar -> blue, style-> green ...). >>> >>> The extension does not only send the text of the document to the linguistic >>> server but also context information like character-style, paragraph-style, >>> font-type. The linguistic rules within the server application are context >>> sensitive, i.e., they might behave differently depending on the context of >>> a >>> particular part of the text (for instance different capitalization in >>> titles). >>> >>> Furthermore, they are also context sensitive with respect to the >>> surrounding >>> text, i.e., it is not sufficient to consider only one or two words (for >>> instance "sentence too long"). The context can be quite large since the >>> system >>> can be configured so that certain document structures (entire paragraphs, >>> footnotes, image captions...) are considered as parenthetic elements which >>> are removed from the normal text-flow or completely ignored. Since the >>> outcome >>> of the checking process can depend on the entire document, it is not >>> possible >>> to perform the check based on a part of the text as it is done in some >>> proofreading APIs. >>> >>> Due to the reasons mentioned above, it is neccessary that the smarttag >>> extension can globally identify and localize a particular part of the text >>> within the entire document. Therefore, we felt the need to introduce a new >>> interface "XRangeBasedSmartTagRecognizer" that can be optionally >>> implemented >>> in a smarttag extension. The smarttag manager inside AOO would check if a >>> smarttag recognizer implements this additional interface. If the interface >>> has >>> been implemented, the smarttag manager would call "recognizeTextRange" >>> which >>> provides a globally identifiable text range to the recognizer >>> (https://issues.apache.org/ooo/show_bug.cgi?id=121730). >>> >>> To enable the marking of text by means of such a text-range, we extended >>> the >>> XTextMarkup interface >>> (https://issues.apache.org/ooo/show_bug.cgi?id=121734). >>> >>> To make colored smarttags possible, we felt the need to modify SwWrongArea >>> and >>> the lcl_DrawWrongListData function within the AOO sources >>> (https://issues.apache.org/ooo/show_bug.cgi?id=121733). >>> >>> If the user clicks on a smarttag, he/she gets a context menu that offers >>> actions to improve the document. What these actions are depends on the type >>> and context of the marked part of the text. Depending on the type of issue >>> and >>> the actual issue itself the number of actions might vary. >>> In order to make this possible, we felt the need to modify the >>> XSmartTagAction >>> interface (https://issues.apache.org/ooo/show_bug.cgi?id=121731). >>> >>> If the user applies some action to the document, the action could >>> invalidate >>> other smartags at different locations in the document. For instance, the >>> begin >>> and the end of a sentence is marked as a result of a "sentence too long"- >>> issue. If the users chooses the "ignore"-action of the begin-smarttag, the >>> corresponding end-smarttag would be removed too. Furthermore, the menu and >>> toolbar have buttons/entries to hide/show the smarttags that are related to >>> our extension. Therefore, we added a new interface "XMarkingAccess" that is >>> implemented by SwXTextCursor and can be used in order to invalidate and >>> repaint/remove/recolor the smartags within a particular text-range >>> (https://issues.apache.org/ooo/show_bug.cgi?id=121732). >>> >>> We would like to present our modifications to the community since we think >>> that they might add desirable functionality to AOO that enables the >>> implementation of more powerful smarttag-extensions that could not be >>> realized >>> before. >>> >>> Here at Acrolinx, we have set up an AOO build environment for >>> Windows/Linux/OSX which provides us with a patched AOO that can already be >>> used together with our software. In the long run, we would like to >>> integrate >>> our software into a standard version of AOO. >>> >>> I'm looking forward to your comments and criticism. >>> >>> Best regards, >>> Kai Labusch >>> >> >> just to let you know that I will take a look on it later, it seems I >> will need a few minutes ... >> >> But I appreciate that you take our concerns serious and reworked on your >> patch. Your extension will be definitely useful. > >sorry for the delay but I have taken a look on it now and I am in >general fine with the patch. By the way Kai send me off-list a combined >patch for all issues that I have applied locally and tested. > >I found a few things that I had to correct. > >- a missing include of XInterface in the new IDL XMarkingAccess.idl, IDL >compile error on Mac, surprising that it worked for you >- checking if xPropertyBag is valid in wrong.hxx because my Java Test >SmartTag insert a null interface for XStringKeyMap > > >The interface name "XMarkingAccess" and the method name >"invalidateMarkings" sounds somewhat strange but I have to confess that >I don't have a much better name in place. Maybe somebody else has a good >name in mind? > >My Test SmartTag implementation worked quite well after I have made 2 >minor changes >- adapt the changed method name: commitTextMarkup -> commitStringMarkup >- add new additional parameter XStringKeyMap to method >XSmartTagAction.getActionCount(...) > >If nobody raised further concerns or come up with a better name for the >new interface XMarkingAccess I plan to integrate it later this week. > >@Kai, I hope we will see more from you and you will make use of the >opportunity to enhance/extend an open source program with general new >features to make use of them later on in your own extension. But others >can benefit from the new enhancements as well. Or you help us to fix >issues that prevent you from using AOO. I think this exactly is the key >of open source and our opportunity to build an eco system around >OpenOffice. It must be possible to add value on top of or to AOO >(proprietary or free) to open further business opportunities. In your >case it is to make AOO ready for enterprises to use your powerful, >professional proof reading software (more than a grammar checker). I >think this is a very nice example and I am looking forward to further >contributions from you. > >Once it is integrated I would like to write a blog entry about it >together with you to make this more visible. It is exactly what AOO >needs to grow effectively. > >And more general we should blog about all new features, important bug >fixes, etc that somebody brings in the office. We should blog about all >the good things we are doing, the logo contest, the QA, the translation ... > >Juergen > > > > > > > > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >For additional commands, e-mail: dev-h...@openoffice.apache.org >