MIME type of current document
Hi everyone, is it possible to get the kind of document currently opened in Writer via the API? Ideally, this would be a MIME type kind of thing. Thank you very much! Best, Robert
Re: [Call-for-Review] Extension to XSmartTagRecognizer interface
Hi, sorry for the long delay, we're currently very busy finalising our next big release. I hope I can address all the different concerns raised here: 1) Why XTextRanges? As Jürgen already guessed, we are iterating over a document's content (via XEnumerationAccess) to extract the text and get associated styling information. This extraction is necessary since users can define filters (based on fonts and styling) that determine whether text is extracted at all or if its text that needs to be handled in a different way. Examples could be code snippets (set in a monospace font; linguistic analysis of code doesn't make much sense unless you're a compiler) or auto generated text which needs to be marked as readonly. All suggestions that our tool provides are based on the extracted text, we need a mapping between XTextRanges and the extracted text to be able to highlight the respective part of a document. When authors start to edit issues and accept suggestions from our tool, original text positions start to move. Fortunately enough, positions of XTextRanges are updated automatically. In general, Ariel is right in saying that we're abusing the smart tags API. We decided to use Smart Tags since we get highlighting for free and can use the existing context menu to add our actions. In other editors, we always need to do this ourselves. 2) Proofreading API We did look at the Proofreading API but it does not fit our use case properly. As far as I can tell, it is more geared towards a check as you type kind of functionality whereas our software is designed to process entire documents or topics. In terms of an author's workflow, our tool is intended as a separate and conscious step. There are two more points that speak against this API from our point of view: * you can't trigger it independently (needed as mentioned earlier) * the notion what a sentence comprises and will differ between the API and our tool. I hope I could clarify our approach a bit more. In case I missed something or you need more detail, just let me know. I'll do my best to answer in a more timely fashion this time. Thank you and best, Robert On Dec 7, 2012, at 8:06 PM, Ariel Constenla-Haile arie...@apache.orgmailto:arie...@apache.org wrote: On Fri, Dec 07, 2012 at 07:56:12PM +0100, Juergen Schmidt wrote: Yes, but it look like the design was not to give access to the text range, but a string; I tend to think the underlying reason was that giving a text range is not safe. I tend to agree, but in related Smarttags actions you will get the text range object anyway. But this is the intended design: concurrent smart tag processing, while I assume that actions are not invoked concurrently: the user can select only one menu item at the time with one action. Concerning the proof reader, I don't have any at hand right now, but IIRC the text is underlined with a dotted light blue line. I'll have to try the LanguageTool to see what offers the context menu in this case. Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: Access to Fonts and Style via API
D'oh! Google is your friend: http://wiki.openoffice.org/wiki/Documentation/DevGuide/Text/Overall_Document_Features#Styles This page describes exactly what I needed. Robert On Nov 27, 2012, at 10:55 PM, Robert Barbey robert.bar...@acrolinx.com wrote: Hi everyone, quick question about the possibilities of the OpenOffice API: is it possible in Writer to access the available fonts, character and paragraph styles via the API? Many thanks in advance, Robert
Access to Fonts and Style via API
Hi everyone, quick question about the possibilities of the OpenOffice API: is it possible in Writer to access the available fonts, character and paragraph styles via the API? Many thanks in advance, Robert
Re: Maven plug-in for building extension description.xml files
Rob, thanks for the quick answer. Unfortunately, I wasn't talking about the Writer extension but about the Maven plug-in. It hasn't been decided yet whether the extension will be publicly available. Sorry for the confusion! Robert On Nov 21, 2012, at 10:37 PM, Rob Weir robw...@apache.org wrote: On Wed, Nov 21, 2012 at 4:23 PM, Robert Barbey robert.bar...@acrolinx.com wrote: Hi everyone, as I mentioned earlier on this list, I'm working on a Writer extension in Java. We're using Maven as a build tool and I wanted to let Maven generate description.xml and update.xml files based on the information in the POM. That's why I started writing a Maven plug-in that can do that. I convinced my CTO that it would be a good idea to donate this plug-in's sources once it's completed. I'd like to know what's necessary in terms of licensing. Is it sufficient to prepend a licensing statement to each source file or is more involved? Are they any formatting conventions I should know about? And what about package names? So two options: 1) Make your extension be open source at Apache, for distribution within an OpenOffice release 2) Make it open source elsewhere, like on SourceForge, and distribute it on our extensions website: http://extensions.openoffice.org/ Key insight is that for #2 you can have any license you want. Of course, we think the Apache License is a fine license. For #1 we'd want to first have a discussion on the list on what your extension does and whether it makes sense to be part of the project. Regards -Rob Thanks for your help! Best, Robert
Hello from Acrolinx
Hi everyone, since my colleagues and I started writing a plug-in for OpenOffice Writer I wanted to let you guys know what we're trying to achieve with it. My company's main product is a client-server-based tool that assists authors in editing technical documentation. With a plug-in in their authoring tool, they can send the document they're currently working on to the server for linguistic analysis. Next to spell and grammar checking, this analysis involves checking of certain style rules (like Don't use Future tense, Don't use passive voice) and that the right terminology is used. Terminology is useful if you want to ensure that e.g. parts of a device are always called the same in a manual or that the right product name is used. The results of the analysis are then highlighted in the document itself so you don't have to jump between tools. The author can then click on each highlight and gets a context menu that offers more information about the issue and offers a suggestion how to correct it. After some great hints and some research we decided to use a smart tag-based approach to get the highlights for our flags into the document. For dummy texts, this works pretty well. Writing a plug-in for OpenOffice is pretty exciting for us since we have so far only dealt with proprietary editors with black box APIs. Sometimes we're lucky and grab a hold of a developer within the company that develops that editor and we get some information (usually just a confirmation that this is indeed a bug). With OpenOffice, this is a completely different story (finally!). If there's anything else you're interested in please drop me a line. Really looking forward to working with you guys! Best, Robert -- Robert Barbey Principal Software Engineer Integrations UI robert.bar...@acrolinx.com Acrolinx GmbH Friedrichstraße 100 | 10117 Berlin | Germany http://www.acrolinx.com/
