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
>
