I’ve pulled the most common bits out of the Django views where I had rendered ODFs before and have the itty-bitty beginnings of an ODF handling/rendering library started now. “Library” is a bit of a stretch, since its only a few functions and a Bash script, but it abstracts the most mysterious/tedious parts of ODF handling already.
This is just a simple tarball right now. It unpacks like a Django app would, but only contains a copy of odfapper, funcs.py and a templatetags/odf_tags.py. But since we are doing template tag registration you need to include it in your INSTALLED_APPS in settings.py and add a new variable ODFAPPER_PATH which needs to be a string with the absolute path to /your/project/location/odfapper/odfapper. Importing into a views.py (or wherever) that you want to render ODFs in is done with from odfapper.funcs import render_odf, and I go into a bit more detail in the README included in the tarball. At the moment this post and the stuff in README (which is just an expansion of internal notes) is all the documentation.
I’ve got a ton more work I’d like to do on this. If there is any interest I could put a GitHub repo up — but other (paying) work calls to which this isn’t central, so… let me know if this is a direction anyone wants to head in and I’ll keep it going. There are a bajillion tiny things that are not so hard to do that would make ODF handling enormously more intuitive.
Link to 0.04 archive: odfapper_django-0.04.bz2
Link to just the shell update: odfapper-0.04.bz2
It bears mentioning that this is tested against Django 1.4, but not 1.5 yet. Unless the template loader classes have changed a lot then this should still work fine anyway, though.
I do lots of automated ODF rendering using framework data from AOW, Snap and Django. Its a pain to keep it straight, so I’m slowly extracting the common bits. The most annoying and easiest to distill is the basic process of guarding against clobbering something else in the filesystem, getting all the files out, reformatting the XML to be easier to edit, and later repacking it in a way that doesn’t make an office program tell you “This file is screwed up — I can fix it, but I hate you”.
Here is a script that handles the packing and unpacking of ODFs in a more friendly way than having to remember how all the time: ODFapper-0.01.bz2.
It takes very few options because it is written against my most common use case: unpacking to touch up a template, render the marked-up content.xml (and add images, or whatever) and then repack it to a new location from within a framework. In other words, ODFs can be used identically to HTML page rendering.
This is just a tiny part of what I do with ODFs, but it covers the most common bits (in particular, all that checking that a framework isn’t clobbering something in the filesystem), and answers the most frequent question I get from people who are curious about how I render ODFs: how to make them palatable to LibreOffice later.
I’ll eventually pull the rest of the render/repack ODF process out of my various programs that already do that and maybe make a for-real project of ODFapper. But that takes time, for now if you want an easy way to pack/unpack ODFs without screwing them up feel free to incorporate this script in whatever you’re doing. If you are a Bash wizard with suggestions, of course, I’m all ears…