Here is some Java code that creates a <number:date-style> element from a format string. The format string is much like the strings used in Java’s SimpleDateFormat class.

Some of the format specifiers do not exist in ODF, and I have added the Q format specifier for “quarter.” If you repeat the Q three or more times, you get the long format, such as “3rd quarter”; if repeated less than three times, you get the short form of “Q3.”

If you only use format specifiers for hours, minutes, and seconds, the code creates a <number:time-style> element instead.

A test file is also available. To use the test file, just type something like this, where the classpath is set to where you have the appropriate files.

java -cp lib/odfdom.jar:lib/xercesImpl.jar:. TestDateStyle outputfile.ods

ODFDOM is now in version 0.6.6, and correctly builds empty spreadsheets, so I have updated the ODFDOM program.

MakeChangeList.java
ChangeInfo.java

While the other toolkits are fairly low-level and expose every part of the XML in their interfaces, jOpenDocument appears to be meant to be used at a higher level.

For example, I needed to assign the office:value-type="date" to certain cells, but the method for setting the type was private, and thus inaccessible to me. It turns out that if you do a cell.setValue(dateObject), where dateObject is of type Date(), jOpenDocument figures this out and assigns the correct office:value-type.

jOpenDocument is easier to use when modifying existing spreadsheets than creating one from scratch. Adding a <number:date-style> to a new spreadsheet was a task I did not want to try to analyze, so, for this version, I have used a template spreadsheet file.

Here is a tarball containing the code, an auxiliary class it uses, the template spreadsheet, and a couple of shell scripts I used to help me compile and run the code. (If you are using Windows, you can download 7-zip to unpack the tarball.)

The problem was that a previous attempt at a patch (changing use XML::Twig to use XML::Twig::XPath) hadn’t been changed back. As soon as i fixed that, my test program worked.

Writing the remainder of the code became much simpler once I realized that all the objects I created were really instances of XML::Twig::Elt, which meant that I could use all of XML::Twig::Elt’s methods.

Here is the code.

OODoc is stalled; I’m getting an error with XML::Twig::XPath trying to parse the string “#PCDATA”, which, of course, isn’t any sort of XPath at all.

jOpenDocument doesn’t seem happy to read a plain .odt file; it is protesting a
<text:p> that is not inside a <table:table-cell>.

I’m putting everything on hold for the next week or so.

At the risk of starting a language flamewar, a toolkit written in Java would seem to get the most bang for the buck. A Java toolkit can be used with Java, Groovy, JRuby, Jython, and Scala. That’s pretty good leverage.

I can’t seem to get OODoc to use XML::Twig::XPath on an input document, so, after several attempts, I will use XML::Twig::XPath directly to parse the input, and then use OODoc to create the output.

I am working on the OODoc version of the program now, and am trying to use an XPath expression:

text:deletion|text:insertion|text:format-change

but XML::Twig does not support the | operator. The XML::Twig documentation says that you can use XML::XPath if you have it installed (and I do), but does not tell how you get them to work with each other. That is, I cannot find a way to findnodes directly on an odfDocument.

For the moment, I will just use three calls to getElement; I will figure out how to do it the right way later.

ODFPy is also very close to the XML. It does not have the capability to read an existing file, so I had to unpack the file and use XPath to get the changes out of the original file. Once I had that done, building the output spreadsheet was remarkable similar to the ODFDOM version. In fact, a large part of the work was taking the Java and transforming it to Python–the logic stayed pretty much the same.

Here is the code.

Most of the people I’m working with on these toolkits are in Europe, and it’s a nine-hour time difference between central European time and Pacific time. That means that I have to be up at 6 a.m. to get in at any reasonable part of their working day. (They all appear to have a life, so most of them aren’t working after 6 p.m. or so.) And, even though I don’t have a life, I am not keen on staying up past midnight to get in at the beginning of their working day.

I tell you, it’s just killing me. <grin/>