shameless self-promoting website
»Rejourn root
»LibreOffice Community Blogs
  • Tuesday, 13 September 2016
    Using clang-based tools beyond loplugin LOCon lightning talk (Comments)

    The last week I gave a Using clang-based tools beyond loplugin lightning talk at LibreOffice conference 2016, on the last day. Click on the image to see all the slides.

    If you’re a vim or emacs user and you work with C++11 code, you probably want to have a look at clang-rename, include-fixer and some editor plugin exposing the power of libclang (like YouCompleteMe or libclang-vim), sometimes these are really helpful.

  • Monday, 12 September 2016
    A year in LibreOffice's RTF support LOCon talk (Comments)

    Last week I gave a year in LibreOffice’s RTF support talk at LibreOffice conference 2016, in the development track. Click on the image to see all the slides.

    I’ve also published a number of (mostly) sightseeing pictures based on wondering around in Brno before and after the conference.

  • Friday, 09 September 2016
    Collaborative editing using LibreOfficeKit LOCon talk (Comments)

    Yesterday I gave a Collaborative editing using LibreOfficeKit talk at LibreOffice conference 2016, in the development track. There were many interested parties — not a surprise, as this is the power horse behind LibreOffice Online. :-)

  • Thursday, 08 September 2016
    Improved digital signature handling in LibreOffice LOCon talk (Comments)

    Earlier today I gave a Improved digital signature handling in LibreOffice talk at LibreOffice conference 2016, in the development track. The room was well-crowded — seems this year classification was a hot topic. ;-)

    Quite some pictures are now available on Twitter, don’t miss them.

  • Friday, 05 August 2016
    LibreOffice now bundles the latest libxmlsec version (Comments)

    I wrote about how LibreOffice uses the XMLSec Library in an earlier post from March. There are two long-term goals regarding xmlsec in LibreOffice:

    • bundle the latest xmlsec version, instead the one from 2009

    • upstream enough of the patches, so building & running against xmlsec as provided by a Linux distro also works

    I’m happy to say that the first goal is now reached:

    • libreoffice-5-1 bundled xmlsec 1.2.14 from 2009

    • libreoffice-5-2 bundles xmlsec 1.2.20 from 2014

    • master bundles the latest xmlsec 1.2.22, released earlier this year :-)

    This is good, as this way it’s easier to integrate xmlsec upstream improvements into LibreOffice in the future.

    Regarding the other goal, shrinking the patch list is still to be done. ;-)

  • Monday, 25 July 2016
    A LibreOffice / AddressSanitizer setup (Comments)

    sanitizers (ASAN, UBSAN, etc.) is a collection of tools to detect memory corruption bugs, undefined behavior and more by instrumenting the code generated by the compiler. (That’s the main difference from valgrind.) From LibreOffice’s perspective one more important difference is that there is a Jenkins_Linux_Ubsan tinderbox that makes sure that the master branch is kept clean from errors detected by a given configuration.

    So when the tinderbox failed after a commit of mine, I wanted to set up a similar environment locally, reproduce and fix the bug, and push the fix once I saw that the fix indeed solves the problem. You can set many options both at build and runtime, so while we have some documentation on the TDF wiki (and also Stephan was kind enough to share his config) on how to use these sanitizers, it wasn’t clear to me what to do step by step. So here is one possible setup that worked for me — in my case I wanted to reproduce a stack-use-after-return problem. If you haven’t ever built LibreOffice before, then go to the Development wiki page, first do a normal build, and if everything went fine, came back here.

    Build options

    My autogen.input looks like this:

    CC=clang -fsanitize=address
    CXX=clang++ -fsanitize=address

    Which is a normal clang debug build, except:

    • you need to add -fsanitize=... to CXX (not to CXXFLAGS), as explained on the wiki

    • you need to explicitly disable Firebird integration for now


    My first attempt failed at build time, as even the tools used only during the build are instrumented, and some memory leak was detected there, which means the build aborted before reaching the problem I was interested in. To disable leak detection during build, and disable parallelism (I needed this, as I did the build in the background while using the machine for something else):

    make build-nocheck ASAN_OPTIONS=detect_leaks=0 PARALLELISM=1

    This also means that I explicitly disabled running any tests, as I knew which is the single unit test I want to run for the purposes of reproducing and fixing the problem.


    Once the build completed, it turns out that the stack-use-after-return detection is disabled at runtime by default, which means I could not see any problem locally. Here is the commandline to run one specific CppunitTest with this detection on:

    cd sw; make -sr CppunitTest_sw_tiledrendering ASAN_OPTIONS=detect_leaks=0:detect_stack_use_after_return=1

    Again, this is just one possible setup, you can use other -fsanitize=... options, other environment variables during build and during testing — but hopefully it helps in the future to avoid pushing fixes for such problems detected by sanitizers just blindly.

  • Monday, 18 July 2016
    On LibreOffice's ViewContact/ViewObjectContact/ObjectContact (Comments)

    I’ve recently fixed a missing-repaint problem in LibreOffice’s headless backend, but the root cause wasn’t close to the symptom I saw first. Part of the debugging process was to understand what’s the relation between sdr::contact::ViewContact, sdr::contact::ViewObjectContact and sdr::contact::ObjectContact.

    See this old presentation and the review of my documentation update for the details, but the short version is that:

    • somewhat confusingly, sdr::contact::ViewContact is part of the model, and there is one sdr::contact::ViewContact object per shape

    • sdr::contact::ViewObjectContact is part of a view, and there is one sdr::contact::ViewObjectContact per shape, per view

    • finally sdr::contact::ObjectContact is part of a view, and there is one sdr::contact::ObjectContact per view

    So the answer to my original Is it normal that I have two object contacts and a single view contact for a shape and two views? question is: yes, that’s expected. ;-) Hopefully the updated documentation is now more clear, the incorrect 1:N relation in the original class diagram first confused me.

  • Monday, 27 June 2016
    RTF shape import: group scaling and flip in LibreOffice Writer (Comments)

    Some kind of simple logo was reported to be mis-imported in the RTF filter, it looked like this:


    which is interesting, but the reference output is different:


    With a bit of investigation, it turns out this was a flipped group shape with a few rectangles, so the mis-rendering of the logo was due to two independent problems. The first is that the child shapes inside a group shape were scaled incorrectly. See the commit for the exact details, after fixing scaling, it looked closer to the original:


    The second problem was that the group itself was flipped, and this was again ignored on import. After fixing that problem:


    the result is basically the same as the reference. Both fixes are not only on master (towards LibreOffice 5.3) but also backported to LibreOffice 5.2. :-)

  • Thursday, 02 June 2016
    Classification toolbar in LibreOffice: Multiple Categories (Comments)

    I explained the concept of the classification toolbar appearing in LibreOffice 5.2 in a previous post. One incremental update on top of that is support for multiple categories, which I’m describing here.

    TSCP in its BAILSv1 spec defines 3 different policy types (IntellectualProperty, NationalSecurity and ExportControl), and you can set different classification categories for different policy types. Giving a practical example, if you’re communicating with someone, then you can declare what policy type will you be using for that communication, and tag a single document multiple times, once for all used policy types.

    This multiple-categories feature wasn’t supported by LibreOffice previously, we simply read the IntellectualProperty type from the document, and also only wrote that. Now the user interface still reacts to the IntellectualProperty policy type (since in case there are multiple policies and each of them wants a different e.g. watermark, the UI has to pick one in some way), but other than that we read all types from the document, all values are shown on the toolbar and of course you can also set all of them.

    All internal APIs and the .uno command that can be used from macros take a type parameter to get/set a given type of category, if wanted. As usual, you can try this right now with a 5.2 or 5.3 daily build. :-)

  • Wednesday, 18 May 2016
    Recent undo/redo fixes in LibreOffice Impress (Comments)

    I’ve recently spent some time fixing a few bugs around undo/redo in Impress, in the area of table shapes. I’m mentioning these here as they’re all bugfixes, so they are backported to LibreOffice 5.1, and no major release notes will point them out. So if you are using Impress table shapes and you consider their usability suboptimal, then read on, I have some great news. :-)

    The first problem is tdf#99396, where there were actually two problems:

    1. Vertical alignment is a cell property, but when setting that property, the undo code was simply missing.

    2. When editing cell text (the user is inside "text edit") the undo stack is in a special mode — and ending text edit made the cell property undo items go away. This wasn’t a problem for vertical alignment only, it was a problem for example when the background color of the cell was changed, too. These cell property changes are now added to the undo stack after finishing text edit, so you can still undo them later.

    The second bugreport is tdf#99452 where resizing a table shape row separator and then undoing the resize didn’t restore the original state. See the commit for all the details, but the bottom line is: it isn’t a good idea to automatically re-layout the table when we’ve already resized the shape as part of undo, but the table rows were not yet resized to reflect their original sizes.

    As usual, you can try this right now with a 5.2 daily build. :-) (Or even with an 5.1 one, actually.)

more »