You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Jürgen Schmidt <jo...@gmail.com> on 2013/03/13 14:30:26 UTC
Re: [Call-for-Review] code changes for more powerful smarttag extensions
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
Posted by TJ Frazier <tj...@cfl.rr.com>.
On 3/18/2013 03:45, Jürgen Schmidt wrote:
> On 3/17/13 11:27 PM, TJ Frazier wrote:
>>> ... I also noticed that when you zoom a text document the lines for
>>> redlining as well as for smarttags, etc. are not zoomed in the same way
>>> and makes it less visible. But this seems to be a general issue.
>>>
>>> Juergen
>>>
>> Hi, Jürgen,
>>
>> This is one of my pet peeves. The major problem seems to be the line
>> thickness, which corresponds to the glyph property "stroke weight". The
>> un-zoomed skinny line just disappears at high zoom factors. Do you want
>> me to file an issue in BZ on this?
>
> Having an issue for this is definitely a good idea.
>
> Thanks
>
> Juergen
>
<https://issues.apache.org/ooo/show_bug.cgi?id=121911>
(The problem with cats is, they have kittens.)
If you would take a minute to look through this issue, you will see why
I am asking you to add a comment on it. I am a firm believer (though
others disagree) in "BZ as database", that is, as the right place to
record details for the future; I picked the title as carefully as I
could, to show up on searches.
/tj/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
Posted by TJ Frazier <tj...@cfl.rr.com>.
<https://issues.apache.org/ooo/show_bug.cgi?id=121911>
Feel free to cross-link or add comments.
/tj/
On 3/18/2013 03:45, Jürgen Schmidt wrote:
> On 3/17/13 11:27 PM, TJ Frazier wrote:
>>> ... I also noticed that when you zoom a text document the lines for
>>> redlining as well as for smarttags, etc. are not zoomed in the same way
>>> and makes it less visible. But this seems to be a general issue.
>>>
>>> Juergen
>>>
>> Hi, Jürgen,
>>
>> This is one of my pet peeves. The major problem seems to be the line
>> thickness, which corresponds to the glyph property "stroke weight". The
>> un-zoomed skinny line just disappears at high zoom factors. Do you want
>> me to file an issue in BZ on this?
>
> Having an issue for this is definitely a good idea.
>
> Thanks
>
> Juergen
>
>
>>
>> /tj/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/17/13 11:27 PM, TJ Frazier wrote:
>> ... I also noticed that when you zoom a text document the lines for
>> redlining as well as for smarttags, etc. are not zoomed in the same way
>> and makes it less visible. But this seems to be a general issue.
>>
>> Juergen
>>
> Hi, Jürgen,
>
> This is one of my pet peeves. The major problem seems to be the line
> thickness, which corresponds to the glyph property "stroke weight". The
> un-zoomed skinny line just disappears at high zoom factors. Do you want
> me to file an issue in BZ on this?
Having an issue for this is definitely a good idea.
Thanks
Juergen
>
> /tj/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
Posted by TJ Frazier <tj...@cfl.rr.com>.
>... I also noticed that when you zoom a text document the lines for
> redlining as well as for smarttags, etc. are not zoomed in the same way
> and makes it less visible. But this seems to be a general issue.
>
> Juergen
>
Hi, Jürgen,
This is one of my pet peeves. The major problem seems to be the line
thickness, which corresponds to the glyph property "stroke weight". The
un-zoomed skinny line just disappears at high zoom factors. Do you want
me to file an issue in BZ on this?
/tj/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/15/13 1:09 PM, Kai Labusch wrote:
> Am Freitag, 15. März 2013, 07:34:17 schrieb Ariel Constenla-Haile:
>> On Fri, Mar 15, 2013 at 10:45:56AM +0100, Jürgen Schmidt wrote:
>>> On 3/15/13 10:20 AM, Ariel Constenla-Haile wrote:
>>>> On Wed, Mar 13, 2013 at 02:30:26PM +0100, Jürgen Schmidt wrote:
>>>>> - a missing include of XInterface in the new IDL
>>>>> XMarkingAccess.idl, IDL compile error on Mac, surprising that it
>>>>> worked for you
>>>>
>>>> This is a bug, the one that removed the need for explicitly
>>>> inheriting from XInterface should have taken care for not needing
>>>> to include the IDL, what sounds like a non-sense (do not explicitly
>>>> inherit, but include the header!).
>>>
>>> I agree that it's a bug
>>>
>>>>> 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?
>>>>
>>>> IMHO what it does is more problematic than how it's named; see my
>>>> comment on the bug.
>>>
>>> issue https://issues.apache.org/ooo/show_bug.cgi?id=121733
>>
>> Not this one, but https://issues.apache.org/ooo/show_bug.cgi?id=121732
>> invalidation should be triggered on a TextMarkupType base, just like in
>> XFlatParagraph::setChecked, otherwise a smart tag extension triggers
>> unnecessary spell and grammar checking.
>>
>>
>> Regards
>
> Hi,
>
> I agree with both, i.e., using the correct types instead of strings and
> selectively invalidating markup rather than doing it for all types of markup
> at once.
>
> I'll modify and update the patches as soon as possible.
>
> As a first step, it would be sufficient for our purposes, if the extension
> could specify the color of a smart-tag.
>
> Would it reduce your concerns that the patches would give to much control to
> the extension if we remove the possibilty to specify the line type?
>
> However, I already heared some complaints that the smart-tags are not visible
> enough. In other editor applications, we change the background color of
> the text in order to make the problems more visible. In the long run, it would
> be nice if one could introduce a more obvious marking mechanism in AOO.
That can of course make sense and it's worth to think about it more
general. I also noticed that when you zoom a text document the lines for
redlining as well as for smarttags, etc. are not zoomed in the same way
and makes it less visible. But this seems to be a general issue.
Juergen
>
> Regards,
> Kai Labusch
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag
extensions
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Fri, Mar 15, 2013 at 01:09:45PM +0100, Kai Labusch wrote:
> As a first step, it would be sufficient for our purposes, if the extension
> could specify the color of a smart-tag.
>
> Would it reduce your concerns that the patches would give to much control to
> the extension if we remove the possibilty to specify the line type?
IMO it's fine if the smart tag extension specifies both underline color
and style, but the application code, before applying it, should check
that the settings do not overlap with the other settings for spell and
grammar checking, and in case the smart tag extensions overlaps with the
other settings, apply some default. Here the priority is the user
experience: the user should clearly distinguish the different markups.
> However, I already heared some complaints that the smart-tags are not visible
> enough. In other editor applications, we change the background color of
> the text in order to make the problems more visible.
You could implement something similar to the fields shading, may be also
a more detailed mouse-over hint in the tooltip (see void
SwEditWin::RequestHelp(const HelpEvent &rEvt) ), etc. etc. There are
place for improvement in the current implementation (always taking take
that Writer is supposed to be WYSIWYG editor, so all these visual hints
should be configurable).
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [Call-for-Review] code changes for more powerful smarttag extensions
Posted by Kai Labusch <la...@gmail.com>.
Am Freitag, 15. März 2013, 07:34:17 schrieb Ariel Constenla-Haile:
> On Fri, Mar 15, 2013 at 10:45:56AM +0100, Jürgen Schmidt wrote:
> > On 3/15/13 10:20 AM, Ariel Constenla-Haile wrote:
> > > On Wed, Mar 13, 2013 at 02:30:26PM +0100, Jürgen Schmidt wrote:
> > >> - a missing include of XInterface in the new IDL
> > >> XMarkingAccess.idl, IDL compile error on Mac, surprising that it
> > >> worked for you
> > >
> > > This is a bug, the one that removed the need for explicitly
> > > inheriting from XInterface should have taken care for not needing
> > > to include the IDL, what sounds like a non-sense (do not explicitly
> > > inherit, but include the header!).
> >
> > I agree that it's a bug
> >
> > >> 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?
> > >
> > > IMHO what it does is more problematic than how it's named; see my
> > > comment on the bug.
> >
> > issue https://issues.apache.org/ooo/show_bug.cgi?id=121733
>
> Not this one, but https://issues.apache.org/ooo/show_bug.cgi?id=121732
> invalidation should be triggered on a TextMarkupType base, just like in
> XFlatParagraph::setChecked, otherwise a smart tag extension triggers
> unnecessary spell and grammar checking.
>
>
> Regards
Hi,
I agree with both, i.e., using the correct types instead of strings and
selectively invalidating markup rather than doing it for all types of markup
at once.
I'll modify and update the patches as soon as possible.
As a first step, it would be sufficient for our purposes, if the extension
could specify the color of a smart-tag.
Would it reduce your concerns that the patches would give to much control to
the extension if we remove the possibilty to specify the line type?
However, I already heared some complaints that the smart-tags are not visible
enough. In other editor applications, we change the background color of
the text in order to make the problems more visible. In the long run, it would
be nice if one could introduce a more obvious marking mechanism in AOO.
Regards,
Kai Labusch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/20/13 10:26 AM, Kai Labusch wrote:
> Am Freitag, 15. März 2013, 07:34:17 schrieb Ariel Constenla-Haile:
>> On Fri, Mar 15, 2013 at 10:45:56AM +0100, Jürgen Schmidt wrote:
>>> On 3/15/13 10:20 AM, Ariel Constenla-Haile wrote:
>>>> On Wed, Mar 13, 2013 at 02:30:26PM +0100, Jürgen Schmidt wrote:
>>>>> - a missing include of XInterface in the new IDL
>>>>> XMarkingAccess.idl, IDL compile error on Mac, surprising that it
>>>>> worked for you
>>>>
>>>> This is a bug, the one that removed the need for explicitly
>>>> inheriting from XInterface should have taken care for not needing
>>>> to include the IDL, what sounds like a non-sense (do not explicitly
>>>> inherit, but include the header!).
>>>
>>> I agree that it's a bug
>>>
>>>>> 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?
>>>>
>>>> IMHO what it does is more problematic than how it's named; see my
>>>> comment on the bug.
>>>
>>> issue https://issues.apache.org/ooo/show_bug.cgi?id=121733
>>
>> Not this one, but https://issues.apache.org/ooo/show_bug.cgi?id=121732
>> invalidation should be triggered on a TextMarkupType base, just like in
>> XFlatParagraph::setChecked, otherwise a smart tag extension triggers
>> unnecessary spell and grammar checking.
>>
>>
>> Regards
>
> I integrated your suggestions for improvement
> and updated the related bugzilla entries.
>
> Jürgen tried to apply the separate patches to the AOO trunk sources and
> reported that some of the patch-files were broken.
> Therefore, I have regenerated the patch files and submitted them again:
>
> https://issues.apache.org/ooo/show_bug.cgi?id=121730
>
> https://issues.apache.org/ooo/show_bug.cgi?id=121731
>
> https://issues.apache.org/ooo/show_bug.cgi?id=121732
>
> https://issues.apache.org/ooo/show_bug.cgi?id=121733
>
> https://issues.apache.org/ooo/show_bug.cgi?id=121734
I have built with your latest changes and tested my adapted example
SmartTag. Everything works and I plan to apply the patches today to have
them on trunk for further testing and potentially for further
changes/improvements on demand.
Thanks
Juergen
>
> Regards,
> Kai Labusch
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
Posted by Kai Labusch <la...@gmail.com>.
Am Freitag, 15. März 2013, 07:34:17 schrieb Ariel Constenla-Haile:
> On Fri, Mar 15, 2013 at 10:45:56AM +0100, Jürgen Schmidt wrote:
> > On 3/15/13 10:20 AM, Ariel Constenla-Haile wrote:
> > > On Wed, Mar 13, 2013 at 02:30:26PM +0100, Jürgen Schmidt wrote:
> > >> - a missing include of XInterface in the new IDL
> > >> XMarkingAccess.idl, IDL compile error on Mac, surprising that it
> > >> worked for you
> > >
> > > This is a bug, the one that removed the need for explicitly
> > > inheriting from XInterface should have taken care for not needing
> > > to include the IDL, what sounds like a non-sense (do not explicitly
> > > inherit, but include the header!).
> >
> > I agree that it's a bug
> >
> > >> 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?
> > >
> > > IMHO what it does is more problematic than how it's named; see my
> > > comment on the bug.
> >
> > issue https://issues.apache.org/ooo/show_bug.cgi?id=121733
>
> Not this one, but https://issues.apache.org/ooo/show_bug.cgi?id=121732
> invalidation should be triggered on a TextMarkupType base, just like in
> XFlatParagraph::setChecked, otherwise a smart tag extension triggers
> unnecessary spell and grammar checking.
>
>
> Regards
I integrated your suggestions for improvement
and updated the related bugzilla entries.
Jürgen tried to apply the separate patches to the AOO trunk sources and
reported that some of the patch-files were broken.
Therefore, I have regenerated the patch files and submitted them again:
https://issues.apache.org/ooo/show_bug.cgi?id=121730
https://issues.apache.org/ooo/show_bug.cgi?id=121731
https://issues.apache.org/ooo/show_bug.cgi?id=121732
https://issues.apache.org/ooo/show_bug.cgi?id=121733
https://issues.apache.org/ooo/show_bug.cgi?id=121734
Regards,
Kai Labusch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/15/13 11:34 AM, Ariel Constenla-Haile wrote:
> On Fri, Mar 15, 2013 at 10:45:56AM +0100, Jürgen Schmidt wrote:
>> On 3/15/13 10:20 AM, Ariel Constenla-Haile wrote:
>>> On Wed, Mar 13, 2013 at 02:30:26PM +0100, Jürgen Schmidt
>>> wrote:
>>>> - a missing include of XInterface in the new IDL
>>>> XMarkingAccess.idl, IDL compile error on Mac, surprising that
>>>> it worked for you
>>>
>>> This is a bug, the one that removed the need for explicitly
>>> inheriting from XInterface should have taken care for not
>>> needing to include the IDL, what sounds like a non-sense (do
>>> not explicitly inherit, but include the header!).
>>
>> I agree that it's a bug
>>
>>>
>>>> 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?
>>>
>>> IMHO what it does is more problematic than how it's named; see
>>> my comment on the bug.
>>
>> issue https://issues.apache.org/ooo/show_bug.cgi?id=121733
>
> Not this one, but
> https://issues.apache.org/ooo/show_bug.cgi?id=121732 invalidation
> should be triggered on a TextMarkupType base, just like in
> XFlatParagraph::setChecked, otherwise a smart tag extension
> triggers unnecessary spell and grammar checking.
ok, I see thanks for the pointer. It's probably worth to take a
further look on this code.
@Kai, Ariel has a better overview than I have already. I looked not
deep enough in the code. Please take his feedback into account. We
should avoid any unnecessary overhead.
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag
extensions
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Fri, Mar 15, 2013 at 10:45:56AM +0100, Jürgen Schmidt wrote:
> On 3/15/13 10:20 AM, Ariel Constenla-Haile wrote:
> > On Wed, Mar 13, 2013 at 02:30:26PM +0100, Jürgen Schmidt wrote:
> >> - a missing include of XInterface in the new IDL
> >> XMarkingAccess.idl, IDL compile error on Mac, surprising that it
> >> worked for you
> >
> > This is a bug, the one that removed the need for explicitly
> > inheriting from XInterface should have taken care for not needing
> > to include the IDL, what sounds like a non-sense (do not explicitly
> > inherit, but include the header!).
>
> I agree that it's a bug
>
> >
> >> 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?
> >
> > IMHO what it does is more problematic than how it's named; see my
> > comment on the bug.
>
> issue https://issues.apache.org/ooo/show_bug.cgi?id=121733
Not this one, but https://issues.apache.org/ooo/show_bug.cgi?id=121732
invalidation should be triggered on a TextMarkupType base, just like in
XFlatParagraph::setChecked, otherwise a smart tag extension triggers
unnecessary spell and grammar checking.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [Call-for-Review] code changes for more powerful smarttag extensions
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/15/13 10:20 AM, Ariel Constenla-Haile wrote:
> On Wed, Mar 13, 2013 at 02:30:26PM +0100, Jürgen Schmidt wrote:
>> - a missing include of XInterface in the new IDL
>> XMarkingAccess.idl, IDL compile error on Mac, surprising that it
>> worked for you
>
> This is a bug, the one that removed the need for explicitly
> inheriting from XInterface should have taken care for not needing
> to include the IDL, what sounds like a non-sense (do not explicitly
> inherit, but include the header!).
I agree that it's a bug
>
>> 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?
>
> IMHO what it does is more problematic than how it's named; see my
> comment on the bug.
issue https://issues.apache.org/ooo/show_bug.cgi?id=121733
you are correct with your concerns of using strings where of course
other existing types would make more sense.
Your sugggestion of using
- a "LineColor" with value css::util::Color instead of Red, Green, Blue
- "LinjeType" of type css::awt::FontUnderline
@Kai, can you please take this into account and adapt the changes?
Ariel is right that these changes would an improvement.
Regarding your concern I don't agree completely. For me it's fine to
allow some more tweaking from the extension. Where I agree is that it
shouldn't conflict with other global settings or other SmartTags. I
will also take a further look into the code...
Thanks for your reply Ariel
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag
extensions
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Wed, Mar 13, 2013 at 02:30:26PM +0100, Jürgen Schmidt wrote:
> - a missing include of XInterface in the new IDL XMarkingAccess.idl, IDL
> compile error on Mac, surprising that it worked for you
This is a bug, the one that removed the need for explicitly inheriting
from XInterface should have taken care for not needing to include the
IDL, what sounds like a non-sense (do not explicitly inherit, but include
the header!).
> 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?
IMHO what it does is more problematic than how it's named; see my comment on
the bug.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re:Re: [Call-for-Review] code changes for more powerful smarttag
extensions
Posted by Yi <la...@126.com>.
Hi,
What I mean isthatI would liketo participate in development of this extension
At 2013-03-13 22:33:43,"Jürgen Schmidt" <jo...@gmail.com> wrote:
>On 3/13/13 3:04 PM, 2 wrote:
>> Hi, this is a wonderful extension, I would like to take a look, how can I get it?
>
>you can't get the extension at the moment and it would not help you. The
>extension works only with a server backend and/or a valid account.
>
>And I think the extension is still under development...
>
>
>Juergen
>
>>
>>
>>
>> 在 2013-03-13 21:30:26，"Jürgen Schmidt" <jo...@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-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: [Call-for-Review] code changes for more powerful smarttag extensions
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 3/13/13 3:04 PM, 2 wrote:
> Hi, this is a wonderful extension, I would like to take a look, how can I get it?
you can't get the extension at the moment and it would not help you. The
extension works only with a server backend and/or a valid account.
And I think the extension is still under development...
Juergen
>
>
>
> 在 2013-03-13 21:30:26，"Jürgen Schmidt" <jo...@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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re:Re: [Call-for-Review] code changes for more powerful smarttag
extensions
Posted by 2 <la...@126.com>.
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" <jo...@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-unsubscribe@openoffice.apache.org
>For additional commands, e-mail: dev-help@openoffice.apache.org
>