Free opendocument software for linux

There are some interesting projects (OpenDocumentPHP, OpenDocument Fellowship) around the creation of OpenDocument Text from a Web-application.

Thus far none of these projects yielded a result to create an OpenDocument Text. Therefore - and inspired by an article in the German cumuter magasin ct - I desiced to implement a libary that takes a template document and adds some to it.

OpenOffice::OODoc::Intro is a Perl module for an introduction to the Open OpenDocument Connector.

The main goal of the Open OpenDocument Connector (OODoc) is to allow quick application development in 2 areas:

- replacement of old-style, proprietary, client-based macros for intensive and non-interactive document processing;
- direct read/write operations by enterprise software on office documents, and/or document-driven applications.

OODoc provides an abstraction of the document objects and isolates the programmer from low level XML navigation, UTF8 encoding and file compression details. For example:

use OpenOffice::OODoc;
my $document = ooDocument(file => filename.odt);
$document->appendParagraph
(
text => Some new text,
style => Text body
);
$document->appendTable("My Table", 6, 4);
$document->cellValue("My Table", 2, 1, "New value");
$document->save;

The script above appends a new paragraph, with given text and style, and a table with 6 lines and 4 columns, to an existing document, then inserts a value at a given position in the table. It takes much less time than the opening of the document with your favourite text processor, and can be executed without any desktop software connection. A program using this library can run without any OpenOffice.org installation (and, practically, OODoc has been tested on platforms where OpenOffice.org is not available yet).

More generally, OpenOffice::OODoc provides a lot of methods (probably most of them are not useful for you) allowing create/search/update/delete operations with document elements such as:

- ordinary text containers (paragraphs, headings, item lists); - tables and cells; - sections; - images; - styles; - page layout; - metadata (i.e. title, subject, and other general properties).

Docvert web service software takes multiple word processor files (typically .doc) and converts them to Oasis OpenDocument v1.0 format, and then optionally runs them through an XML pipeline. The result is returned in a .zip file.

Docvert builds upon OpenOffice.org because it has the best chance of dealing with the vagaries of the MS Word format.

The resulting XML is themable with XML/XSLT Pipelines, which supports breaking up content over headings or sections, multiple serializations and pipeline branching.

Docvert is easy to integrate as it uses a simple REST-style interface, and its released under the LGPL so although its open source theres no legal problems developing proprietary software ontop of it.

Right now Im looking to bundle themes, so if youre an XSLT programmer send in your themes and Ill include them in the next release. Oh, and any patches or suggestions would be appreciated!

OpenOffice::OODoc::XPath is a Low-level XML navigation in the documents.

This module is a low-level class which uses OODoc::File (without inheriting anything from it) along with the classes defined in the XML::Twig module. Its a common basis for the other, more user- friendly, document-oriented modules. It uses XPath expressions in order to retrieve any document element (but it doesnt provide a full implementation of the XPath standard). In addition, while the most part of the provided methods are OpenDocument-aware, this module could be used against any other kind of XML documents, simply because it benefits from all the features of XML::Twig. Such a possibility may prove useful for applications that simultaneously process OpenDocument and non-OpenDocument XML files.

The OpenOffice::OODoc::XPath class should not be explicitly used in the applications, because all its features are available in more user-friendly classes such as OODoc::Text, OODoc::Styles, OODoc::Image, OODoc::Document and OODoc::Meta. The present manual page is provided to describe the common methods and properties that are available with all these classes.

This chapter can be skipped by programmers who are only interested in upper level methods provided by the OODoc::Text, ::Styles, ::Image and ::Meta modules. Understanding these modules is easier and using them requires less Perl and XML expertise. However, calling OODoc::XPath methods remains a good rescue option as it allows all kinds of operations on all types of XML elements contained in any OpenDocument-compliant file.

OODoc::XPath is the common foundation of OODoc::Meta, OODoc::Text, OODoc::Styles and OODoc::Image. It contains the lowest layer of navigation services for XML documents and handles the link with OODoc::File for file access. Its primary role is as an interface with the XML::Twig API.

In the present manual chapter, you will see "elements" often mentioned. When it says that a module expects a parameter or returns an element (either singly or as a list), it is referring to an XML element. It is important to distinguish elements from their content (elements being simply references to XML data structures). To read or modify the content of an element such as its text or XML attributes, use the accessors also available within OODoc::XPath.
In most cases where XPath methods require a reference to an element as an argument, there are two ways of proceeding:

- reference the element directly (obtained previously)
- or give an XPath expression and a position, being a string and an integer respectively; for example, the pair (//office:body/text:p, 12) or (//text:p, 12) represents the thirteenth occurrence of the text:p element, i.e. the 13th paragraph (occurrences are numbered starting from 0).

The second way requires the knowledge of an appropriate XPath expression (according the OOo/OpenDocument XML format specification). And a given XPath expression is not necessarily the same with an OpenDocument as in an OpenOffice.org document. So you should preferently use high level accessors (provided by derivative classes such as OODoc::Document) and avoid XPath hardcoding. However, you know you can at any time reach any element with XPath.

Of course, you will never need to use XPath expressions in order to reach the most common text elements (such as paragraphs), because the OODoc::Text module provides more friendly accessors (for example, you will probably use the getParagraph() method and forget "//text:p").
Some methods accept both forms which means that if the first parameter is recognised as an element reference, the position does not need to be given. Therefore the number of arguments for certain OODoc::XPath methods can vary.

For those who really want to access all areas there are also OODoc::XPath methods which allow unrestricted access to every element or XML attribute via an access path in XPath syntax. If you are into this kind of thing, we recommend you obtain good syntax reference manuals for XPath and OpenOffice.org and a supply of aspirin.

Methods which may return several lines of text (e.g. getTextList) do so either in the form of an unique character string containing "n" separators or in table form.

Unless otherwise stated, the word document in this chapter only refers to XML documents contained within OODoc::XPath objects and not, say, OpenOffice.org files (as an end user would use).

Amongst the different methods which return elements, attributes or text, some are called getXxx, others selectXxx or findXxx. Read methods whose names start with "get" generally refer to an unfiltered object or list, whereas others return an object or list filtered according to a parameter value. In this latter case the search parameter is treated as a standard expression and not an exact value. This means that if the search criteria is "xyz", all text containing "xyz" will be considered a match. To restrict the search to text exactly equal to "xyz", use "^xyz$" as the search criteria (following Perl regular expression syntax).

Several methods allow you to place copies of or references to elements (from other documents or from other positions in the same document) in any position in the current document. This offers powerful manoeuvrability but only if these placements conform with the destination positions context.

For example, you can easily copy a paragraph from one document to another but only if you knowingly modify the paragraphs style attribute if that style is not already defined in the destination document. You can also copy the style but only if you are sure that this style is not already defined by another unknown style in the destination document (and so on).

For advanced users familiar with the XML::Twig API, it might be interesting to know that all the objects called "elements" in the following chapters are objects of the

OpenOffice::OODoc::Element class, which is an XML::Twig::Elt derivative. So all methods associated with this class are directly applicable to these elements, on top of the functionality described in this manual. However, the knowledge of XML::Twig is not mandatory.

Important note: The applications should not explicitly work with this class. We recommend using OODoc::Meta and OODoc::Document (which are both OODoc::XPath derivatives). These two objects provide highest-level methods which are neater and more productive. Explicit use of OODoc::XPath methods (which sometimes require large numbers of parameters) should only be considered as a last resort in unexpected circumstances for access to any element or XML attribute not handled by more friendly methods. However, the present manual chapter could prove helpful because all the common features of OODoc::Meta and OODoc::Document are described here.

OpenOffice::OODoc::Styles is a Perl module for document styles and layout processing.

This class is designed to handle styles, whether automatic or named, contained in styles.xml or content.xml. It inherits from the common OpenOffice::OODoc::XPath class and brings style-focused features.

This class should not be explicitly used in an ordinary application, because all its features are available in the OpenOffice::OODoc::Document class, in combination with other features. Practically, the present manual is provided to describe the style processing features of OpenOffice::OODoc::Document (knowing that these features are technically supported by the OpenOffice::OODoc::Styles component of the API).

Remember that named styles are those that the end user can see and edit using the Stylist tool in OpenOffice.org. Such styles usually have meaningful names and are stored in the styles.xml member. But an OpenDocument-compliant style may own two names, so-called name and display-name. The display-name is the name as its displayed by the office software, while the name is the main identifier. Both are displayable character strings, but they often differ. For a given display-name, the application software is allowed to set any arbitrary name. For example, with OpenOffice.org 2, the well-known pre-defined style whose display name is "Text body" is named "Text_20_body" (the space character is replaced by its hexadecimal value between two "_" characters). In the other hand, the name and the display-name generally dont differ when they contain letters and/or digits only. Remember that the name (and not the display-name) is the main identifier of a style element. So, such a method as getStyleElement("style name") uses the name attribute to retrieve a style descriptor (unless you change this behaviour through the retrieve_by document property).

Care should be taken particularly with predefined base styles in OpenOffice.org. These styles are described in styles.xml just like named styles, but they appear to the end user with localised names (in their local language), so the really displayed style name is neither the name nor the display-name stored attributes. For example, in the French distribution of OpenOffice.org, the "Text body" style appears as "Corps de texte", while its "display-name" is "Text body" and its "name" is "Text_20_body". However, this is not a problem for user-defined styles as the stored display-name is exactly the same as the effective display name.

There are also numerous "automatic" styles in a document which are created implicitly by the office application each time a particular set of presentation attributes is given to an element, but where no named style is referenced. Automatic styles which apply to the document body are stored in content.xml (but in an XML element isolated from the content). An automatic styles name can change randomly each time the document is edited or saved in OpenOffice.org.

Applications which access automatic styles will not want to indicate them using "hard-coded" names. The best way is to retrieve each automatic style via an object that is known to use it. Using a "hard-coded" name is all right for styles created by a program (the createStyle() method requires it), but such a name should only be considered to be stable for the duration of the session. If you want a program-created style name to be then respected by OpenOffice.org, you must create it as a named style.

This is no more complicated, but it is better to avoid making hundreds of styles visible to the user that they do not need to see.
There are some structural differences between the old OpenOffice.org 1.0 format and the new OASIS Open Document (ODF) one. A few of these differences arent made fully transparent by OpenOffice::OODoc. So, in some cases, a program including style definitions or updates doesnt produce exactly the same results with both OOo 1 and OOo 2 documents.

Some styles are more complex than others as they describe the page layout. These styles can themselves contain text and images. A page style, or a "master page", can actually define a header, a footer, margins, and a background. Headers and footers can contain text and images which can otherwise be handled by OODoc::Text and OODoc::Image. A background contains a colour and can also include a background image (several methods are possible).
Presentation of these objects is itself controlled by styles.

All of this leads to the conclusion that it is not enough just to associate each content element with a style. In reality, document styles form a rather complex network of interdependencies.
As for page styles, the OpenOffice.org format contains a concept which must be understood in order to use some of the following methods. By virtue of the principle of separation of content and presentation, the definition of a page style is based on two distinct objects: "master page" and "page layout". A "master page" object encompasses any page style content (i.e. the content of headers and footers) and links to a "page layout" object which describes page presentation characteristics (with large numbers of parameters from page dimensions to background colour to footnote separator size, etc.). Names which appear in the list of page styles in OpenOffice.org are actually names of "master pages". However, to work with physical aspects of the presentation, you have to access the associated "page layout".

To complicate matters, there are also header and footer styles. Each object contained in a header or footer (e.g. paragraph or image) has a style. The number and range of styles are much larger that you would imagine just looking at the Stylist tool in OpenOffice.org. Up to a point, OODoc::Styles methods make life easier for you by masking some of this complexity.
In OODoc::Styles methods, styles are normally indicated by their logical names (which must be unique), but, except where otherwise stated, they can also be indicated by their style element reference. Moreover, when a method is expecting a page layout as an argument but the programmer passes it a master page instead (whether by design or by mistake), it "knows" in most cases how to automatically select the associated page layout.

Defining a style requires a great many attributes. Some appear in code examples in this manual, but for a full list of possible attributes for each style, you must refer to the OpenOffice.org specification or publications derived from it.

OODoc::Styles module is designed to allow applications to manipulate any style and even create new ones. It is not recommended, however, to use it to create a presentation entirely from code. Here again, it is better to start from document templates which already contain at least a blank of each required style.

JODConverter, the Java OpenDocument Converter, converts documents between different office formats.
The project leverages OpenOffice.org, which provides arguably the best import/export filters for OpenDocument and Microsoft Office formats available today.
JODConverter automates all conversions supported by OpenOffice.org, includin:
Microsoft Office to OpenDocument, and viceversa
- Word to OpenDocument Text (odt); OpenDocument Text (odt) to Word
- Excel to OpenDocument Spreadsheet (ods); OpenDocument Spreadsheet (ods) to Excel
- PowerPoint to OpenDocument Presentation (odp); OpenDocument - Presentation (odp) to PowerPoint
Any format to PDF
- OpenDocument (Text, Spreadsheet, Presentation) to PDF
- Word to PDF; Excel to PDF; PowerPoint to PDF
- RTF to PDF; WordPerfect to PDF; ...
And more
- OpenDocument Presentation (ods) to Flash; PowerPoint to Flash
- RTF to OpenDocument; WordPerfect to OpenDocument
- Any format to HTML (with limitations)
- Support for OpenOffice.org 1.0 and old StarOffice formats

OpenOffice.org Utility Library, or ooolib in short, is actually more than one library module. Included are a Python module (ooolib-python) and a Perl module (ooolib-perl).
The Python module is currently focused on Calc and can be used to create OpenDocument Format Calc spreadsheets.
The Perl module can be used to create simple OpenOffice.org Calc spreadsheet and Writer text documents. (Note: The files created by ooolib-perl are pre-ODF files.)
Main features:
- Ability to create OpenOffice.org Calc Documents
- Example programs that use the Python Module