The Document Foundation Planet


October 25, 2016

Official TDF Blog

Presenting our Telegram channels

telegram_logo_smallFollowing the success of the LibreOffice Conference Telegram channel, we have asked our community – through an informal poll on the Telegram channel itself – if they wanted to keep the channel alive and change the name to LibreOffice Community. The feedback has been overwhelming, as 21 out of the 22 answers have been positive.

We have therefore changed the name of the Telegram channel to LibreOffice Community, and made the channel public to allow everyone to subscribe. The link is the following: To widen the reach, the channel is bridged to the #libreoffice-telegram IRC channel on Freenode. Please be aware that the objective of this channel is to share information and experiences amongst community members, and not to support end users.

End user support, as well as other strategic activities for the project, will continue to be managed through the current channels. For end user support, the different options available are listed here:

In addition to the discussion channel, we have also opened two Telegram broadcast channels, which will be used to increase the reach of our announcements: (1) The Document Foundation (, and (2) LibreOffice ( These channels will be used to broadcast announcements, and therefore will have a very low traffic.

Before launching the Telegram channels, we have had several discussions about the opportunity of extending the project reach through social media, with different opinions on the subject. Thus, we have created a very short survey (just one question), to get the opinion of community members.

<script type="text/javascript"><!]]></script> <noscript>Take Our Survey!</noscript>

by Italo Vignoli at October 25, 2016 08:25 AM

October 24, 2016

Official TDF Blog

Community Weeks: Design – meet the team

LibreOffice Community Weeks

We now come to our final Community Week for October 2016, and this time we’re talking to the Design team. Design is an essential aspect of LibreOffice development, and it’s sometimes tough to find the right balance: some users want the interface to change rapidly with each release, whereas others are more conservative and prefer an incremental approach. When new features are added to LibreOffice, they must be made accessible and easy to find, but not interfere with the workflow of experienced users.

The Document Foundation, the non-profit entity behind LibreOffice, has a dedicated user experience mentor: Heiko Tietze. He works with the Design team to research and implement user interface improvements, trying to take into account the needs and wishes of as many users as possible. We caught up with Heiko to see what he’s working on at the moment…


Heiko Tietze LibreOffice developer

What is your role in the Design team?

I’m the user experience (UX) mentor and my role is to support and facilitate work on the user interface (UI) of LibreOffice – how it looks and behaves. This includes giving my advice on Bugzilla tickets with the needsUXEval keyword, conducting surveys and quick polls, working on and publishing proposals on the design blog, managing weekly design meetings, defining human interface guidelines (HIG), creating prototypes, etc. In general, my task is to get more people involved.


How did you first get involved with LibreOffice?

In the 1990s I studied psychology with a focus on methodology and statistics. Scientific experiments typically end up with a mass of data, so getting familiar with programming is a big plus – which brought me towards usability. Some years ago I volunteered with a couple of tests about the icons used in LibreOffice.

Later on this moved forward to more advanced studies on how users deal with the product and what they expect (find all blog posts here). And finally The Document Foundation made a tender last year for a freelancer for UX and design work, and I was picked for it.


What does your typical workday look like?

Usability is about users, so basically I observe, talk, interview, watch videos, and read comments to get an impression of what our users need. My day starts with reading emails – typically a lot come in from the ux-advice mailing list. Commenting can often take some time when a ticket is not clear in respect to the workflow.

When working on a new UI design I start by researching the issue and collecting all the requirements first, and then I scribble mockups that follow our principles of simplicity, consistency, and ease of use. While this might sound straightforward, it isn’t always so. Usability is an iterative process where everything needs to be discussed and improved repeatedly. If you want to learn more about the work of the design team read “How we work” on the wiki.


What areas in Design are working well, and what needs to be improved?

Regarding the team, we are doing pretty well in my opinion. There is always room for improvement and we need to be faster with decisions on UX-related tickets. But that’s how open source works, slowly. And regarding the application, I believe we need to improve on simplicity and clear concepts. There are numerous functions for special workflows that hinder beginners. And on the other hand we have a lot of hidden gems that even experts never use.


Who else is involved and what do they do?

The design team has many contributors who are experts from different areas including members of the development team. Some spend a lot of their spare time committing patches for menus or UI files, while others work on small aspects such as visual design or icons. Find a list of members see this wiki page.


How can regular (non-developer) LibreOffice users help out?

Everyone is an artist, and everyone is a user. The simplest way to contribute to LibreOffice is to file bugs and submit enhancement requests to our bug tracker. For those who want to do more, we have tasks for the very beginner (eg assign nice names to colors, create custom shapes), for experienced UX/UI designers (eg revamp the bibliography dialog), and for advanced developers (typically Google Summer of Code students). On our wiki we list the topics so everyone can get an impression about the demands: click here for all the details.

Finally, we’re currently running a survey asking users how LibreOffice should handle missing fonts. It would be great if LibreOffice users could read the survey and choose whether they like the change or not in the form at the bottom.


Thanks Heiko. Coming up later in the week, we’ll explore in further detail what the Design team does, and show you some more ways to get involved.

by Mike Saunders at October 24, 2016 01:02 PM

October 21, 2016

LibreOffice Design Blog

Dealing with Missing Fonts

When documents are sent from one computer to the next or opened on the same computer in a different operating system, these documents may not look the same unless all the fonts used in the document are available on the …

by The LibreOffice Design Team at October 21, 2016 08:13 PM

Caolán McNamara

Office Binary Document RC4 CryptoAPI Encryption

In LibreOffice we've long supported Microsoft Office's "Office Binary Document RC4 Encryption" for decrypting xls, doc and ppt. But somewhere along the line the Microsoft Office encryption scheme was replaced by a new one, "Office Binary Document RC4 CryptoAPI Encryption", which we didn't support. This is what the error dialog of...

"The encryption method used in this document is not supported. Only Microsoft Office 97/2000 compatible password encryption is supported."

...from LibreOffice is telling you when you open, for example, an encrypted xls saved by a contemporary Microsoft Excel version.

I got the newer scheme working this morning for xls, so from LibreOffice 5-3 onwards (I may backport to upstream 5-2 and Fedora 5-1) these variants can be successfully decrypted and viewed in LibreOffice.

by Caolán McNamara ( at October 21, 2016 10:35 AM

October 20, 2016

Andreas Mantke

Freie Software und Nachhaltigkeit

Seit einigen Jahren besitze ich eine GPS-Uhr für das Lauftraining und Trecking. Diese Uhr kann mittels eines USB-Kabels ausgelesen werden. Hierfür wurde mit der Uhr eine Software mitgeliefert, die auf Windows XP usw. gestartet werden konnte. Unter der aktuellen Version von Windows ist die Software nicht mehr lauffähig.

Ich bin deshalb und weil ich es lästig fand, nur zum Auslesen der GPS-Uhr ein anderes Betriebssystem zu starten, auf die Suche nach einer passenden freien Software gegangen, die auch auf dem Betriebssystem Linux lauffähig ist. Nach kurzer Suche habe ich ein freies Software Projekt auf der Plattform gefunden:

Dank der unter Linux verfügbaren freien Werkzeuge zum Kompilieren von Quellcode konnte ich ein lauffähiges Programm erstellen und auf meinem Linux-Rechner installieren. Nach dem Anschluss der GPS-Uhr an den USB-Port des Rechners konnte ich als Superuser („su“) mit dem Kommando „/usr/local/bin/crane_gps_watch_client“ auf die Daten der Uhr zugreifen und auf dem Rechner lokal ablegen. Mit der Option –split wurden die einzelnen GPS-Trainings-/Trecking-Tracks gesondert heruntergeladen und als einzelne Dateien abgespeichert.

Diese einzelnen Tracks konnte ich später in das Programm „MyTourBook“ einlesen und mir die einzelnen Trainings/Touren mit Ihren Daten und in einer Landkarte anzeigen lassen. Auch dieses Programm ist freie Software.

Dank freier Software gehört meine GPS-Uhr folglich nicht zum „alten Eisen“. Ich kann sie weiter wie bisher verwenden. Da die freien Software-Programme auch unter Linux lauffähig sind, brauche ich kein Windows-Betriebssystem mehr, um die Daten von der GPS-Uhr zu laden und zu verwalten. Freie Software hat damit für mich wieder einen Beitrag zur Nachhaltigkeit geleistet.

by andreasma at October 20, 2016 07:42 PM

Tamas Zolnai

Improve pivot table import performance (tdf#102694)

After a short break I got back to Collabora and I continue working on LibreOffice. This time I handled a performance issue in pivot table's import code, as part of our work for SUSE. In some cases importing an XLSX document containing more pivot tables took such a long time, that user could interpret it as a freeze.

After some testing we found that pivot table grouping is one of the points which makes import slow. We means me and Kohei Yoshida, who is an expert in this area of the code and helped me with understanding it. So grouping was in our focus this time.

Pivot table groups

In case of pivot tables we can make groups for columns of the source data. This groups can be name groups (general groups), number groups (e.g. number ranges) and date groups (e.g. grouped by year, month, day, etc.). Since this groups are related to the source, they rather part of the source than the pivot table layout. This is true both for MS Excel and LO Calc implementation. Effectively this means that when we have more pivot tables using the same source they will have the same groups too. In case of LO Calc this groups are stored in the pivot cache linked with the corresponding source range.


The performance issue here was that however these kind of pivot tables (having the same source) were linked to each other by the pivot cache, XLSX import ignored that and worked expecting pivot tables are fully independent. Which means that same groups were imported so many times as many tables referenced them. What makes it even slower, this kind of tables are linked to each other on a way that when one table's grouping is changed other tables are also affected.

This difference between internal handling of pivot tables an the XLSX import code came from that XLSX import code was written before groups became part of the pivot cache. So I actually needed to update the import code to follow the changes of pivot table internal implementation. With that, pivot table groups' import time became quite good. For example the test document I uploaded to bugzilla (tdf#102694) took more than 20 minutes before and now it takes less than a half of a minute. This document contains a small data table and 20 simple pivot tables. So it's not something which should take so much time to load and now it doesn't.

by Zolnai Tamás ( at October 20, 2016 06:03 PM

Michael Meeks

2016-10-20 Thursday.

  • Mail chew, encouraged to see Seafile 6.0 released with Collabora Online integration expanding the list of our partners with shipping integrations.

October 20, 2016 12:34 PM

Official TDF Blog

Community Week: QA – get involved

LibreOffice Community Weeks

Earlier this week we talked to LibreOffice’s quality assurance (QA) engineer, Xisco Fauli, about how the QA team works, what they’re involved with at the moment, and where they need help. Let’s now look at how regular LibreOffice users can get involved: even if you can only spare a little bit of time each week, you can really make a difference to strengthen and improve the software.

LibreOffice’s QA team is comprised largely of volunteers. The team works through bug reports submitted by LibreOffice users, checking them for accuracy, reproducing them (where possible), and assigning them to the appropriate developers or projects.


Reporting bugs

Bugzilla is used for tracking bugs, and it’s a very versatile tool that may look a bit daunting initially. But once you’ve submitted a couple of bug reports it becomes easier to work with. To submit a bug report, you need to be logged in there – so click “New Account” at the top to set up an account.

Now, let’s say you’ve found a bug in LibreOffice and want to report it. The process goes as follows:

  1. Click New at the top of Bugzilla, choose LibreOffice, and you’ll end up on this page
  2. Many bugs have been reported multiple times already, so scan through the list to check your issue isn’t already being dealt with
  3. Also, try typing some keywords associated with your bug (eg “docx import” or “PDF crash” in the box under the list, and click “Find Similar Issues” to check if someone else has submitted the bug already
  4. Otherwise, click “My issue is not listed” and fill in the form
  5. Provide as much information as possible: the component of LibreOffice affected (eg Calc), what hardware you’re using, and LibreOffice version
  6. Provide a short summary and detailed description with as much useful information as possible
  7. Add steps to reproduce, the results you get, and what you expected
  8. For the “severity” part, only choose a high ranking if it’s extremely serious (like, it can cause major data loss

Once your bug has been submitted, a member of the QA team will check it and ask for more information if required. Also see this page for more information on submitting good bug reports.


Confirming and triaging

But what happens if you bug has already been reported? It still helps the QA team if you confirm it as well, especially if you’re using a different operating system or version of LibreOffice. In that way, the QA team can narrow down the cause more quickly. So it’s worth taking the time to confirm even if a bug report from someone else already looks detailed enough.

If you’d like to get more involved in the QA team, maybe to build up experience for a future career in QA, you can help by triaging bugs. This is the process of confirming and prioritising bugs so that developers know what to work on. As it’s a large and complex piece of software used by tens of millions of people, LibreOffice receives many bug reports, so it’s important that they are organised correctly.

Then there are Easy Hacks you can help with, which help the QA processes and team. These vary from improving the QA infrastructure to more creative topics like making a video to assist newcomers. Have a look at the page – something is bound to take your interest!


Join the Bug Hunting Session

On Friday October 21, from 08:00 UTC to 22:UTC, a big testing effort to fix bugs in the upcoming LibreOffice 5.3.0 release will take place. There are many new features in this next version of LibreOffice, so your assistance in making it rock-solid is very much appreciated. Here’s how to get involved:

See the wiki for more information on the Bug Hunting Session – and thanks in advance for any help you give. Millions of LibreOffice users around the world will benefit from your efforts, and free and open source software on the desktop will keep getting stronger!

by Mike Saunders at October 20, 2016 12:10 PM

October 19, 2016

Michael Meeks

2016-10-19 Wednesday.

  • Mail chew, poked at some bugs; fixed LOK scheduler locking issue found by yesterday's checks. Lunch; call with Tomaz. Plugged at actions; out to visit Colin at West Suffolk Hospital: some encouraging progress. Worked late.

October 19, 2016 09:00 PM

October 18, 2016

Michael Meeks

2016-10-18 Tuesday.

  • OSCON booth-ness; commercial team call; wrote up minutes. Caught up with various people, lunch, demo'd LibreOffice to people. Off early, train home - knocked up scheduler locking assertions on the train. Tea, read stories, collected M. from cubs; hacked while J. had her Cruse counselling supervision.

October 18, 2016 09:00 PM

Official TDF Blog

Community Week: QA – meet the team

LibreOffice Community Weeks

Having covered development and documentation, we’re now into our third LibreOffice Community Week: Quality Assurance (or just “QA” for short). QA is an essential element of the LibreOffice development process, and affects the suite in many ways. For the benefit of end users, QA helps to identify and fix bugs – whether they’re glitches in the behaviour of the office suite, or problems that arise when importing certain files, or just issues with the user interface.

But QA is an integral part of new feature development as well. When a LibreOffice developer adds something new to the office suite, QA processes ensure that it doesn’t impact other features, and that the rest of the software continues to be stable and robust.

LibreOffice has an active QA community that works on tracking, reproducing and fixing bugs, and The Document Foundation (the non-profit entity that backs LibreOffice development) recently hired a dedicated QA engineer, Xisco Fauli. We caught up with him to see how the QA process works and how newcomers can help out.


Xisco Fauli LibreOffice developer

What is your role in the QA team?

My role is to act as a middle-man between the QA community and other teams, such as participating in the Engineering Steering Committee (ESC) meetings for instance.

I’m also in charge of organizing the QA meetings, which take place every other Tuesday, and organizing the bug hunting sessions, the next one being on Friday October 21 for LibreOffice 5.3 Alpha. I also spend time maintaining Bugzilla, our bug-tracking tool, updating the wiki, helping other users on IRC, and triaging and reporting bugs. Lately I’ve been working on collecting stats from Bugzilla so that they’ll help us to analyze the status of bugs and users in the platform.


How did you get involved?

I started working for The Document Foundation just one and a half months ago, in the beginning of September, so I’m a newbie here. However, I had already contributed to the LibreOffice project in the past, mostly doing bibisections in QA or working on Easy Hacks and small fixes in development. Besides, I participated in the Google Summer of Code in 2011, converting some Java wizards to Python.


What does your typical workday look like?

So far I think no two days have been alike for me, so I’ll try to summarize it as much as possible! Normally, the first thing I do when I get connected is check the email and the IRC history. Then I take a look at the new changes in Bugzilla (new unconfirmed bugs, new bibisectRequest bugs, etc.) and eventually I work on the main task I have planned for the day. In case I have a meeting, I also spend some time getting things ready beforehand.


What areas in QA are working well, and what needs to be improved?

Definitely the best part of QA is the volunteers themselves, who expend their own time on the project, keeping the unconfirmed bugs low, triaging bugs, providing backtraces, etc. as this would be impossible without them.

I also find tools like the bibisect repositories really great for triaging regressions. On the other hand, as the amount of bugs in Bugzilla is quite high, I believe we need to improve how duplicated bugs can be identified more easily, as well as finding ways of attracting new volunteers to the team and encouraging them to stay in the project.


How can normal (non-developer) LibreOffice users help out?

One of the best ways a normal day-to-day Libreoffice user can help out is by reporting clear and detailed bugs when they find a problem, making the chances of getting the bug triaged, and subsequently fixed, much higher. A good bug report must have:

  • Operating system and LibreOffice version
  • Enumerated reproducible steps
  • Simple attachments where appropriate
  • Observed or expected results

Besides, they can also help to confirm bugs or retest bugs that might be fixed.

Finally, participating in the next Bug Hunting Session on Friday October 21 is a good way to start helping out. Newcomers can contact us on IRC (#libreoffice-qa on Freenode) or via the mailing list if they have any questions.


Thanks Xisco. So, that’s an overview of the QA team and what it does – later this week we’ll show you exactly how to get involved, confirm a bug report, and help to make LibreOffice stronger and more robust for everyone.

by Mike Saunders at October 18, 2016 12:11 PM

October 17, 2016

Michael Meeks

2016-10-17 Monday.

  • Early to rise; train to London, Edgware Road. Met Giovanni, and helped at the OSCON LibreOffice booth with him. Good to catch up with Karen & the SFC guys, a number of interesting people around to talk with. Out to the JS Foundation launch event in the evening.

October 17, 2016 09:00 PM

October 16, 2016

Michael Meeks

2016-10-16 Sunday.

  • Off to Church, ran older kids group went well; home for roast pork lunch. Slugged a bit, disassembled lego mindstorms robot and started re-assembling it. Read Adrian Plass to kids variously; put them to bed. Gordon sermon on 2 Samuel.

October 16, 2016 09:00 PM

October 14, 2016

Official TDF Blog

Community Week: Development – get involved

LibreOffice Community Weeks

On Monday we had a chat with LibreOffice’s dedicated mentor for new developers, Jan Iversen, and on Wednesday we then looked at some statistics from the development team and the tools they use. Today we finish off this Community Week by showing you how to get involved. Put your coding gloves on and get ready to become a LibreOffice hacker…


Getting the source code

The first thing you need to do is read this page – this is a step-by-step guide, from the primary contact until you have successfully gotten your first patch merged.

The page describes how to download the source code:

  • Git: at the command line, enter “git clone git://”

This download takes a while, but with that you have access to not only master (the bleeding edge source code), but also are release candidates (e.g. 5.1.6 RC1) as well as old versions. In total this is the source code with history.

Building LibreOffice is a task that takes quite a while, because the suite has approximately 7 million lines of code. The time needed depends a lot on your setup and the operating system. Windows is the slowest, and it is common to see the first build to take 6-10 hours. Linux and macOS are pretty fast: the normal time is 1-2 hours. Remember that the second build is a lot faster because it only builds changes.


Building it

How you build the code depends on your operating system, but our wiki has some guides:

If you have a choice of operating systems at your disposal, we recommend using Linux, where it’s very easy to install development tools and other related software.

Oh, and want to see what a LibreOffice build process looks like? Check out this speeded-up video (maybe turn down your audio before playing it though – the music is a bit loud!)


Start communicating

Once you’re able to build LibreOffice from its source code, it’s a good idea to reach out to other developers – maybe to get help, or ask for pointers, or simply see what things need working on. You can subscribe to the mailing list (see the archives here), but for more immediate contact join the #libreoffice-dev IRC channel on Freenode.

The mailing list and IRC channel can be busy, so there’s not a lot of time for off-topic discussion, but it’s worth introducing yourself quickly (who you are, why you want to help, any specific things you want to work on). If you want to talk to Jan, the new developer mentor, you’ll find him as @janIV on the IRC channel. Or send an email to


Start hacking!

We’ve mentioned “Easy Hacks” a few times this week – now we’ll explore them in detail. Easy Hacks are small tasks designed to be ideal starting points for new LibreOffice developers, so you can take them on without needing a lot of experience with the project or source code.

The first thing to do is read the quick introduction on this page – it explains the workflow and shows you how to use Bugzilla, which is used to coordinate Easy Hacks. From there, you can choose the language or technology area in which you want to help, eg:

For a full list of Easy Hacks in different languages, see this page, and once you’ve completed a few, you may want to move on to Core Hacks.

So good luck on your coding adventure, we look forward to your contributions, and just let us know on IRC or the mailing list if you have any questions!

by Mike Saunders at October 14, 2016 10:16 AM

October 12, 2016

Cor Nouws

Dutch parliament votes to make open standards mandatory

It has been a bit quiet. On this blog. And apparently also at the Dutch government with regard open standards. If that would be the case at all, then now there is some very good news. In the attendance discussing the "Actieplan Open Overheid" ("Plan for action on open government") the parliament adopted a resolution to make the use of open standards mandatory. Mandatory for the countries government and the regional/local administrations. By law. This, finally, will put an end to the halfheartedly policy in this area. An excellent example is easy to spot at the parliament's website: the resolution is published in an old proprietary format..

In any case: excellent news. And thanks to MP Astrid Oosenbrug for her competent and tireless work for a saner approach for the countries ICT. And of course to all other MP's that understand the importance of this.
The resolution also asks the government to improve sharing the knowledge they have on open source software. Very useful, since there is a lot of knowledge in this area at the various services/offices. My compliments!

by Cor & OfficeBuzz ( at October 12, 2016 11:03 AM

October 10, 2016

Miklos Vajna

Insert PDF as image in LibreOffice 5.3


LibreOffice 5.3 will add one more vector-based format that can be inserted as an image into documents: PDF. First, thanks to PMG who made this work possible. On the user interface you can now select PDF files when you choose e.g. Writer’s Insert → Image option:

The first page of the PDF document will be shown, which is handy if the PDF file is basically used as a vector image format.

Similarly to the SVG feature, the original vector image is stored in the document, but when saving to ODF, a replacement PNG file is also generated to be backwards compatible with older ODF readers. The image context menu → Save menu item allows to extract your original PDF data from the image, too:

And that’s it, as long as you save your document in ODF, your PDF-as-an-image will be kept without loosing any data. As usual, you can try this right now with a 5.3 daily build. :-)

However, if you’re interested in how this is implemented, keep reading…

Document model

The PDF image in the document model is really similar to how SVG is handled, next to Graphic::getSvgData(), there is now a Graphic::getPdfData(). This new member function exposes the original PDF data, otherwise the Graphic is just a metafile.


The ReplacementGraphicURL property of the image at an UNO level now exposes the generated metafile for PDF images. This is implemented for both Draw and Writer images, and is used by the ODF export filter.


When the Graphic instance is rendered, the layout knows nothing about the PDF data attached to the object, only parses the generated metafile. This way the display of the PDF image works out of the box.


First I’ve implemented a PDF import-as-graphic filter, then the export equivalent of it. As you can see, the PDF import-as-graphic filter isn’t too complicated, it completely reuses the existing "import PDF into Draw" filter, it simply copies the first page of the resulting document model as a metafile.

Second, once the graphic filters were working, I’ve also improved the ODF import to recognize PDF data — the export side needed no explicit work, once the ReplacementGraphicURL bits were in place.


As mentioned above, the Draw and the Writer image implementation is separate, so first I’ve added tests for ODT files in the testEmbeddedPdf of CppunitTest_sw_odfexport, and then SdExportTest::testEmbeddedPdf() to cover ODP files (and other ODF formats). Second, the PDF part of the graphic swapout/in code has a dedicated test in GraphicObjectTest::testPdf(), and the UI’s "Save original PDF" feature has a new XOutdevTest::testPdfGraphicExport() test.

Oh, and if you intent to test this manually in a self-created build, make sure to avoid --disable-pdfimport, otherwise this feature can’t work. ;-)

October 10, 2016 06:31 AM

October 09, 2016

Charles Schulz

An Emacs Update

It’s been a while I have not written about Emacs and more particularly my personal use case for Emacs. I started using Emacs because I was looking for a text editor capable of handling formats such as HTML and CSS; then I found out Emacs had quite convenient IRC clients and I could even use a bit of Org mode for project management. That was in 2013 and early 2014. As I was impressed by the seemingly infinite power of Emacs, I started using Org-mode more and more on a daily basis (something I still do today); and I started learning (e)lisp both in order to understand Emacs a bit more in-depth and because I wanted to start to learn a programming language.

Remember: I’m no software developer. When I’m not maintaining or creating websites for friends, I’m not doing much else in the way of “coding”. My Emacs usage remains however a daily experience that I would like to share here.

The first and basic idea that drives my usage of Emacs is both simple yet powerful. I’m certainly not the first one to come up with it: most of what we do as users of computers on a daily basis revolves around text edition and handling text. That’s an obvious concept when it is applied to software development or just plain text edition. But it is equally relevant when we consider email, IRC, file and folder management, Twitter and RSS feeds browsing; and it does still make sense with web browsing for instance.

Put simply and broadly, many things -if not most- that we accomplish on a computer can be seen as text editing. Once somebody shares this view deeply, that is on a personal basis and for its own personal case, it is possible to accomplish a lot of things with text editors such as Emacs. What this does practically mean in my case is that I use Emacs for a broad variety of usage on a daily basis:

Email: I am happy -and somewhat proud- to announce that I’m using mu4e (and emacs set of tools and clients for email) for most of my mail processing. I now rarely use Evolution, which is my only graphical email client besides K9 on Android. Mu4e caters to most of my needs when it comes to email. In fact it fits the bill almost perfectly, the only exception being that I sometimes need to tweak it a bit when receiving oddly formated emails sent from Outlook 2014 and upwards. My mails are stored both online and on my computer in the MailDir format. I fetch them and sync them between my computer and the servers using offlineimap; they are indexed and searchable using the powerful mu mail indexer; and there is no performance issue at all. If anything it is noticeably faster than graphical email clients, especially the search part. Emacs in general handles html emails surprisingly well, and besides the Outlook 14 hiccup I mentioned above, I have no trouble viewing decent html on my “buffer”.

Org-Mode: that one is a heavy hitter. I use Org-mode for what it does best: task management, planning, note taking and ideas organization. I use it sometimes to write blog posts, but where it would really be useful in that regard would be with a blogging engine supporting org files and / or markdown.

Blogging and text editing: I write my posts using either org-mode or markdown. But the real trick is to have an effective workflow between Emacs and the blog engine. Unfortunately WordPress is not so good at that which makes me think about a few options for the future.

IRC: I don’t use IRC on a daily basis, but I have grown frustrated for years with IRC clients. No names here, but I find most of them complex and annoying. At least with ERC, I have an unobstrusive experience which got me on IRC more frequently, and not just to communicate within the confines of the LibreOffice community.

File and document management: Using Dired, a well known Emacs set of tools, file management is increasingly a good reason for me to use Emacs.

Terminal using eshell: I’m not fiddling on the command line all day long, but using Arch Linux on my systems means that you will fire your terminal at least one every two or three days in order to keep the system updated.

Files editor: That is as close to coding as I get to this day. I have to maintain a few websites for friends and sometimes it means dabbling into the CSS, PHP scripts or Javascript files. Of course, Emacs excels at that, for instance with web-mode (but there are other utilities and modes available).

Documentation: Emacs comes with a lot of tutorials and manuals for many of its main utilities, and of course to learn (e)Lisp. It is possible and even very convenient to browse this documentation stack within Emacs.

What I use less for various reasons:

Internet browsing: Emacs is getting better at that but let’s face it, unless I’m browsing documentation or text-rich web pages online, I get a rather limited use for a text only browser.

Twitter mode: I would LOVE to edit and browse Twitter through Emacs. But the twitter mode is simply counterintuitive and slow. I’m a taker of any suggestion for any other Twitter utility running on Emacs out there.

RSS feeds browsing: Here again, I think we’re missing a good package. Emacs ships with a native RSS feed reader, but it is frankly a bit horrible. Another tool, elfeed, has a much richer functionnality but either because of lack of time or because of a bad configuration I just don’t find it convenient, even though it loads evertime on my own Emacs and is updated with my own feed. It is something to consider for the future.

I hope I have given some hope for people interested in using Emacs. I’m not a programmer, and if anything my specialities are literature, philosophy and History. As one can see however, Emacs is really useful for me and it should be for a lot of people as long as they’re willing to invest some time and enjoy learning new things and new ways to work and communicate.

by Charles at October 09, 2016 09:09 PM

October 08, 2016

Naruhiko Ogasawara

LibreOffice Conference 2016 Brno (or my hospital life in Czech)

Time is passing too fast.  Almost one month ago, LibreOffice community had an annual conference in Brno, Czech
Entrance. Welcome to LibreOffice Conference 2016 Brno!

Beautiful venue

Unfortunately, I had fever quite and strong pain in my left leg ("erysipel" according to my medical certificate) while the date, and I had stayed the hospital while the conference...
I had been the University Hospital Brno from 7th to 10th Oct.

The gate of hospital.  Thanks for everyone!

I'm so sorry you all LibreOffice friends worrying about me.  Now I'm (almost) fine.  My left leg is still swollen little bit, but no pain.  I live my life as usual :)

It was little sad that I missed most of interesting talks in the conference, I had to absent most of interesting events within the dates.  However, it was good opportunity to me that I could observe our community from different aspect.

I proud that I'm a part of the brilliant community.  All of you are awesome!  I can't express well with my English how I appreciate you.  Thanks to Czech local team, especially Tomas and Jiri, my doctor doctor and nurses did anything perfectly to cure me, although I couldn't understand any Czech language and my English is not fluent.

See you in Rome!

(And personally, I have to try Czech beer near future :)

Brno Central Station

by Naruhiko Ogasawara ( at October 08, 2016 07:21 AM

October 03, 2016

Markus Mohrhard

LibreOffice UI test tutorial (part 1): Adding a simple test.

After writing my last blog post about adding a simple Calc UI test I was thinking about the future direction of my documentation effort. As this documentation has to move to the TDF wiki at some point I was looking for a way to document every step in a cohesive way. After looking through the conditional format bugs I think I found one that allows me to write several independent documentation pieces building on each other.

As a result this is the first of four tutorials showing how to write an UI test for tdf#96453. The test will test the interaction of the “Manage Conditional Format” dialog with the “Add Conditional Format” dialog witha  focus on tdf#96453 and some related bugs that I found on the way.

The test document that we will use will have already 2 conditional formats defined. For the final test we want to open the “Manage Conditional Format” dialog, delete one entry and assert that we have only one entry in the table but still two in the document. After that we want to add a new entry through the “Add” button and the corresponding dialog, close that new dialog, assert that we have again two entries in the table and still only 2 entries in the document. Finally close the “Manage Conditional Format” dialog and assert that there are still exactly 2 conditional formats in the document.

Note that I picked one of the more complicated tasks and that it is normally less work to write a test. Also we are still at the early stages of the UI testing framework so we still have to add common code from time to time. As can be seen with the other LibreOffice test frameworks the more common code we add the easier it becomes to add new tests.

The different tutorials cover:

  1. Add test, load test file, open dialog, close dialog, close LibreOffice (basically a summary of the previous blog post)
  2. Add support for previously unsupported UI elements to the introspection library (C++)
  3. Add python code to assert document properties and a short summary of the directory structure
  4. Combine everything and make it work

Most of the time step 2 and to some degree step 3 should not be necessary for adding a new test. Over time more UI elements will be covered by the introspection library and more shared code for asserting properties on the document model will be available for reuse.

The Test

This is basically a short extension of the previous blog post. A detailed explanation of the code can be found there. The code for this tutorial can be found in the corresponding commit.

We don’t need to register the new file as we place it in the uitest/calc_tests directory which is registered inside of the calc_demo makefile. The actual test discovery happens through introspection by the test framework.

In contrast to the previous test we are going to load an existing document as that is much faster than creating a conditional format through the UI. Loading a document is already supported by the UITest class. Similar to creating a new document in the start center the method to load the document waits until the document is ready. So we can basically replace the UITest.create_doc_in_start_center method with the UITest.load_file method. This method expects as the argument the URL to the file so we generate the URL through a short helper methods. Better support for document URLs will be added to the UI testing framework in the future.

The conditional format manager is a modal dialog so we use UITest.execute_modal_dialog_through_command with the command ID “.uno:ConditionalFormatManagerDialog“. An easy way to find the correct command ID is to check the definition of the menu (for calc in the menubar file or the popupmenu directory) and find the correct entry.

As we are not yet planning to do any work we can just close the dialog again through the Cancel button and close the document. Both of these actions have been shown already in the older blog post.

Next blog post

We have not done any useful work in the test yet. The problem is that the table used in the “Manage Conditional Format” dialog is not well supported in the introspection library. So for the next tutorial we will improve this support and show how the introspection library is organized and how to add support for a previously unsupported elements.

by Markus Mohrhard at October 03, 2016 08:06 PM

Miklos Vajna

Small capitals toolbar button in LibreOffice Writer

It was requested to be able to set the small capitals character property via a toolbar button in Writer, which was indeed not possible. Not only the toolbar button wasn’t there, but the underlying UNO command was also missing (which you can use e.g. from a macro to format the current selection).

So my commit added a simple set of icons to the galaxy theme for the new toolbar button, defined the new UNO command for Writer text and added it to Writer’s text object bar, next to the upper case and lower case buttons (hidden by default). One difference from those buttons is that those buttons perform a transliteration, while this one really just sets a character property, you can easily undo the property later if needed.

Wrt. other icon themes, see this mail, hopefully the design team can help there.

As usual, you can try this right now with a 5.3 daily build. :-)

October 03, 2016 06:25 AM

October 01, 2016

Jan Iversen

Community building, spanish art

This Saturday I joined a local event. In the morning pressing grapes (see foto), and in the afternoon great food.

This is the  version of a “hachfest”. The intention was different but I ended up having an agreement to provide a secondary school with a personalised release of LibreOffice 5.2


Some people might not believe it, but I had to work hard to land the deal (and get a cup of wine, although it was easier than in Kaufbeuren).

And the lady of the house, allowed us to make a picture, of the wonderful main meal:


No worries it was finger off for me🙂

We are eager planning a real developers hack fest in Granada, so please sent me an email if you are around.

At the end of day I promised to supply a “colegio” with the newest 5.2.2 release….just part of my work as release manager

have a nice weekend

jan I.

by jan at October 01, 2016 06:08 PM

Happy birthday to LibreOffice.


This week (Wednesday) was the 6th anniversary for LibreOffice and The Document Foundation. A happy birthday from me, but even more, “job well done”.

Approximate a year ago, I resigned as Chair of the Apache OpenOffice project. I took on the  role after Andrea Pescetti, who had been a good mediator in transforming AOO from Apache Incubator to a real Apache Project. I thought as Chair, to have more possibility to help bring the two projects together (a work Andrea had started, and I had helped with). There were many discussion at different levels, starting at FOSDEM 2015 and ApacheCON Austin with the PMC, Apache board members as well as TDF board members. Sadly enough my well meant efforts caused some very personal discussions at PMC level, that eventually lead to my resignation. Dennis Hamilton, who became the new chair, have done quite a good job for the last year.

It is important to all of FOSS that does not die, a lot of people see as an equivalent of OpenSource !! It makes me sad to see, how many people put personal interest ahead of the bigger picture.

I gave a presentation at the LibreOffice Conference (2 days full of talks in 3 tracks only about the community around LibreOffice and of course the product itself), with my mentoring hat on. see

<iframe allowfullscreen="true" class="youtube-player" height="270" src=";rel=1&amp;fs=1&amp;autohide=2&amp;showsearch=0&amp;showinfo=1&amp;iv_load_policy=1&amp;wmode=transparent" style="border:0;" type="text/html" width="480"></iframe>

The LibreOffice project is very much alive, and is growing stable. A few numbers from a neutral source  open hub:

  • 289 different people made 16.484 commits within 12 months (just measuring core)

For comparison here is a link to AOO. It is my strong hope, that this will be the year where AOO and LO starts to cooperate, as I once said publicly, AOO inherited a strong brand, and LO has a high activity level, together that would make 1+1 = 3.

With my role as development mentor for LO and history of AOO, I am prepared to help as much as I can, in giving the story a happy ending.


by jan at October 01, 2016 10:15 AM

September 28, 2016

Florian Effenberger

Happy Birthday, LibreOffice!

Vor sechs Jahren, am Morgen des 28. September 2010, saß ich mit einem guten Freund zusammen. Die Nacht zuvor war extrem kurz, um online mit Kollegen aus aller Welt noch die letzten Änderungen an der Pressemitteilung einzuarbeiten, die von vielen Freiwilligen erstellte Webseite zu prüfen und den Server gemeinsam mit vielen Helfern auf den erwarteten Ansturm vorzubereiten. Wir starrten zusammen auf den Monitor, die Uhr fest im Blick, im Hintergrund lief noch Musik und um Punkt neun Uhr, gepaart mit ziemlich viel Herzklopfen, wurde eine neue Ära eingeläutet – die Ankündigung des LibreOffice-Projekts und der damals noch zu gründenden Document Foundation ging über den Äther.

Am Vortag hatten wir uns mit ausreichend Proviant eingedeckt und genug Telefone standen bereit, wussten wir doch am Morgen noch nicht, was die kommenden Stunden bringen würden.

Nicht nur offen, sondern frei

Die Wochen zuvor waren extrem spannend. Auf der knapp vier Wochen vorher zu Ende gegangenen Konferenz in Budapest konnte man eine regelrechte Aufbruchstimmung fühlen – „Foundation“, das war das Wort, das man immer wieder über die Flure schallen hörte, von Eingeweihten wie Unbeteiligten. Im Lauf der Zeit fanden immer mehr Aktive zusammen, grübelten über Namen für Programm und Foundation, tüftelten an Ideen und Konzepten und arbeiteten an der Infrastruktur, der Bestückung der weltweiten Mirrors und nicht zuletzt mussten auch Logo und Design gefunden werden und das alles, ohne allzu großes Aufsehen zu erregen. Am Abend zuvor waren schon die einzelne Vorzeichen sichtbar, die ersten Begrüßungsnachrichten auf den Mailinglisten machten die Runde – wenn ich mich recht entsinne, war der erste Satz auf der deutschen Liste ein Zitat von Georg Greve: „Am Anfang war alle Software frei.“

Auf ins Getümmel!

Da war er also nun, der große Tag, der den Beginn einer neuen Ära markieren und nicht zuletzt auch mein Leben maßgeblich verändern sollte.

Am Anfang waren noch viele Fragen offen – die Foundation existierte bislang nur auf dem Papier, ein nur vorübergehender Treuhänder in Form des damaligen Freies Office Deutschland e.V. war gefunden, aber Spenden gab es ebenso wenig wie ein Budget. Aber wir hatten schon damals etwas, das bis heute anhält – Zusammenhalt, ein gemeinsames Ziel, Aktive weltweit, Kollegen, die zu wahren Freunden wurden und „ihr Ding“ mit Spaß, Mut und Überzeugung angehen.

Die ersten Rückmeldungen waren überwältigend – wenige Stunden nach der Ankündigung begannen die ersten Entwickler ihre Patches einzureichen, die IRC-Kanäle füllten sich, die Mailinglisten erwachten zum Leben und die Presse im In- und Ausland hat die Ankündigung mehr als positiv aufgenommen.

All die Bedenken, die noch am Vorabend in meinem Kopf umhergeisterten – Wird der Server Slashdot standhalten? Klappt die Verteilung auf die Mirrorserver? – waren mit einem Mal wie weggeblasen. Es fühlte sich einfach verdammt gut an, auch wenn wir die Augen kaum von htop lassen konnten, um die Serverauslastung zu verfolgen. Und ja, wir haben den Slashdot-Effekt überlebt!

Rückblickend wird mir immer stärker bewusst, wie viele helfende Hände Anteil am Erfolg von „Tag 0“ hatten – Webdesigner, Systemadministratoren, Übersetzer, Marketing-Experten, Entwickler und Tester, Unternehmen und Organisationen, die uns von Anfang an unterstützt haben und nicht zuletzt zahlreiche Linux-Distributionen, die LibreOffice direkt in ihre Repositories aufgenommen haben.

Reichlich Zuspruch

Am Tag der Ankündigung fand in Paris eine Veranstaltung statt und die Kollegen vor Ort konnten direkt die Fahnen für LibreOffice hochhalten und die Idee der Stiftung in die Welt hinaustragen.

Zwei oder drei Wochen nach der Ankündigung fand in Nürnberg eine Konferenz statt und das Gefühl war einfach unbeschreiblich – der Zuspruch, die Aufbruchstimmung, der Enthusiasmus, der Interviewmarathon mit der Presse, noch heute erinnere ich mich wahnsinnig gern daran. Auch die erste CeBIT, ein halbes Jahr nach Projektstart, wird unvergessen bleiben, war sie doch auch die Gelegenheit, zahlreiche Mitstreiter zum ersten Mal seit dem „Launch“ in persona wiederzutreffen. LibreOffice war bereits fest im Vortragsprogramm präsent und wurde, wenn meine Erinnerung mich nicht trügt, auch gleich mit einem Publikumspreis bedacht.

Wir gehen dann mal stiften…

Seit diesen frühen Tagen haben wir einen weiten Weg zurückgelegt. Die Gründung der Foundation – damals ganz bewusst noch als englischer Begriff, da die Rechtsform noch nicht feststand – sollte dabei deutlich länger dauern als zunächst gedacht: Nach Analyse verschiedener Optionen stand schlussendlich fest, dass es eine Stiftung nach deutschem Recht sein sollte, um die Sicherheit und Garantien für unsere Community zu erhalten, nach denen wir so lange gestrebt haben. Das „Ticket“ für diese Rechtsform war der Kapitalstock, in unserem Fall in Höhe von 50.000 € – aber das Problem war, dieses Geld hatten wir schlichtweg nicht. Nach einer mit großartiger Unterstützung der Presse durchgeführten Kampagne erreichten wir binnen acht Tagen unser Spendenziel im Rahmen der „Fundraising Challenge“, wie wir sie genannt haben – lang vor Ende unserer selbst gesetzten Deadline.

Die zweite Herausforderung war das Abfassen der Stiftungssatzung, denn wir wollten die Sicherheit des deutschen Stiftungsmodells kombiniert mit starken Rechten für all diejenigen, die sich engagieren – das Prinzip der Meritokratie. Diese Idee stiftungskonform umzusetzen hat insgesamt beinahe ein ganzes Jahr gedauert. Viele Iterationen der Satzung zwischen Stiftungsaufsicht, Community und unserem unglaublich engagierten Anwalt später war es so weit – die Idee des „Mitglieder-Kuratoriums“ war geboren und zahlreiche gute Rückmeldungen und Anmerkungen zur Satzung dankbar eingearbeitet. Ich erinnere mich noch daran, wie wir gemeinsam auf der FOSDEM 2012 das Stiftungsgeschäft in der Hotel-Lobby vor uns hatten – das dazugehörige Foto muss ich bei Gelegenheit nochmal raussuchen…

Heute zählt die Stiftung an die 200 Kuratoren aus allen Ländern, Kontinenten, Berufsgruppen, Religionen, Sprachen und Kulturen und spiegelt damit die Vielfalt der Community wider und die großzügigen Spenden aus aller Welt ermöglichen es uns, zahlreiche Projekte und Ideen umzusetzen, die anfangs noch undenkbar schienen.

Die Idee freier Software ist dem Stiftungsgedanken dabei übrigens ähnlicher, als man zunächst denkt.

Die erste Konferenz

Die erste offizielle Konferenz nach einem informellen Treffen auf der FOSDEM war die LibOCon 2011 in Paris. Durchaus noch etwas, nennen wir es mal „kreativ“ organisiert – ich erinnere mich an zwei verschiedene Veranstaltungsorte, die Party in einem eher unbekannten Viertel der Stadt und den Tag, an dem ein Referent durch den Raumtrenner auf die Bühne des anderen fiel – war die Konferenz ein unglaublicher Erfolg und mehr als nur Ausdruck des „Community Spirit“, den wir alle die letzten zwölf Monate aufgesogen haben. Seitdem findet jedes Jahr im Frühherbst eine LibreOffice Conference statt: 2012 im Wirtschaftsministerium in Berlin, 2013 an der Universität Mailand, 2014 an der Universität Bern, 2015 in Aarhus, 2016 an der Universität Brno und 2017 wird die Konferenz in Rom ausgetragen.

Einen festen Platz im Programm nehmen auch die Hackfeste ein – Veranstaltungen, bei denen selbst ich als „Alien“ (sprich: Nicht-Entwickler) mich wohl fühle und die uns unter anderem nach München, Freiburg, Hamburg, Gran Canaria oder Brüssel gebracht haben. Der Erfahrungsaustausch mit Gleichgesinnten, das gemeinsame Hacken am Code und das Lernen neuer Fertigkeiten ist wichtiger Bestandteil der LibreOffice-Community und das „Pasta Hacking“ mit den italienischen Kollegen ist mittlerweile schon leckere Tradition.

Es menschelt

Neben der Arbeit „am Gerät“ ist die LibreOffice-Community auch privat zusammengewachsen. Viele Freunde weltweit, Menschen die man rund um den Globus kennt, Einblicke in Kulturen und Lebensweisen, die einem sonst verschlossen wären, auch das macht eine Open-Source-Community aus. Ich persönlich bin ja ohnehin der Meinung, dass man die Arbeit in einem Open-Source-Projekt mit dem gemeinsamen Zubereiten eines leckeren Essens vergleichen kann…

Ob Liebe nun durch den Magen geht, das vermag ich nicht zu sagen, aber im Lauf der Zeit fand nicht nur das ein oder andere LibreOffice-Pärchen zusammen. Es gab auch mindestens eine Projekthochzeit und das erste LibreBaby wurde auch schon auf den Konferenzen gesichtet – die Nachwuchsfrage ist also geklärt.

Auf eigenen Beinen stehen

Mit sechs Jahren haben viele Kinder schon ihren eigenen Kopf und einen ausgeprägten Charakter entwickelt, die Weichen für den weiteren Lebensweg werden so langsam gestellt. Als im Privatleben stolzer Onkel kann ich sagen, dass das eine wunderbare Zeit ist – die Pubertät, die mal mehr oder weniger spannend verläuft, liegt noch weit vor einem, aber schon jetzt zeichnen sich Stärken und Schwächen, Talente und Fähigkeiten ab, die den weiteren Lebensweg maßgeblich bestimmen werden.

Jeder Geburtstag ist etwas Besonderes, jedes neue Jahr wartet mit Aufgaben, Herausforderungen und Erfolgen auf – LibreOffice ist da keine Ausnahme. Und genauso wie der Zusammenhalt in einer guten Familie dafür sorgt, dass es gemeinsam voran geht, genauso sorgt auch der Zusammenhalt in der Community dafür, dass am Ende des Tages die richtigen Entscheidungen getroffen werden und das Kind wächst und gedeiht und Eltern und Freunde mit Freude erfüllt. Im Fall von LibreOffice sind das weit über 100 Millionen Freunde weltweit.

Sechs Jahre ist eine lange Zeit. Die Welt verändert sich, man selbst verändert sich, Freunde kommen und gehen. Umso schöner ist es zu sehen, dass das, was wir vor genau sechs Jahren am 28. September 2010, gemeinsam auf den Weg gebracht haben so erfolgreich ist, so vielen Menschen jeden Tag aufs Neue große Freude bereitet und für viele von uns auf die ein oder andere Art zu einem festen Bestandteil ihres Lebens geworden ist.

Lust bekommen?

Wer jetzt Lust bekommen hat, sich in einem der für mich spannendsten Open-Source-Projekte einzubringen, viel Neues über sich und die Welt zu lernen und dabei die mitunter inspirierendsten und engagiertesten Menschen zu treffen, die ich bislang kennenlernen durfte, der sollte unbedingt bei uns mitmachen, auf eine der zahlreichen Veranstaltungen (beispielsweise in München) kommen oder sich bei einer der nächsten Telefonkonferenzen einwählen! In einem Open-Source-Projekt mitzumachen ist nicht nur gut für den Lebenslauf, sondern auch eine persönliche Bereicherung, die das Leben manchmal ganz schön auf den Kopf stellen kann…

In diesem Sinne: Alles Gute zum Geburtstag, LibreOffice – und bleib so quirlig, gesund und fröhlich wie du bist!

<figure class="wp-caption aligncenter" id="attachment_88" style="width: 300px">Happy Birthday, LibreOffice!<figcaption class="wp-caption-text">Happy Birthday, LibreOffice!</figcaption></figure>




by Florian Effenberger at September 28, 2016 01:16 PM

Björn Michaelsen

Merging Communities

Come together, right now
— Beatles, Abbey Road, Come together

So September, 28th 2016 is the 6th birthday of LibreOffice and at the recent conference, we took a picture of those who were there on day zero:


As you might notice, I am not on that picture — on day zero I was working at Oracle, and were surprised by the news — like many others in this picture:


This is everyone at this years LibreOffice conference who used to work on the codebase at StarDivision, Sun or Oracle. A few people are in both pictures: Caolán McNamara and Thorsten Behrens were with LibreOffice from the start, but also worked at the team in Hamburg at some point in time. Of those working on still when LibreOffice started, I was the first to join LibreOffice — I had quit my job for that. It was an exciting time.

Looking back, both of these groups appear small — mostly because merging them, the LibreOffice community became so much more that the sum of its parts:


And of course, while a lot of people were at the conference, not everyone could
join, so there are more contributors from each of these groups than are in the
pictures. This years “state of the project” presentation showed again that the members of The Document Foundation are a truly worldwide community:


So, like the branches of the different descendants of, the
contributors and communities did come together in Brno to push
LibreOffice forward as one!

by bmichaelsen at September 28, 2016 10:58 AM

September 17, 2016

Andreas Mantke

Plone Script Fun

The Plone content management system could run Python scripts from the command line. I worked already with such scripts in the past. I decided to work on a new script that reads the current users of the new LibreOffice extensions and templates website with some additional information (e.g. email-address, roles) and put this information into a csv-file.

Then I want a list of all user names line by line in a text file. The same I want for the contributors to the new website. This will help to regularly clean up the amount of accounts in the new website and delete not used accounts (the diff of both lists).

by andreasma at September 17, 2016 08:16 PM

September 14, 2016

>Szymon Kłos

LibreOffice conference 2016 - Brno

This year again I had the pleasure to attend in the annual LibreOffice conference. This time it was organized in Brno, Czech Republic on September 7-9th 2016.

The conference was very well organized. The conference venue was located in the modern campus of the Faculty of Information Technology at the Brno University of Technology. Every day we listened talks and participated in events on evenings. It was a good opportunity to meet my mentors and other GSoC students. One of the best things is that you can find out who is behind well known IRC nick :)

First day started with opening session and presentation of the state of the project. That day we also took part in HackNight - hacking together in the Red Hat office. My short talk was on the last day of the conference. There was a GSoC panel where we were able to present our projects. At the end we went sightseeing Brno.

I would like to thank sponsors, The Document Foundation and all organizers for a great event.

We also found out where will be organized next meeting.

See you next year in Rome!

by Szymon Kłos ( at September 14, 2016 08:30 AM

September 13, 2016

Miklos Vajna

Using clang-based tools beyond loplugin LOCon lightning talk

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.

September 13, 2016 12:37 PM

September 12, 2016

Miklos Vajna

A year in LibreOffice's RTF support LOCon talk

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.

September 12, 2016 07:55 AM

September 11, 2016

Jan Iversen

Birthday and Libreoffice staff meeting in Brno

I became a year older today, while attending our staff meeting in Brno.

My collegaues surprised me in the morning with a birthday song, something that has not happened in many many years.

At lunch time, they gave the BIG SURPRISE, a cake and a bottle of italian “champagne”

BRNO, Staff meeting, LibreOffice

A BIG THANK to all my collegaues for making this day more special than normal.

The libreoffice community is really about having fun !!



by jan at September 11, 2016 04:42 PM

Charles Schulz

Women & Free Software projects

I have never written about this rather sensitive topic before, but I recently realized that when we set up the concept of “Native-Language Communities” back in the old days of, the general idea was to allow everyone to participate to a Free Software project. Now, the stated ability -the basic freedom if you will- for women to contribute to any Free Software project has never been offically questioned. The reality, however, is more complex.

Surveying a broad range of Free & Open Source Software projects will highlight one unmistakable trend: Only very few women may be counted as contributors (active, regular, or otherwise) . Even The Document Foundation that is rather on the top of the projects with several women on the board of Directors, part of the foundation’s staff and among the most active developers, the community likely has about a dozen female contributors. A dozen over several hundred contributors: that’s not much. It is possible to explain this relative absence of female developers by several social and cultural factors (some jobs and industries tend to attract more males than females, etc.) . To a large extent that is probably true. What these factors do not take into account, however, is the social games of discrimination towards female developers occuring in some communities.

To many women, a large social group of men they are supposed to join may be intimidating – the same could probably be said of any men joining a large social group primarily populated of women. But when what looks intimidating reveals itself as being actually oppressing , that is the moment we have a true problem. Male developers shunning, criticizing, belittling and offending female developers because they are females, even when not necessarily expressed in an explicit way, is purely not acceptable. It is neither on the most basic moral grounds nor in the letter and spirit of the Free Software movement. The Internet, unfortunately, reveals protracted bullies, the kind of people who would probably not have the guts to ask the targeted woman out, or even not dare look at a female developer in the eyes and tell her what he would be able to write from the comfort of his own keyboard, miles away from her.

In the Free & Open Source Software projects, a particular attention must then be paid to this double issue: ensuring female contributors feel at ease participating to the community while ensuring that no form of discrimination based on sex (or race for that matter) is explicitly or implicitly tolerated as an acceptable behaviour. In concrete terms, clear rules against discrimination should be laid out and enforced – the latter being the key part of the solution – while a number of ideas should be explored in order to ease the participation of female contributors to Free Software projects. The Debian Women project is in many ways a great testbed for future initiatives.

Meanwhile, let’s all remember that regardless of our personal views on society, religion, politics and other topics, no one should be discriminated for its involvement and contribution to Free Software projects. Free Software is too important to let it sink under those issues, and female contributors deserve the same respect and the same roles as male developers. Software freedom comes for everyone.

by Charles at September 11, 2016 10:08 AM

September 10, 2016

Jiri Eischmann

LibreOffice Conference 2016

LibreOffice Conference 2016 is over and for us organizers it’s a time to reflect.


It was the third big open source desktop conference we’ve managed to get to Brno (after GUADEC 2013 and Akademy 2014). 3 days of talks, 150 attendees from all over the world, 4 social events.

The conference went pretty well from the organizational point of view. Feedback has been very positive so far. People liked the city, the venue (FIT BUT campus is really, really nice), the parties, and catering during the conference. TDF board even lifted Red Hat to the highest sponsorship level for the amount of work we did for the conference. The only major bummer we had was no online streaming. It’s quite easy to set it up with the university’s built-in video recording system, but the university didn’t allow it in the end. Nevertheless, we treated online streaming as nice-to-have. Video recordings are important to us and we’ll do our best to get them online as soon as possible.

I’ve (co)organized quite a few international conferences, but what was new for me was an attendee who gets seriously sick and needs medical services. One of the Libocon attendees got a serious infection in his leg and we spent a lot of time driving between hospitals, talking to doctors, arranging things. Everything ended well and the attendee got so better than he was even able to fly back home as he planned originally which didn’t look very likely at the beginning.

What I really don’t like doing is being an organizer and speaker at the same conference. As an organizer you’re just too busy and can’t concentrate on a talk you’re supposed to deliver. I volunteered to do an introductory talk in the Friday’s Czech track. I was even given already prepared slides and using someone else’s slides is another thing I don’t like doing. So as you can imagine it was not one of the best talks of my career🙂 But the Czech track turned out to be quite good overall. I just wish more people had come, but if you only have <2 weeks to promote the program you won’t get crowds to the conference.

I’d like to thank The Document Foundation for a great cooperation, and all attendees for being so kind and forgiving us minor glitches in the organization. It was an exhausting, but great experience, and I hope to see everyone in Rome next year where I can again be in the comfortable seat of a visitor.

by eischmann at September 10, 2016 03:05 PM

Markus Mohrhard

Writing a LibreOffice Calc UI test

After the blog post describing the design of the UI testing framework I wanted to quickly follow up with a post showing how to write a simple test.

As is a bit expected (in the end I’m still a calc developer😉 ) currently the support for calc tests is better than for other applications. There is already support for writer, impress and math with different degree of completeness. Especially the special main windows have only a limited support for special operations right now. A future blog post will show how to add introspection support to a special UI element.

In this blog post I will show how to add a simple Calc UI test that creates a range name.


We will start with a new file that contains just the minimal boilerplate code to have a new test that is discovered by the test framework. We place the file in the uitest/calc_tests directory as this one is listed in uitest/ to contain test code.

Inside of any class derived from uitest.framework.TestCase any method with a name starting with test will be executed by the test framework. We will simply name our method for now test_number_format


Writing the test

Let us start with the code and explain on the code what each part does.

1  from import mkPropertyValues
3  from uitest.framework import UITestCase
5  class CreateRangeNameTest(UITestCase):
7      def test_create_range_name(self):
9          self.ui_test.create_doc_in_start_center("calc")
11         self.ui_test.execute_modeless_dialog_through_command(".uno:AddName")
13         xAddNameDlg = self.xUITest.getTopFocusWindow()
14         xEdit = xAddNameDlg.getChild("edit")
16         actionProps = mkPropertyValues({"TEXT":"simpleRangeName"})
17         xEdit.executeAction("TYPE", actionProps)
19         xAddBtn = xAddNameDlg.getChild("add")
20         xAddBtn.executeAction("CLICK", tuple())
22         self.ui_test.close_doc()


Obviously line 1 and 3 just import the method and class that we need.

Line 5 creates a class that inherits from our UITestCase class and therefore all methods in it will be executed as test cases.

Line 7 defines the test method. Note that the method name needs to start with test to be picked up by the test framework.

The test framework starts LibreOffice and opens the start center so line 9 is a helper method that clicks on the Calc button in the start center and waits until the document is ready.

By line 11 we have a working calc document and need to open the range name dialog. There are a few helper methods for this in the UITest class. All dialogs are opened by sending an UNO command ID (in our case “.uno:AddName“) instead of going through the menus. Currently there are two separate methods for modal and modeless dialogs but the plan is to combine the two methods into one. As soon as this method returns the dialog is ready and we can work with the dialog.

Line 13 and 14 select different UI elements. In line 13 we get a reference to the current top window that has the focus. This is the window that represents the whole dialog. From this UI element we ask for the child with the ID “edit”. The ID is imported from the ui file of the dialog. xEdit now contains a reference to the name edit of the dialog.

Line 16 and 17 send a string that should be typed to the edit. mkPropertyValues in line 16 creates the required sequence from a dict. In line 17 we send this sequence as argument to executeAction. The first argument to the method is the action that should be executed on the UI element. For the TYPE action the framework generates keyboard events that are sent to the element.

Line 19 and 20 select the “add” button and send a “CLICK” action closing the dialog. At this point we could add any code we want to assert that the range name has actually been created correctly.

Finally in line 22 we close the document. The UITest.close_doc method correctly handles the query dialog requesting confirmation that we want to discard all changes.

Running the test

Before we push the test to master we should obviously check that the test is working. A simple way is to execute all UI tests in the uitest module through make uitest.uicheck. However we would like to see the UI while the test is being executed and the tests are run headless by default.

The solution that I currently use is a simple script starting a test. Obviously the plan is to have a better solution in the framework at some point.

When you execute the test with the visible UI you’ll notice that the test is too fast to see what is going on. A quick and dirty solution is to add python’s time.sleep which stops execution for a bit. The other solution that you can actually leave in the code (only leave a few useful ones in a test) in interesting places is uitest.debug.sleep. This method is ignored unless the test is started in debug mode by passing the --debug parameter to the test.


You can see the test in the repository in the uitest/calc_tests/ file. The second test in that file shows how to create a local range name by selecting the second entry in the combo box.

More blog posts and wiki pages documenting the UI test framework are going to follow soon.

If you have any question or suggestion please contact me.

by Markus Mohrhard at September 10, 2016 04:20 AM

September 09, 2016

Miklos Vajna

Collaborative editing using LibreOfficeKit LOCon talk

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. :-)

September 09, 2016 07:45 AM

September 07, 2016

Markus Mohrhard

UI testing in LibreOffice

Anyone familiar with testing in LibreOffice knows that for a long time we have had one huge weak point in our testing infrastructure. Until now we were more or less unable to do any UI testing which means we had no chances to test a fairly big part of our code base. We have existing tests for import and export, for performance problems, for normal low level classes and even two frameworks for our UNO API. More or less for everything except for our UI we already have a solution that works quite well.

This post will outline why it took until now to add the UI testing framework and how the design tries to solve some of the weak points of existing UI testing approaches.

Difficulties of UI testing

I have been discussing different designs for an UI testing framework for a few years with other developers at various conferences but never felt like one of the designs would not cause more problems than it solves. I’ll outline below how the new UI testing framework solves some of the problems that I have with other concepts.

My list of requirements for a good (UI-)testing framework are:

  • Easy to add a test: This is even more important in an UI testing framework where we ideally want the UX team to add test cases as well.
  • Stable across unrelated changes: I don’t want to see failing tests because someone changed an unrelated part of the code. In the UI case this also includes that the test should not fail because someone renames a button or moves an UI element. This requirement is meant to reduce the maintenance costs of the tests.
  • As close to the code paths triggered by an user as possible: We want to test the code that is used in production and not some random test code.
  • Does not need random sleeps: Needing to add sleeps to deal with asynchronous events makes executing the tests brittle and includes random false positives.
  • Low number of false positives: Obviously if the number of false positives is too high developers start to ignore test failures.


This is a quite complex list and even the proposed solution might not always be able to fulfill all the requirements but at least it should improve compared to the other considered solutions. The most common solutions for UI testing that people propose are using the accessibility framework or hard coding the path to UI objects. However in my opinion both solutions have some problems that make them unsuitable as testing concepts in LibreOffice.

The hard coded path approach obviously is not stable across UI changes and becomes brittle across different OS versions. The big advantage compared to many other approaches is that you can in theory just record an user interaction and replay it during the tests. Also it would work with any version of LibreOffice without any changes but you pay with increased maintenance costs.

The accessibility based approach suffers from our poor quality of the accessibility code (some people will argue that it is a chance to clean it up) and that the code is not that close to what happens if a non-accessibility user does an action. Sadly the code is not yet stable so at least for a long time until we manage to improve the accessibility code significantly we would suffer from regularly failing tests which in the long run means that developers start to ignore the tests.

Compared to the hard coded path approach the accessibility idea is already an improvement from the maintainability based approach and is used in quite a few programs. However it still does not completely solve the problem of changing dialogs and it is much mroe complicated to write a test.


To solve the problems outlined above the new framework trades upfront costs for easier maintenance later. From a mile away the UI testing approach is based on a bit of newly written introspection code interacting with a testing framework in python through a simple mostly un-typed UNO interface. To identify objects we use the ids that we introduced for loading dialogs from UI files.

Introspection code

The introspection code is a small bit of code around UI objects providing a simple standard interface to each UI object. The interface provides methods to get state and properties of the UI objects as well as sending commands to the objects. For a button a property could be a label and an action could be sending a click command. The introspection library would then call the method on the VCL button object that is called by a real button click.

Obviously we are still not directly taking the same code paths with this introspection code as a real mouse click but we can get as close as possible as any automation framework that is not sending real mouse events can get.

Introspection code for many commonly used UI objects is already available and adding new code for UI objects that are not yet covered is simple. More details on how to add such introspection objects will be added to the wiki page soon.

To solve the problem that many UI operations happen asynchronously we have added some events (for now only for opening dialogs) and will use events as a way to make the tests more reliable. Existing events that get reused are the events for signaling that a document is ready and that the document has been closed.

Finding an object is solved through the ID that we most of the time get from the ui file. Nearly all of them are locally unique so they make for some great identifiers that stay unchanged even when a dialog is reorganized or a new element is introduced. Obviously this would still cause issues when a button is moved from one container widget to another one and we ask the old one for a child with the ID. However as we assume locally unique IDs we just always walk up to the top level window (either of the dialog or the whole document) and search for there.

Python testing framwork

The actual tests are not written in C++ and while I’m normally not a fan of using different languages for writing tests it seems like the right decision here. The tests only interact with LibreOffice through the UNO interface and we want to lower the barrier for adding UI tests compared to our complicated internal C++ tests (which are still much more useful for anything that you need to debug regularly). Additionally debugging of the UI tests can normally happen by invoking the UI operations manually whereas debugging one of our other tests is bound to some function calls.

The testing framework is split into three parts: the test cases, the framework code specific to UI testing and useful UNO code. Splitting the last part out from the rest allows us to collect useful code snippets that can be used in other places or even by external developers interacting with LibreOffice. An example that is already in the framework code is the code used to start LibreOffice and create a socket connection.

Adding a new test mainly requires to create a class that derives from the main test class and through introspection each method whose names starts with test will be executed (an example; the sleeps are just for visual inspection).

To make the life easier there is a UITest object that provides access to some common operations like opening a dialog and waiting for the event that the dialog is ready.


Open issues

The implemented test framework trades stability of the tests against less code. For now only the most common UI objects have introspection code, which still covers around 90% of the objects, but there are still corner cases where we need to add more code to the introspection library. Nevertheless you can already write tests for many of the dialogs and can already inspect some of the demo code that I have written.

I’m also still chasing two race conditions that make the tests deadlock or fail. The deadlock case is already handled by a patch that is in gerrit and just not yet pushed to the repository, but the case that Impress tests fail with the new template chooser is still under investigation(the time.sleep in [1] are currently mandatory).

I would also like to move some of the tests([2],[3],[4],[5]) from the uitest module into the correct application module (sc for calc, sw for writer, …) but that needs some more makefile code.

Another open issue is still how to best organize running the uitests under gdb. There is some support already but sadly it is not working as well as it should.


I’m going to add more documentation in form of blog posts and wiki pages soon but you can already get an idea of how the tests work by inspecting the code in the uitest module.

Executing the tests should mainly work (except for the two problems mentioned above) with a make uicheck or make uitest.uicheck after a successful make.

Please report all problems and suggestions to me so that I can integrate them into the new framework.

by Markus Mohrhard at September 07, 2016 05:46 PM

Andreas Mantke

New Release For The New LibreOffice Templates Site

I worked on some more bits of the Plone 5 add-on for the new LibreOffice templates website. There were especially some localisation tags missing etc. I updated them and the corresponding localisation template file. The new release ships also with a first localisation into German. The source code is available at the repository of The Document Foundation at github (

The new release is available at the ‚Cheeseshop‘:

by andreasma at September 07, 2016 02:06 PM

September 06, 2016

TDF Infrastructure Status

jenkins (ci) unavailable

Jenkins VM has gone bonkers, to recover we need to move other VMs off the hypervisor to be able to reboot. Sorry for any inconveniences this might cause - other services should continue to work without interruption.

by The Document Foundation at September 06, 2016 10:00 PM

September 02, 2016

Jan Iversen

GSoC 2016 is over

Google Summer of Code 2016 have ended, now we can evaluate.

I was Org. admin for


We got 12 slots from Google, which was used to create some awesome changes in LibreOffice, which will be released later this year with 5.3.

I am proud to see that Google recognises our consistent work, to deliver the best open office package on the planet…and even keep it free.

Thanks to all the students who participated, you can be proud of yourself. We had 86 Students apply for the 12 projects, so election was tough decisions, but I would like to thank all students who applied for projects, thanks for taking an interest in LibreOffice.

It is our hope that we will be able to run more projects at GSoC 2017.

Looking forward to talk/mail with students again next year. In the meantime we do not sleep, and I continue to help new contributors:

Developers get involved

And just for the fun of it, Google just mailed me a certificate

gsoc_mentor for jan iversen


Have a nice time out there.

Jan Iversen

by jan at September 02, 2016 06:03 AM

August 31, 2016

LibreOffice Design Blog

Tickets on behalf of UX

The simplest way to contribute to LibreOffice is to submit bugs and enhancement requests to our bugtracker. This is also true for design and usability related issues, where up until now we had the ux-advice component that these bugs

by The LibreOffice Design Team at August 31, 2016 01:26 PM

August 28, 2016

Andreas Mantke

OpenSuSE Leap 42.1 and Brother MFC 7320

I tried to get the scanner of a  Brother MFC 7320 into work with openSuSE Leap 42.1. I could install the software with a script ‚linux-brprinter-installer-2.0.0-1‘ downloaded from the support page of the vendor. But there was an issue with the conection to the scanner via USB-Port. Although the model is not new the scanner was not listed in /etc/udev/rules.d/55-libsane.rules. I looked with scanimage -L out for the scanner and it was listed. Then I run lsusb and got the vendor-id and the device-id. I added a new entry to the libsane.rules file:

# Brother MFC-7320 ATTR(idVendor)==“04f9″, ATTR(idProduct)==“01eb“, MODE=“0664″, GROUP=“lp“, ENV(libsane_matched)=“yes“

Then I had to add the user to the group ‚lp‘ and after a restart the scanner works.

Xsane got the scanner and I could also use the automatic scanner utility to scan more than one page at once. There is a special mode for this in xsane for this (drop down menu on the top right). I had to count the pages of the multipage scan and put the number in the field on the top left. There is a pop up window where I had to create a multipage project. Then everything was done by xsane and its toolbox.

by andreasma at August 28, 2016 08:08 PM

New Release For Extensionuploadcenter And Update Of Testwebsite

I worked on the localisation of the Plone add-on tdf.extensionuploadcenter and added the last bits. I published a new version with this changes and a first localisation into German today.

The testwebsite for the new LibreOffice extensions templates repository uses this new release and also the latest release of tdf.templateuploadcenter. Thus it reflects the current development status.

by andreasma at August 28, 2016 02:11 PM