The data point objects support now the com.sun.star.drawing.FillProperties service similar to the other chart objects. This finally allows to access all chart2(not chart1) objects with the same fill property set names.

For the data points we now have the additional property names:

FillColor

FillTransparence

FillTransparenceGradientName

FillGradientName

FillGradientStepCount

FillHatchName

This change will be available in LibreOffice 5.1, currently scheduled for the beginning of February 2016.

I also filed an EasyHack to support FillTransparenceGradient, FillGradient, FillHatch and FillBitmap which would simplify handling of the fill properties even further.

]]>https://mmohrhard.wordpress.com/2015/07/28/new-fill-property-names-in-chart2/feed/0mmohrhardSupporting more OOXML dialects in chart importhttps://mmohrhard.wordpress.com/2015/03/11/supporting-more-ooxml-dialects-in-chart-import/
https://mmohrhard.wordpress.com/2015/03/11/supporting-more-ooxml-dialects-in-chart-import/#commentsWed, 11 Mar 2015 20:27:34 +0000http://mmohrhard.wordpress.com/?p=98Continue reading →]]>A common problem during our OOXML import is that there are several different OOXML dialects: OOXML transitional, OOXML strict and the not specified version written by MSO 2007. The MSO 2007 version is mostly identical to OOXML transitional with the small but nasty exception that they have some differences in the default values. Recently I got a document from a Collabora customer using MSO 2007 exhibiting some bugs related to that.

A few days ago I finally managed to bring support for handling the differences between the OOXML dialect written by MSO 2007 and the one in the specification to LibreOffice. This is an important step forward for our OOXML chart import as that code was written against the MSO 2007 version and more and more documents are generated by newer MSO versions. In recent years we have changed quite a few of the default values in the code to handle OOXML specification conforming documents correctly. Sadly this introduced a number of regressions for the handling of MSO 2007 documents.

With [1] and [2] we are now able to recognize files that have been created by MSO 2007 and are able to use different default values. Currently this is only used for the flag that decides if the chart title is deleted but more cases might be fixed in the future.

]]>https://mmohrhard.wordpress.com/2015/03/11/supporting-more-ooxml-dialects-in-chart-import/feed/2mmohrhardGuadec 2014https://mmohrhard.wordpress.com/2014/08/03/guadec-2014/
https://mmohrhard.wordpress.com/2014/08/03/guadec-2014/#commentsSun, 03 Aug 2014 21:10:44 +0000http://mmohrhard.wordpress.com/?p=88Continue reading →]]>I had the privilege to attend GUADEC this year and speak about Libreoffice. I was really impressed by the conference and enjoyed the beautiful city of Strasbourg and the nice Gnome community.

The next conference that I will attend will be the LibreOffice conference in Bern, Switzerland where I will give presentations about OpenGL in Libreoffice, recent development in charts and automated testing.

]]>https://mmohrhard.wordpress.com/2014/08/03/guadec-2014/feed/2mmohrhardProperty mapping in chartshttps://mmohrhard.wordpress.com/2014/05/29/property-mapping-in-charts/
https://mmohrhard.wordpress.com/2014/05/29/property-mapping-in-charts/#commentsThu, 29 May 2014 21:30:18 +0000http://mmohrhard.wordpress.com/?p=79Continue reading →]]>The release of the next LibreOffice version is not that far away with a lot of cool new features. Additionally to the many nice features already mentioned on our Release Notes page I want to talk a bit about one of the new chart features that will be part of the 4.3 release.

What is property mapping and how to use it in a chart?

Property mapping is a way to map a property of a chart series, for now fill color and line color, onto a data range in a spreadsheet. Based on the value in the spreadsheet the property value is changed.

If this sounds familiar you are correct. Inside spreadsheets you have a similar feature called conditional formatting that allows formatting of a cell based on a spreadsheet value. Until now all the chart formatting was either fully automated based on default values in the LibreOffice code or hard formatting. The new “conditional formatting” for charts allows us to dynamically adapt the chart formatting based on the data in our spreadsheet.

A simple use case for this feature is to highlight special values in your chart. In older versions you would need to modify the formatting of the chart each time your data changed. With this new feature you just have an additional column where you calculate the color automatically based on the value of the point. In the screenshot below data series “col2″ has a property mapping that formats the bar red if the value is larger than 3, otherwise green.

How do you add a property mapping to a chart?

Adding a property mapping is quite simple. In the chart wizard or in the data ranges dialog select the data series and add a property mapping based on the list shown after clicking on the “Add property mapping” button (The available mappings depend on the chart type). In the next step set the range property for the mapping as shown in the screenshot.

The feature is already working quite nicely in current daily builds however I’m aware of some open items that need improvement. The UX team asked for a few changes to the dialog and in my opinion there needs to be a way to prevent that empty cells are treated as 0 (black). I think it might be a better idea to use the series color in case we find an empty cell.

Additionally the concept is still a bit user unfriendly. The mapping is based on implementation defined property values and calculating the correct RGBA value needs some experience. A small step into a more user friendly handling is the addition of the COLOR spreadsheet function that takes 3 (RGB) or 4 (RGBA) parameters and returns the correct value.

Testing in a daily build is highly appreciated. Additionally I’m still looking for ways to extend property mapping to non-color properties but I’m missing a good concept. If you have an idea for a good mapping between values and properties please drop me a note.

]]>https://mmohrhard.wordpress.com/2014/05/29/property-mapping-in-charts/feed/1mmohrhardcolor-mappingadd-property-mappingUpdate about our import/export crash testinghttps://mmohrhard.wordpress.com/2014/03/24/update-about-our-importexport-crash-testing/
https://mmohrhard.wordpress.com/2014/03/24/update-about-our-importexport-crash-testing/#commentsMon, 24 Mar 2014 19:03:07 +0000http://mmohrhard.wordpress.com/?p=75Continue reading →]]>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.

]]>https://mmohrhard.wordpress.com/2014/03/24/update-about-our-importexport-crash-testing/feed/0mmohrhardOOXML strict support in Libreofficehttps://mmohrhard.wordpress.com/2014/03/18/ooxml-strict-support-in-libreoffice/
https://mmohrhard.wordpress.com/2014/03/18/ooxml-strict-support-in-libreoffice/#commentsTue, 18 Mar 2014 19:41:14 +0000http://mmohrhard.wordpress.com/?p=72Continue reading →]]>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.

]]>https://mmohrhard.wordpress.com/2014/03/18/ooxml-strict-support-in-libreoffice/feed/9mmohrhardCppunit 1.13.2 releasedhttps://mmohrhard.wordpress.com/2013/11/12/cppunit-1-13-2-released/
https://mmohrhard.wordpress.com/2013/11/12/cppunit-1-13-2-released/#commentsTue, 12 Nov 2013 00:10:32 +0000http://mmohrhard.wordpress.com/?p=70Continue reading →]]>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.

]]>https://mmohrhard.wordpress.com/2013/11/12/cppunit-1-13-2-released/feed/7mmohrhardAutomated import crash testing in Libreofficehttps://mmohrhard.wordpress.com/2013/04/19/automated-import-crash-testing-in-libreoffice/
https://mmohrhard.wordpress.com/2013/04/19/automated-import-crash-testing-in-libreoffice/#commentsFri, 19 Apr 2013 05:38:26 +0000http://mmohrhard.wordpress.com/?p=64Continue reading →]]>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 2.23.52.0.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.

]]>https://mmohrhard.wordpress.com/2013/04/19/automated-import-crash-testing-in-libreoffice/feed/20mmohrhardWhy I contribute my changes to Libreoffice and won’t re-license them to a non-copyleft license?https://mmohrhard.wordpress.com/2013/01/30/why-i-contribute-my-changes-to-libreoffice-and-wont-relicense-them-to-a-non-copyleft-license/
https://mmohrhard.wordpress.com/2013/01/30/why-i-contribute-my-changes-to-libreoffice-and-wont-relicense-them-to-a-non-copyleft-license/#commentsWed, 30 Jan 2013 02:38:47 +0000http://mmohrhard.wordpress.com/?p=51Continue reading →]]>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.

Of course the main reason for contributing to Libreoffice is our amazing community. I started about 2 years ago working on Libreoffice when the project was still very young and Oracle required a copyright assignment. However in the Libreoffice community I was immediately welcome and got amazing help, encouragement and found great new friends. It is this community that I want to support and not another project that is spreading rumors and tries to undermine our community.

No company is dominating the development process
Another major point is that I don’t trust the big company in the background of the other project asking for the re-licensing. In my opinion it just feels wrong if a single company is more or less dominating the development of an open source project without even revealing its plans or making clear which of the members are actually being paid for their work on the project. At TDF we have rules that limit the influence of a single company in the Board of Directors and the Engineering Steering Committee. We keep track of the employer and even for single developers these information are kept in our wiki. Our regular commit stats show that not a single company is dominating the development. This independence from a single company and the transparency are one of the great achievements of TDF and I don’t plan to support a project that is not following similar rules.

TDF as organization
In my last point I already indirectly mentioned another feature of the Libreoffice community. The Document Foundation, as meritocratic foundation, provides a stable environment around the Libreoffice community. Through the foundation we can concentrate on our main task: Making the best office suite. Compared to other office suites that are part of larger foundations TDF’s main goal is providing support to the Libreoffice community and therefore neither the development community nor any other part of the project has to adapt to an external set of rules. Additionally all legal entities of TDF (Board of Directors and Membership Committee) are elected by a STV election from all members.

Amazing framework for developers
So lets finally come to some development related topics. The Libreoffice project provides an incredible framework of tools for developers. I’ll try to list the most important ones with links but I will surely miss some of our cool toys. So lets begin with one of the most important tools, git as version control system, allowing our high commit volume with more than 1500 commits per month to the main development branch ( that does not include commits to the stable branch ). Additionaly we have now gerrit which allows easy review of patches and makes it as easy as possible for new developers so commit their first patch. Tinderboxes building Libreoffice automatically several times a day and automatically notifying all committers who are possibly guilty of breaking the build (While writing this blog post 12 machines are building the master branch with different settings on several platforms: Linux (with clang and gcc), Mac, Windows, Android, iOS). Let’s not forget being able to crosscompile from Linux to Windows. This allows quickly to build for the Windows platform without needing to set-up a new virtual machine or worry about our difficult build process on Windows. In the last 2+ years of the project we have cleaned the code from ancient container structure and old string classes, introduced cleaner string handling, transformed nearly our whole build system to gbuild and have done many more clean-ups that are invisible to the user. These improvements are not directly visible but will allow us in the future to focus on the difficult problems instead of worrying about technical debt. Other great tools that developers use every day are automatic bugzilla notifications for bug fixes, static source code analysis reports, a compiler plugin for refactoring, gdb pretty printers, a large set of automatic tests with test coverage reports and much more. I’m sorry for every missing tool in my list. And last but not least one of the coolest things we have are our easy hacks. They allow new contributors to start with a small task and an assigned mentor and are a great way to help new developers getting started.

So I believe that supporting the Libreoffice project is a good way to support the FOSS community. However I will not agree with people suggesting that re-licensing your commits for another project is a good idea. The Libreoffice project has chosen a free and open source license and anybody implying that refusing to re-license commits is against the FOSS ideas or trying to force developers to re-license by threatening that the changes will be otherwise rewritten disqualifies for any further discussions. In my opinion similar tactics are used by some of our closed-source competition and I feel ashamed that I know about a project using these in the open source world. Respecting the license of a project is a key part of open source development.

Finally I’d like to thank all members of the community who make working on Libreoffice so much fun.

]]>https://mmohrhard.wordpress.com/2013/01/30/why-i-contribute-my-changes-to-libreoffice-and-wont-relicense-them-to-a-non-copyleft-license/feed/4mmohrhardCppunit 1.13.1 Libreoffice version releasedhttps://mmohrhard.wordpress.com/2012/09/25/cppunit-1-13-1-libreoffice-version-released/
https://mmohrhard.wordpress.com/2012/09/25/cppunit-1-13-1-libreoffice-version-released/#commentsTue, 25 Sep 2012 19:38:09 +0000http://mmohrhard.wordpress.com/?p=34Continue reading →]]>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.