Another script: revision controlled OpenOffice.org documents

I mentioned that I used OpenOffice.org for my thesis.

However, a problem is that binary files, like .ODT, don't work well with revision control systems.

Firstly, they aren't diff-able so you have to also keep a .TXT file, in the repository, in sync with the .ODT. This is error-prone and the .TXT diffs don't reflect formatting changes.

Secondly, because OpenOffice.org files are compressed (.ZIP format), the binary deltas that revision control systems (e.g. SVN) use to save space fall apart for even the tiniest of changes to documents, due to the characteristics of compression.

But thanks to the second anonymous commenter on that blog post, I came up with a new way of revision-controlling OpenOffice.org documents:

What I now do is keep the unzipped OpenOffice.org document in revision control, not the binary .ODT file. This means that I can diff the content.xml between revisions, not bother keeping a .TXT file in sync and avoid SVN's space-inefficient binary deltas since I'm really only keeping text files in the repository (more on this later).

If you checkout such an unzipped OpenOffice.org document from SVN, you can use my magic Makefile to reconstruct the .ODT from these unzipped contents by typing make. It's just like adding water to milk powder.

And every time you make a change to the .ODT file, the same make command works the other way and updates the unzipped contents to match the changed .ODT. Then you can svn commit a new revision.

Caveats:

* Warning: svn status will not report changes to the .ODT, until you type make. Be careful or you might think that your checkout has no local changes and you decide to delete the checkout to "save space"! A "foolproof" way to get around this problem is to skip the svn propedit svn:ignore . [and type kolourpaint-developer-guide.odt] step.

* It actually does store a binary file in revision control, namely Thumbnails/thumbnail.png. I haven't dared try to work around this though, for fear that OpenOffice.org won't like me playing with it.

* Some files such as layout-cache and settings.xml, while not binary unlike Thumbnails/thumbnail.png, change on every save and probably shouldn't be revision controlled either.

* You can't have 2 people working on the same document as merging two content.xml files is asking for trouble. But at least you can diff between revisions.

* A lot of lines in content.xml may change in response to even a small layout change due to lots of tags changing control numbers.

If you try this scheme, please let me know how it goes.

BTW, in the end, my thesis turned out to be 192 pages (probably, about 100 pages too long :)). It was on porting the L4 microkernel to processors without virtual memory, specifically the Blackfin processor. It was written in a rush so apologies for the awful number of spelling and grammatical errors!

A few scripts that could be useful

I just uploaded some scripts I've had lying around for months. Hope they're useful:

1. kbus: starts the DBUS server since it's not done automatically. Sure beats typing eval `dbus-launch --auto-syntax` and copying environment variables all the time.

Update: It looks like DBUS has an auto-starting feature now, via --ensure, so this script is no longer needed).

2. svnupfast: an "svn up" that takes half the bandwidth.

3. svn-import-changes: a poor person's distributed revision control system.

Full details and "sort of" docs here.

Re: We’ve got a couple of feet in our sights

Regarding a few things Boudewijn Rempt wrote about the look of KDE:

1. I actually thought Keramik was stunning during the early builds of KDE 3.1 - it was the perfect balance between good eye candy and not being so noticeable that it got in the way. Unfortunately, I believe it changed in the final KDE 3.1 (please correct me if I'm wrong) and the gradients became too striking.

I liked it in combination with KDE 3.1's bluish icon set, which was sadly replaced in KDE 3.2.

I still use Keramik with the KDE 2 colour scheme and I like it better than Plastik (which is still a very good theme).

2. The window colour changing on focus switches in KDE 4 is a feature of the style, I believe. It is really slow indeed on my old graphics cards as well and for a while I thought it was a palette bug, until I realised that it was supposed to be highlighting the focused window.

I'm sure this will be fixed eventually but I'd still expect KDE 4 to be a tad slower than KDE 3 because of Qt4's automatic double buffering. But I think this is a reasonable price to pay for less flicker.

On a side note, for those of you who are wondering, that automatic double buffering is actually done per top-level window, rather than per widget (I looked inside the Qt code for this and it's actually quite clever).

Why UI messages must be carefully worded

I got this email from the university today:

Your overall [average mark]: 87.0

There were no outstanding results at the time of this calculation.

Apparently, none of my results are any good ("outstanding"). I feel insulted...

... but obviously, that's not what they meant. They should have used "unfinalised" instead of "outstanding" to be unambiguous.

And no, 87.0 is not my real mark. I'm not going to post the real mark here because there are some fellow students running around uni trying to find out my marks, for god knows what reason, so no need to make it easy for them :)

A fix for Radeon Xpress lockups under X.org

I'm writing this article so that people googling can find the fix.

I just helped some fellow UNSW students fix Linux hanging when performing a graphical login (no, even the magic sysrq keys I enabled did not help). They were running X.org 6.8.2 (Fedora Core 4) with an ATI X600 graphics card (Dell Optiplex GX620).

I solved this by switching from the buggy opensource radeon driver to the generic VESA driver i.e. in /etc/X11/xorg.conf under Section "Device", I changed:

Driver "radeon"

to

Driver "vesa"

There are also 2 other solutions that apparently work:

1. Richard Zach suggests using the binary ATI driver.

2. Those students found that the opensource radeon driver worked if they updated to X.org X11R7 (Fedora Core 5) [*]. Unfortunately, they need to run some closed-source software that only supports Fedora Core 4. Furthermore, this upgrade does not seem to help with an ATI X200, which experiences similar lockups.

[*] Does anyone know the exact version X.org number?