OOoPy 0.2

OpenOffice.org (OOo) documents are ZIP archives containing several XML files. Therefore it is easy to inspect, create, or modify OOo documents. OOoPy is a library in Python for these tasks with OOo documents. To not reinvent the wheel, OOoPy uses an existing XML library, ElementTree by Fredrik Lundh. OOoPy is a thin wrapper around ElementTree using Python’s ZipFile to read and write OOo documents.

In addition to being a wrapper for ElementTree, OOoPy contains a framework for applying XML transforms to OOo documents. Several Transforms for OOo documents exist, e.g., for changing OOo fields (OOo Insert-Fields menu) or using OOo fields for a mail merge application. Some other transformations for modifying OOo settings and meta information are also given as examples.

Applications like this come in handy in applications where calling native OOo is not an option, e.g., in server-side Web applications.

Don’t be alarmed by the Alpha-Status of the Software: Reading and writing of OOo documents is stable as well as most transforms.

The only problematic transform is mailmerge: The OOo format is well documented but there are ordering constraints in the body of an OOo document. I’ve not yet figured out all the tags and their order in the OOo body. Another known shortcoming of OOoPys mailmerge is the renumbering of body parts of an OOo document. Individual parts (like e.g., frames, sections, tables) need to have their own unique names. After a mailmerge, there are duplicate names for some items. So far I’m renumbering only frames, sections, and tables. See the renumber objects at the end of ooopy/Transforms.py. So if you encounter missing parts of the mailmerged document, check if there are some renumberings missing or send me a bug report.

Another reason for the Alpha-Status is stability of the API. I may still change the API slightly.

For running the doctest on python2.3 with the metaclass trickery of autosuper, see the file run_doctest.py.