Have let myself get elected as a member for the school board of the elementary school my daughter goes to. Well, I suppose I felt like I had some spare time to spend. Now, guess what they make our first job: Come up with an emergency plan for contacting all parents in case something happens that requires the kids to be picked up from school early and quickly.
How cool! I started thinking SMS relays and e-mail notifications or voice response systems, but then I calmed down a bit. After all, you don’t want to rely on Deutsche Telekom in such a case 😉
But still it was first a nice algorithmic challenge. Will we do it the centralised way where two parents call all the rest? A chain suffers from the risk of being broken. The centralised approach, however, puts a lot of responsibility on one or two people, and rotating this responsibility over seventeen parents in twelve months (take away the holidays) sounds rather confusing. So we decided to go for the chain after all, but make it a double chain that starts from the head and tail and meets in the middle. That can survive a single break and still reach everybody else without further manual intervention.
Then I wanted to create a document to visualize this. I was thinking of two colums of rectangles with the name of one child and relevant contact information in each and arrows coming down each column and going back up the other. Then, if the number of kids was uneven, the middle element should be centered below the two major colums. Should be easy. I can imagine it, I should be able to do it.
So, first I took a look at OpenOffice’s serial letter functionality. It didn’t quite get me there, because I wanted the total number of children displayed to be variable (why class 1a might like this 😉 ), but I also wanted the topmost elements to be the first child in the list and the last one, the first one to the left, the last one to the right. But how do you know, in a serial letter document, how many list elements you have? … Not at all!
Then I looked at jasperreports which I already use in the context of Sun’s Role Manager product. But it essentially has the same problem of having to know the number of elements you will be seeing in advance. That is especially true, if you don’t have a genuine SQL database where you can just do “select count(bla)” but a CSV file. There are supposedly ways of doing that by using invisible subreports that do a noop for each element and return the total number to the main report which can then pass it to another subreport to do something with that information. Well, I couldn’t get any of that to work and it seemed overly complicated. Also, I was not sure I would get the layout flexibility I was looking for. So on we go ….
… and take a look at LaTeX. Wow, I’ve been doing UNIX for almost two decades now and haven’t use any form of TeX before, where some people consider it the best thing since bread can slice. Well, initially I was making some progress down that road with a perl script generating LaTeX definitions from my CSV. I was already looking at some of the more complex packages like xy-pics, when I got bored with the syntax and the fact that I would need a special package for every other feature I was looking for and that my document that I envisioned more like a colourful flow-chart type of thing would be likely to scare people by its mathematical formula looks.
Then I had a brilliant idea!
I had hitherto completely overlooked that OpenOffice essentially is a plain text format, too. After all, it is XML and all I would need do is make my perl script generate the right XML rather than LaTeX directives. And guess what, it really works well (give and take things like Netbeans not supporting the relax-ng XML schemata OpenOffice uses). The only thing you seem to need to watch out for is that you should not change the compression parameters when unpacking the OpenOffice document. What I did was, generate my content.xml, open a dummy OpenOffice Writer file with file-roller and drag and drop my generated content.xml into the open file-roller window. Then open the document with OpenOffice to look at it.
Coming to think of it, I could even have done it smarter still. Rather than maintaining the list of names and telephone numbers as an ODS file and save it to CSV for it to be processed through my perl script to generate an ODT file again, I could have created an XSLT stylsheet to do an ODS to ODT conversion directly with all the required formating. There is an interesting tutorial on this web-site by that other IT company with a three-letter name. Not the one I work for, but hey, credit where credit is due.
But I suppose I’m not nerd enough to refactor my working version.