I wrote a blog post last year reporting about our import crash testing with a python script and how we use these results to improve our quality. Since last year we have extended the script and use it regularly on a TDF server.
Export crash testing
The largest change to the script was the new support for export crash testing. Every document that we successfully import is now exported to a number of formats depending on the application that opens it. Similar to the import testing crashes are logged into a file and are made available together with the import crash testing logs.
File Format Validation testing
Based on the exported files we started to run validators against the exported files. Right now we use officeotron for validating exported OOXML files and ODF Validator for validating ODF files. The logs for each document are written to an own file and published on a TDF server. Additionally to prevent introducing validation errors we started recently to use the same validators in our build to validate the files generated by our automated tests. Building with –with-export-validation and two scripts similar to the ones found here a validation error in the exported files will generate a test failure.
Increased document pool
At the time of my last blog post we were using a bit less than 25000 documents for the import testing. Since then we increased that number to about 54000 documents in many more formats. Together with the export testing which generates about 120000 documents with about 90GB of generated files the tests need about 3 days to run.
The reports have been incomplete recently as we have been hit by a bug currently suspected to be in the kernel. Around the 10000th document the load of the server increases without doing any actual work. We are currently trying to determine if it is a single document that is responsible or if it is a combination of a more complex setup. It has been limited to the 18000 writer documents already.
As always I’m looking for people who either want to fix one of the issues or improve the script.
Recently it came to our attention that we can only handle OOXML transitional and the older Microsoft dialect of OOXML. A short analysis of the document showed that OOXML strict uses different namespaces and different relationship URLs.
After two days of hacking and a lot of help from Miklos Vajna, who fixed the docx import problems, we support now OOXML strict import in master and in the Libreoffice 4-2 branch.
Please test this feature with a daily build or with the upcoming Libreoffice 4.2.3 and report problems that you have with OOXML strict.
Posted in Libreoffice
The new cppunit release which is just a minor update brings mainly support for 64bit Windows builds and fixed some packaging bugs related to the Visual Studio project files. For Linux/Unix users the only change is that we report dlopen errors now correctly thanks to a LibreOffice patch.
Please report bugs and feature requests to the freedesktop bugzilla or the developer mailing list. More information including the MD5 hash can be found on the project page.
I have been working recently on finishing the work on a python script for Libreoffice that automatically imports documents and tests if we crash there. The plan is to run this script automatically against all our bugzilla documents on a regular basis.
I have been running similar tests for calc files(the TEST_BUG_FILES) case already before the 3.5 and the 4.0 releases and fixed these crashes with Eike and Kohei before the releases. However this work was done half manually inside of an “unit” test and as soon as it crashed I had to restart the test. As a result of this complex setup it took me between 4 and 6 days to import all 6000+ calc documents. Back then I already had the idea that this task could be automated and moved to a TDF server.
I already tried to convince someone at the Munich hackfest to write such a script as an Easy Hack but had to wait till December until Joren picked up the task. Based on convwatch.py he implemented the first version that has undergone several iterations now and can be found in the Libreoffice dev-tools repository. The script is still looking quite ugly as I have been only adding code and it still contains a large number of debug output for me but the current version should work fine against current Libreoffice master.
After several toolchain problems, one needs a libstdc++ created with at least Linux binutils 18.104.22.168.1 or newer, I finally published the results of the current test run at the Libreoffice developer mailing list. In my latest test run I had a collection of a bit more than 24500 documents with the file extensions cdr, doc, docx, fodg, fodp, fods, fodt, odg, odp, ods, odt, ppt, pptx, pub, rtf, vdx, vsd, wpd, xls, xlsx. While 60 crashes might sound like a lot one has to remember that many of these crashes will never be seen by users. The test is run with a dbgutil build which means that we enforce the exception specification, we switch the standard library to the gcc debug library which has additional assertions and some crashes are related to the special set up of the test. Nevertheless we are planning to fix all these crashes and use the script as part of our automatic testing.
And finally a special thanks to the amazing Libreoffice community who was incredibly supporting in realizing this crazy concept.
So after reading several times on another mailing list that Libreoffice developers should relicense their patches to make them available to other descendents in the OpenOffice.org ecosystem I’m indirectly responding in this blog post and explaining why I contribute to the Libreoffice project and license my changes only as LGPLv3+/MPL. This reflects of course only my personal opinion.
After our first cppunit release 1.13.0 has been released about two months ago I’m now proud to announce 1.13.1, a small bug fix release for the 1.13 line. You can find the release tarball at the cppunit freedesktop page.
The changes against 1.13.0 are rather small:
- a fix for a crash happening when mixing different gcc versions and demangling fails (fdo#52539)
- using portable way to include header for free (fdo#52536)
Thanks especially to Andriy Gapon for the bug reports and the bug fix.
Please report all bugs you find with this release to bugs.freedesktop.org under the Libreoffice component.
Color scales and data bars are one of our new features in Libreoffice 3.6 You can find more new and cool features in our Release Notes.
But what are color scales and data bars?
Color scales and data bars are a cool way for spreadsheet users to quickly visualize a set of cells. Color scales allow users to automatically color a range of cells depending on their value. In contrast to normal conditional format you no longer need to specify all colors and the corresponding value, instead you can just specify the start and end point and the corresponding color and Calc will calculate the value of each cell automatically.
Data bars however are a bar inside a cell that makes it extremely easy to visualize the amount a cell value represents relative to the other cells.
But enough with this technical talk. A picture shows more than 1000 words. This screenshot shows the fictitious sales of 4 sales person during one week and uses color scales to highlight the sales per day and uses a data bar to highlight the weekly sales.
I hope you agree with me that these visual helps make it easier for anybody to see the central points inside all these values. Now you no longer need to study each single value, the visualization of the values will already help you understand the central points of the spreadsheet without the need of studying all details of the spreadsheet.
And what will be added in Libreoffice 3.7?
In Libreoffice 3.7 I will add some more features. Currently already implemented are AutoMin and AutoMax for data bars. These make it much more easy to control the form of the data bar. AutoMin is just a short version for the Minimum of zero and the smallest value of the range and AutoMax as maximum of zero and the largest value of the range.
In a current master build you can also already test the new export of color scales and data bars to XLSX, we even support the advanced data bar features that Microsoft introduced with Excel 2010.
Another big feature for 3.7 will be the possibility to overlap different conditional formats and if I find some time I would like to improve the new conditional format dialogs. They are not as nice as they should be because the design proposal of our amazing UX team needs these overlapping conditional formats.
Also some performance improvements are already integrated into master or will be implemented soon.