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
