openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kai Labusch <labu...@gmail.com>
Subject [Call-for-Review] code changes for more powerful smarttag extensions
Date Thu, 07 Feb 2013 16:08:03 GMT
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

Mime
View raw message