Re: [Call-for-Review] code changes for more powerful smarttag extensions
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
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 pgpwR6j_capNI.pgp Description: PGP signature
Re: [Call-for-Review] code changes for more powerful smarttag extensions
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
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 pgpodmt_UVOlL.pgp Description: PGP signature
Re: [Call-for-Review] code changes for more powerful smarttag extensions
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Call-for-Review] code changes for more powerful smarttag extensions
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 pgpSsyDXnGWvD.pgp Description: PGP signature
Re:Re: [Call-for-Review] code changes for more powerful smarttag extensions
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,
Re: [Call-for-Review] code changes for more powerful smarttag extensions
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 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
[Call-for-Review] code changes for more powerful smarttag extensions
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
Re: [Call-for-Review] code changes for more powerful smarttag extensions
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
