Blogs | Open Document - Online Community for the OpenDocument OASIS Standard

First release of the Apache ODF Toolkit

Thu, 26 Jan 2012 10:02:03 -0500

The Apache ODF Toolkit 0.5 (incubating) release is now available for download. Detailed change notes are also posted. The ODF Toolkit is a Java library for reading, writing and creating ODF documents. It is entirely in Java and does not require that you install a desktop editor like OpenOffice. It operates directly on the file format and is suitable for server-side use, for tasks such as document automation, report generation, information extractions, etc.

As mentioned in a previous post, the Java components from the ODF Toolkit Union have moved over to Apache. Since this open source project was already using the Apache 2.0 license, the work required to achieve our first Apache release was relatively straightforward. The major task was to take the various components of the Toolkit, which were treated as independent projects at the ODF Toolkit Union, and get them to work better together as a single Toolkit, e.g., build together using the same version of the JDK, package them together into a consolidated release bundle. Not rocket science, but it did require some iteration.

We’re starting now to put together a plan for the next release and future releases. Some of the items under consideration include:

Adding document encryption/decryption support
Adding digital signature support
Update to final published ODF 1.2 schema
Update the demo applications
Concurrency testing
Adding support for ODF 1.2′s RDFa/RDF XML semantic metadata feature
Implement ODF 1.2′s OpenFormula spreadsheet formula language
Add high-performance event-driven streaming API, for subset of tasks that can be done efficiently that way
More cookbook examples
More testing and bug fixing

If you are interested in learning more about the ODF Toolkit, you should visit our website. If you have further questions, we have a users list and a development list that you are welcome to join.

If you know some Java and are interested in ODF, I’d encourage you to take a look at this project and consider participating. We are a small, international, welcoming group working on this project, with a strong focus on quality. Come, take a look.

Another AEGIS development: document accessibility checking - AccessODF

Tue, 08 Nov 2011 18:57:10 -0500

Over the past few years as part of the AEGIS project, our friends at the Katholieke Universiteit Leuven (K.U.Leuven) have released extensions to OpenOffice.org that allow users to create talking books in DAISY format (with odt2daisy), and to print documents in Braille (with odt2braille).

Today K.U.Leuven has announced something that makes both of these extensions even better: AccessODF. AccessODF is a third extension which adds a powerful accessibility checker to the office suite, allowing authors to find and fix accessibility errors in Writer documents. Properly marked up, accessible documents can then be used to generate accessible DAISY books, to print out properly formatted Braille documents, or to create accessible PDF files. AccessODF is fully cross platform, working on Windows, Macintosh, Linux, and Solaris. And like odt2daisy and odt2braille, it also works as an extension to LibreOffice.

AccessODF, along with odt2daisy and odt2braille, will be one of the highlights at the upcoming AEGIS Conference in Brussels at the end of this month.

Another AEGIS development: document accessibility checking - AccessODF

Tue, 08 Nov 2011 18:57:10 -0500

AccessODF, along with odt2daisy and odt2braille, will be one of the highlights at the upcoming AEGIS Conference in Brussels at the end of this month.

AES encryption for OpenOffice.org

Mon, 18 Apr 2011 08:14:16 -0400

The ODF 1.2 specification allows for stronger encryption algorithms, and Blowfish is declared as the legacy encryption algorithm.

The new version of the standard allows the encryption algorithms listed in §5.2 of xmlenc-core.

Many people wanted to see OpenOffice.org using AES encryption instead of Blowfish - and exactly this is what we have implemented for OpenOffice.org 3.4.

AES-256 encryption will be used for ODF 1.2 documents, but when you configure OOo to use ODF 1.1 or older, then of course Blowfish will be used.

In case you want to use the old encryption and hashing algorithms for ODF 1.2 documents you can configure OOo to do so. As this shouldn't be the case for most people, there is no UI for this, but the configuration files need to be changed directly. See the feature mail for more details.

AES encryption for OpenOffice.org

Mon, 18 Apr 2011 08:14:16 -0400

The ODF 1.2 specification allows for stronger encryption algorithms, and Blowfish is declared as the legacy encryption algorithm.

The new version of the standard allows the encryption algorithms listed in §5.2 of xmlenc-core.

Many people wanted to see OpenOffice.org using AES encryption instead of Blowfish - and exactly this is what we have implemented for OpenOffice.org 3.4.

AES-256 encryption will be used for ODF 1.2 documents, but when you configure OOo to use ODF 1.1 or older, then of course Blowfish will be used.

ODF Mime Type Icons Redesign

Thu, 17 Feb 2011 05:19:25 -0500

Dear ODF advocates,

as you might remember, in November 2010 Rosana announced the kick-off of the redesign project for ODF icons. She also explained the context conditions according to which the iTeam was expected to come to a solution.

Meanwhile a few things happened as the iTeam has been working through the issue and one particularly significant change in design was agreed upon in order to reach the required usability improvements. The change includes but is not limited to the transition of the blue ODF badge from its upper left cornet position to the bottom of the icon as proposed by Christian Jansen in his mockup.

So, in which way does this make sense? First of all it simple increases the area that can be used for the pictorial representation of the document type by > 16% as depicted in the illustration below.

It may seem little but there is an additional aspect of the transition that is not too obvious to the naked eye. Having the ODF badge at the upper right corner makes not only the area that is covered by the badge useless; it also impacts a great portion of its surrounding. This is due to the large luminance contrast that is induced by the highly saturated blue ODF badge and its almost white background. As a consequence, the perception of the surrounding and thus the perception of the content inside the icons’ upper half are altered significantly. Partially, due to a phenomenon which is called lateral inhibition. In very short, lateral inhibition means that the perception of one particular light source on the retina changes the perception of light in its surrounding via neural interactions that happen on the retina. Thus it is almost never the case that we mammals really get what we see in terms of light hitting our eyes.

Secondly, the displacement of the ODF badge also gives us the ability to use additional visual channels to convey important document type information: contour and orientation.

Contour contrast is particularly important, as the level of detail within the icons proportionally decreases with icon size. Therefore, pictorial information inside the icons becomes less relevant with decreasing icons size. This makes recognizing ODF documents rather hard if based on pictorial information solely.

As a consequence, we decided to use contour contrasts along with a significant increase of luminance contrast inside the icons to transport information according to which the users can more easily discriminate ODF document types.

Overall, this design decision enables us to make ODF file distinction to be supported via luminance and form/contour contrasts. Which is a significant improvement compared to the current ODF icons, without violating any ODF marketing constraints.

So, stay tuned! Further progress will be published on this blog. As always, everyone is welcome to provide constructive feedback.

Have a nice weekend!

Andreas

ODF Mime Type Icons Redesign

Thu, 17 Feb 2011 05:19:25 -0500

So, in which way does this make sense? First of all it simple increases the area that can be used for the pictorial representation of the document type by > 16% as depicted in the illustration below.

ODFDOM 0.8.7 - The new Release of the OpenDocument Java Library

Wed, 16 Feb 2011 11:03:08 -0500

The new version of ODFDOM - our Apache 2 licensed ODF library in Java has been released!

The major enhancements are:

ODF Validation

The option to validate the integrity of ODF documents is now able to be activated.
This new feature was demanded by the ODF Validator project to ensure non-XML ODF constraints.
Note: The ODF Validator has still its reason for existence, as XML Schema validation is not yet integrated into ODFDOM.

The design for validation is derived from the Simple API for XML (SAX). Validation is enabled by providing a validation handler which catches three types of events:

WARNING - if an optional constraint does not apply (in general written as SHOULD in the ODF 1.2 specification)
ERROR - if a mandatory constraint does not apply (in general written as SHALL in the ODF 1.2 specification)
FATAL ERROR - similar to ERROR, but recovery/loading was not possible (e.g. no ODF Package at all).

The constraints given by the ODF specification are already embraced in the library, but users might write their own validation constraints and use the validation mechanism.
The validation feature alone is worth to update to the latest version.

Further details on the mailing list.

Full Maven support

With ODFDOM 0.8.7 all signed artifacts - bundled sources, binaries and javadoc can be downloaded by other Maven projects using the public central repository.
Special thanks to Antonio Garcia Dominguez, who triggered this and gave the support to complete this feature.
Another benefit is that the deployment is automatic. Both the signing of the artifacts (PGP/GPG, SHA-1 & MD5) and the upload of the online JavaDoc is done by Maven.

Sub Documents

Sub documents are commonly used in ODF. The most frequent use case is with spreadsheets, where the user adds a chart for graphical representation of the spreadsheet data.
In ODF this is accomplished by embedding a Chart document within the spreadsheet.

The ability to embed a document within another was already introduced in the previous version, but only for ODF XML documents.
The real problem was that the saving of the ODF package did not automatically save all its sub documents.
This was fixed by introducing a Package level document base class called OdfPackageDocument, allowing in addition arbitrary non-ODF-XML documents using the library.

XPath

JDK XPath expressions may now include any user/custom XML that was loaded as part of the ODF XML or has been added to the DOM during run-time.
This includes custom XML added by any ODF applications. Arbitrary prefixes for ODF namespaces are switched safely back to the default namespace prefix used within the ODF specification (avoiding conflicts).

Design Update

Perhaps the major update of this release is the correction of one very early, unfortunately wrong design assumption: "Every high level object inherits from a DOM element."
We do now know that the potential benefits do not outweight the design problem. Especially as in reality there is no such thing as a 1:1 relationship. Instead there is an 1:n relationship: One high level component (e.g. an image) consists of multiple DOM elements (e.g. draw:frame/draw:image).
This correction triggered several API changes. To be described from an outside view: we removed all empty high level (DOC) classes (once generated) and moved those with meanwhile added functionality into an incubator package to be deprecated as soon as similar functionality is made available.

Further updates

Finally there had been several updates to the library. For instance, we integrated the latest ODF 1.2 schema from the OASIS ODF TC and our sources of the ODFDOM DOM model are now being generated from that schema.
The detailed task list for this release has been published together with a table to apply required API changes.

Enjoy the new version!

Svante Schubert - ODFDOM WG Chair

ODFDOM 0.8.7 - The new Release of the OpenDocument Java Library

Wed, 16 Feb 2011 11:03:08 -0500

The new version of ODFDOM - our Apache 2 licensed ODF library in Java has been released!

The major enhancements are:

ODF Validation

WARNING - if an optional constraint does not apply (in general written as SHOULD in the ODF 1.2 specification)
ERROR - if a mandatory constraint does not apply (in general written as SHALL in the ODF 1.2 specification)
FATAL ERROR - similar to ERROR, but recovery/loading was not possible (e.g. no ODF Package at all).