The Lifecycle of LibreOffice Bugs

As developer of Gnumeric, during the interoperability testing of new Gnumeric features I often encounter LibreOffice bugs. In the past I tried to report all such bugs to LibreOffice since I would appreciate similar service from the LibreOffice developers. Over time I have come to recognize that the typical lifecycle of a LibreOffice bug differs greatly from that of a Gnumeric bug:

  1. Bug reporter files a bug report with all neccessary information.
  2. Optionally a significant amount of time later the bug is closed or requests more info since the LO developer looking at the report does not know of the existence of an ODF specification and is unable to look into the ODF file without opening it in LibreOffice.
  3. Optionally another person realizes that the bug as reported is in fact valid and the report complete.
  4. The bug is ignored for 6 months to one year.
  5. The bug status is changed to NEEDINFO with the following (or similar) notation added:

    "This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
    started right out as NEW without ever being explicitly confirmed. The bug is
    changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
    to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2
    Details on how to test the 3.5.0 beta1 can be found at:

    more detail on this bulk operation:"

  6. Half a year later the bug is closed with the notation:

    "Due to the fact, that there are a lot of NEEDINFO bugs with no answer within
    the last six months, we close all of these bugs.
    To keep this message short, more infos are available @

    Thanks for understanding and hopefully updating your bug, so that everything is
    prepared for developers to fix your problem."

Of course the problem at hand wasn't really my problem but LibreOffice's problem.

I guess in future I will save myself lots of time by not filing these bug reports in the first place.

Just for reference, the following are example bugs that have this or a similar life cycle:

Posted in Open Document Format & OpenFormula | Comments Off

Designed Incompatibility

In certain circles, Microsoft is usually blamed for "extend, embrace, extinguish" where the "embrace" stands for purposefully changing a specification to create incompatibilities. This post is not addressing Microsoft but another group that is usually more standards compliant: the Apache Foundation.

In the release notes of the new Apache OpenOffice release, changes to the TIME function are advertised:

Spreadsheet: TIME function returns values 00:00:00 <= x <= 23:59:59.999
The TIME spreadsheet function returns values between 00:00:00 and 23:59:59.999... inclusive and wraps values equal to or greater than 24:00:00.

It is easy to verify that Apache OpenOffice saves this function as the ODF OpenFormula function TIME:

<table:table-cell table:formula="of:=TIME(48;0;0)" office:value-type="time" office:time-value="PT00H00M00S"><text:p>00:00:00</text:p></table:table-cell>

This means that normally this function should be compatible with the ODF 1.2 part 2 specification as outlined in 6.10.17, where it says:

Syntax: TIME( Number hours ; Number minutes ; Number seconds )
Semantics: Returns the fraction of the day consumed by the given time, i.e.: ((hours*60*60)+(minutes*60)+seconds)/(24*60*60)
Hours, minutes, and seconds may be any number (they shall not be limited to the ranges 0..24,0..59, or 0..60 respectively).

So ODF requires TIME(48;0;0) to evaluate to 2, while in the new Apache OpenOffice it evaluates to 0.

Note that this is the value calculated, depending on the cell format this value could look differently.  Both LibreOffice and Gnumeric evaluate TIME(48;0;0) as 2, but LibreOffice shows it as 48:0:0 while Gnumeric shows it as 00:00.


Posted in Open Document Format & OpenFormula | Comments Off

The Illusion of ODF Interoperability

We recently saw the first release of Apache OpenOffice, one of the branches of the fork. Since the tangled mess usually known as the Open Document Format (ODF) was initially based on the file format, one could reasonably expect that Apache OpenOffice and LibreOffice are both quite successful in implementing that file format. Especially since Apache OpenOffice was according to the initial Apache incubator proposal intended to

serve as a reference implementation of the Open Document Format standard

one should have expected an attempt to provide a correct ODF 1.2 implementation.

In 2009, a bug was filed against That bug report was later moved to Apache OpenOffice and duplicated to LibreOffice. Essentially this bug is related to how errors return by OpenFormula formulas are saved inside the ODF file. It should have been relatively easy to fix this bug. Unfortunately the recent Apache OpenOffice release shill exhibits the faulty behaviour. As a consequence other implementations that endeavour to provide interoperability still have to work around this bug.

It has abundantly clear to me that both Apache OpenOffice and LibreOffice at most provide lip service with regard to interoperability.

Posted in Open Document Format & OpenFormula | Comments Off