Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
Received-SPF: pass (nike.apache.org: domain of jogischmidt@gmail.com
 designates 209.85.214.46 as permitted sender)
Message-ID: <5113D69D.7090507@gmail.com>
Date: Thu, 07 Feb 2013 17:30:21 +0100
From: =?ISO-8859-1?Q?J=FCrgen_Schmidt?= <jogischmidt@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: dev@openoffice.apache.org
Subject: Re: [Call-for-Review] code changes for more powerful smarttag
 extensions
References: <64781494.IdFnhSqOPI@linux-9wtu>
In-Reply-To: <64781494.IdFnhSqOPI@linux-9wtu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

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.

Juergen