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
