Welcome to The Document Foundation Planet

This is a feed aggregator that collects what LibreOffice and Document Foundation contributors are writing in their respective blogs.

To have your blog added to this aggregator, please mail the website@global.libreoffice.org mailinglist or file a ticket in Redmine.

19 May, 2022


Added something to track the org.freedesktop.appearance.color-scheme property as used by the GNOME 42 Dark Style Preference setting. Screencast recorded with the new iteration of GNOME's screen built-in recorder which is quite snazzy.


Have you received “A polite ping, still working on this bug?” message on one of your Gerrit submissions? You can simply send an arbitrary reply to avoid the patch being abandoned within a month. Here we discuss more about Pootle bot, which is one of the QA (Quality Assurance) tools for the LibreOffice QA team to manage old submissions.

Interacting with the Pootle Bot

You may have received messages from some bots, including Pootle bot. This bot checks Gerrit to find the older submissions, and abandon the old ones that no one actively work on them.

If it has been several months after the last change on a submission, the bot adds a comment and asks:

A polite ping, still working on this bug?

Then, you can do one of these things, according to your choice:

    1. Reply with whatever you want, and the Pootle bot will not longer try to abandon your submission. Do this if you want to continue work on the submission.
    2. Mark the patch as “work in progress”. This would be helpful if you want to prevent the bot from monitoring the submission.
    3. Leave it as is. Then, after 1 month your patch will be automatically abandoned with this message:


Abandoning this for the moment due to inactivity. Be aware it can be reopened anytime if you still want to continue working on it. Do not forget to rebase it first.

Even in this case, you don’t have to worry! As the message says, you can simply click on the RESTORE button on the top right of the page to restore the patch and continue working on it.

Please note that if you have restored an old submission, you have to do a re-base to get the latest changes in the LibreOffice code, pushed while your submission was remaining intact. If there is not a merge conflict, you can do this easily by clicking on the REBASE button on the top right of the page. Otherwise, you have to download the patch and resolve the merge conflict manually.

More information

You can find more information about

Also, you can read this previous post on how to use Gerrit code review.

18 May, 2022


The Impress Guide 7.3 has just arrived with the latest LibreOffice Impress 7.3 developments.

Download Impress Guide 7.3

This 374 pages book covers the main features of Impress, the presentations (slide show) component of LibreOffice. You can create slides that contain text, bulleted and numbered lists, tables, charts, clip art, and other objects. Impress comes with prepackaged text styles, slide backgrounds, and Help. It can open and save to Microsoft PowerPoint formats and can export to PDF, HTML, and numerous graphic formats.

The Guide update was an effort of Peter Schofield and Kees Kriek.

Peter Schofield

Peter Schofield

Kees Kriek

Thank you guys for the wonderful Impress Guide!

The full set of published LibreOffice guides is available in the LibreOffice Documentation Website and in the LibreOffice Bookshelf Project.

Join the Documentation Team

16 May, 2022


LibreOffice Conference 2022 will be a hybrid event, both in presence and remote, scheduled for the month of September, from Thursday, September 29th at 9:00AM CEST, to Saturday, October 1st at 1:00PM CEST (https://conference.libreoffice.org/2022/). In addition, there will be a community day on Wednesday, September 28th. The event will be at NOI Tech Park in Bolzano/Bozen (https://noi.bz.it/it), the capital city of South Tyrol, in northern Italy.

All sessions at NOI Tech Park will be streamed live and recorded for download, but it will be possible to present from remote on Friday, September 30th (details will follow). Workshops will be possible only in presence, and should be agreed with organizers in order to schedule them in a specific room (which will be recorded but not streamed).

The Document Foundation invites all members and contributors to submit talks, lectures and workshops for this year’s conference. Whether you are a seasoned presenter or have never spoken in public before, if you have something interesting to share about LibreOffice, the Document Liberation Project or the Open Document Format, we want to hear from you!

Proposals should be filed by July 15, 2022, in order to guarantee that they will be considered for inclusion in the conference program.

The conference program will be based on the following tracks:

  • Development, APIs, Extensions, Future Technology
  • Quality Assurance
  • Localization, Documentation and Native Language Projects
  • Appealing Libreoffice: Ease of Use, Design and Accessibility
  • Open Document Format, Document Liberation and Interoperability
  • Advocating, Promoting, Marketing LibreOffice
  • Diversity and Inclusion, New Generation

Presentations, case studies, and technical talks will discuss a subject in depth and will last 30 minutes (including Q&A). Lightning talks will cover a specific topic and will last 5 minutes (including Q&A).

Please send a short description/bio of yourself as well as your talk/workshop proposal to https://events.documentfoundation.org/libreoffice-conference-2022/. If you want to give multiple talks, please send a separate proposal for each.

Please check if you need a VISA to travel to Italy on this page (available in Arab, English, Russian and Chinese): https://vistoperitalia.esteri.it/home/. If you need a VISA, please get in touch with Italo Vignoli (italo@libreoffice.org) as soon as possible, to get an invitation letter.

If you cannot travel to Italy and prefer to present from remote, please add a note to your talk proposal, in order to allow organizers to schedule your talk on Friday (and organize a test session in advance).

If you do not agree to provide the data for the talk under the “Creative Commons Attribution-Share Alike 4.0 License”, please explicitly state your terms. In order to make your presentation available on TDF YouTube channel, please do not submit talks containing copyrighted material (music, pictures, etc.).

Thanks a lot for your participation!

13 May, 2022


In 2021, the infrastructure team migrated our “Ask LibreOffice” site to Discourse, deployed a Decidim instance, and assisted with video streaming during the LibreOffice Conference.

(This is part of The Document Foundation’s Annual Report for 2021 – we’ll post the full version here soon.)

LibreOffice’s infrastructure team is responsible for maintaining the hardware, virtual machines and services that enable the wider community to develop, market, test, localize and improve the software. The public infrastructure is powered by around 50 kernel-based virtual machines (KVMs) spread across four hypervisors, plugged to an internal 10Gbps switch, hosted at Manitu in St. Wendel (Germany), and managed with libvirt and its KVM/QEMU driver. The virtual disk images are typically stored in GlusterFS volumes – distributed across the hypervisors – except for some transient disks (such as cache) where the IOPS requirement is higher and the redundancy less important.

As 2021 marked another “pandemic year” with only online events, the infrastructure team helped to make these a pleasant experience from home. Notably, they deployed a Pretalx instance to manage conference submissions and the schedule, and put in place a streaming backend based on Jitsi/Jibri/RTMP during the annual conference, thereby providing several participation options to chose from.

Ask LibreOffice

After several months of tests and feedback from the community, the infra team also concluded the migration of LibreOffice’s Q&A platform (“Ask LibreOffice”) to Discourse. Over 65,000 questions and 130,000 replies from 50,000 users — spanning over 17 languages — were imported, with a focus on preserving post attribution and overall layout. The metric collection engines (Matomo as well as the public Grimoire Dashboard) were updated to reflect that change.

Also on the community participation front, the infrastructure team deployed a Decidim instance to structure debate and encourage democratic participation from community members. The instance is currently still under test.

On the Continuous Integration (CI) front, the team deployed new buildbots for Windows and Linux baselines, as well as a buildbot for the WebAssembly (WASM) effort. They also migrated and refactored the bibisect setup to better suit the needs of the quality assurance community.


As for the backends: Debian GNU/Linux 11 (codename “Bullseye”) was released in the middle of 2021, and the team upgraded most of TDF’s virtual machines accordingly during the second half of the year. However, for the lower layers of the virtualization stack, the upgrade is planned for 2022. Furthermore, lots of work was done in planning the restructuring of database engines, most notably around Point-in-Time Recovery; this work was driven by contributor Brett Cornwall. Finally, the team assisted the Membership Committee with the architecture of the back-end side of their new tooling.

Like what we do? Support the LibreOffice project and The Document Foundation – get involved and help our volunteers, or consider making a donation. Thank you!

12 May, 2022


Berlin, May 12, 2022 – LibreOffice 7.2.7 Community, the seventh minor release of the LibreOffice 7.2 family, targeted at desktop productivity, is available for download from https://www.libreoffice.org/download/.

End user support is provided by volunteers via email and online resources: https://www.libreoffice.org/get-help/community-support/. On the website and the wiki there are guides, manuals, tutorials and HowTos. Donations help us to make all of these resources available.

For enterprise-class deployments, TDF strongly recommends the LibreOffice Enterprise family of applications from ecosystem partners, with long-term support options, professional assistance, custom features and Service Level Agreements: https://www.libreoffice.org/download/libreoffice-in-business/.

LibreOffice 7.2.7’s changelog pages are available on TDF’s wiki: https://wiki.documentfoundation.org/Releases/7.2.7/RC1 (changed in RC1) and https://wiki.documentfoundation.org/Releases/7.2.7/RC2 (changed in RC2).

LibreOffice Community and the LibreOffice Enterprise family of products are based on the LibreOffice Technology platform, the result of years of development efforts with the objective of providing a state of the art office suite not only for the desktop but also for mobile and the cloud.

LibreOffice Technology based products for Android and iOS are listed here: https://www.libreoffice.org/download/android-and-ios/, while for App Stores and ChromeOS are listed here: https://www.libreoffice.org/download/libreoffice-from-microsoft-and-mac-app-stores/

LibreOffice users, free software advocates and community members can provide financial support to The Document Foundation with a donation via PayPal, credit card or other tools at https://www.libreoffice.org/donate.

LibreOffice 7.2.7 is built with document conversion libraries from the Document Liberation Project: https://www.documentliberation.org.


So I enabled support for up to 16384 columns in Calc by default some time ago, but just getting it to work was not necessarily the end of the work. Making Calc have 16 times more columns means that any operation that works on entire columns is suddenly 16 times slower, or even worse. Similarly this could easily lead to 16x more memory used. So the support not only needs to work, but it also needs to be usable.

It theory adding a number of empty columns to the end of a spreadsheet should not make a difference, but in practice it does. With 1024 columns it is not as necessary to ignore those empty columns as it is with 16k, and a lot of the code dates back to the times when Calc supported even fewer colums (256?), where a being little inefficient here or there didn't show. But now it suddently did.

For example, if you protect or hide all unused columns until the end of the spreadsheet, then hitting the right arrow key on the last accessible cell makes Calc check all cells to the right for whether it's possible to go into them. And checking whether a column is hidden requires searching the list of column information, which is not trivial (it's compacted in order not to waste memory). The barely noticeable cost of this with 1024 columns got large enough to cause noticeable delays. Fortunately the ColHidden() function is smart enough to return the first and last column in the compacted range where the flag is equal, the code doing the cursor navigation just up until now didn't bother using that information, but now it needed to do so.

Another example, and that's quite a large topic, is allocating columns. If most of those new columns are not actually used, then it makes sense to allocate them only when needed, right? That will save memory, and it will make things faster too, because there is no need to check those empty columns. That idea got implemented back when this 16k work was started by others, adding e.g. function GetColumnsRange() that clamped the range to the allocated columns, but the problem is that in practice this is not as simple as that.

One of the issues here is let's say the case of selecting an entire row (clicking the row number to the left of the table does that easily) and then hitting Ctrl+B to make the entire row bold. That should not clamp the column range to the allocated columns, because if I later enter something into cells in those columns, I expect that to be bold. But if Calc allocates all columns for this, maybe I do not intend to enter values anywhere else except the first rows, so allocating all columns will be a waste. The solution to this is having default column data. The ScTable class now, besides having a list of allocated ScColumn

10 May, 2022


Zdeněk Crhonek (aka “raal”) from the Czech LibreOffice community writes:

The Czech team has finished its translation of the LibreOffice Getting Started Guide 7.3. As usual it was team work, namely: translations by Petr Kuběj, Zdeněk Crhonek and Ludmila Chládková; localized pictures by Roman Toman; and technical support from Miloš Šrámek. Thanks to all the team for their work! The Czech translation of the guide 7.3 is available for download on this page.

Indeed, many thanks to everyone in the Czech community for their work! Learn more about LibreOffice’s documentation project here.

09 May, 2022


Quality Assurance (QA) is a cornerstone of the LibreOffice project, thanks to the activity of a large number of volunteers and the feedback of many users who help in reporting bugs and regressions.

(This is part of The Document Foundation’s Annual Report for 2021 – we’ll post the full version here soon.)

In 2021, the QA team triaged thousands of bugs, bisected hundreds of regressions, and answered questions from countless bug reporters. As one of the most visible groups directly responding to end users, the QA team must be nimble and able to adapt to changes. In addition, it must deal with specific requests for help from other teams.

The QA team meets regularly on IRC on the #libreoffice-qa channel, which is the best medium for discussing bugs and regressions. The IRC channel provides an excellent opportunity to remain in close contact with team members, and to tutor new members in the art and skill of LibreOffice QA. This is bridged to the Telegram group.

During 2021, 6,804 bugs were reported by 3,022 users, which means 131 new bugs were reported every week on average.

Top 10 bug reporters

  • Telesto (571)
  • NISZ LibreOffice Team (296)
  • Regina Henschel (126)
  • Mike Kaganski (115)
  • Xisco Faulí (104)
  • Eyal Rozenberg (87)
  • Rafael Lima (66)
  • sdc.blanco (60)
  • Valek Filippov (54)
  • Colin (50)

Bug Hunting, Bibisecting

In July 2021, the QA Team organized an online Bug Hunting Session for LibreOffice 7.2. This provided the opportunity for all users, especially those with technical knowledge, to test pre-release versions and provide their feedback in the IRC channel and Telegram group. They were helped to report and confirm bugs, which led to improved stability in the final release.

Also, during 2021, the QA team performed 652 bibisects of regressions.

Top 10 Bisecters

  • Xisco Faulí (166)
  • Timur (85)
  • Aron Budea (68)
  • raal (66)
  • Buovjaga (48)
  • Telesto (46)
  • NISZ LibreOffice Team (29)
  • Justin L (23)
  • Roman Kuznetsov (23)
  • Kevin Suo (18)

Learn more about the QA project on this page, and give the team a hand!

Like what we do? Support the LibreOffice project and The Document Foundation – get involved and help our volunteers, or consider making a donation. Thank you!

06 May, 2022


General Activities

  1. Adolfo Jayme Barrientos made many minor improvements to Help text readability
  2. Seth Chaiklin updated the help for Bullets and Numbering toolbar and made several help page refactorings and tweaks. He also improved many LibreOffice UI strings, tips of the day and UI layouts
  3. Ilmari Lauhakangas (TDF) improved the style of code blocks in Help and started making tables mobile-friendly. He also updated the links to the Developer Guide in LibreOffice source code
  4. Alain Romedenne added notes to Help about Basic ‘New’ operator being optional when setting ‘Option Compatible’ and improved Help for ScriptForge. He also improved many LibreOffice UI strings
  5. Olivier Hallot (TDF) documented Writer manual row break in Help, updated Impress menu paths and made several other improvements to Help
  6. Miklos Vajna (Collabora) worked on content controls feature for Writer, continued working on colour themes in OOXML documents, polished the clearing breaks feature and improved the layout XML dump developer feature
  7. Jean-Pierre Ledure worked on the ScriptForge library and made a couple of small fixes to Access2Base
  8. Tünde Tóth (NISZ) finished fixing the handling of embedded and linked media in PPTX files and polished the fix for the old issue with embedded images getting multiplied upon OOXML export
  9. Dennis Francis and Szymon Kłos (Collabora) worked on LOKit improvements
  10. Vasily Melenchuk (CIB) made it so “border between” feature for tables in Microsoft formats is emulated while waiting for proper support to be implemented. He also fixed a text encoding issue with RTF files and made RTF filter faster
  11. Eike Rathke (Red Hat) improved date handling in Calc
  12. Bartosz Kosiorek polished EMF+ graphics implementation and added initial support OfficeArtBlip TIFF format
  13. Tomaž Vajngerl (Collabora) started working on MSO-style data tables for charts and continued working on sparkline support for Calc
  14. Regina Henschel fixed several issues with shapes in OOXML files
  15. Arnaud Versini made some code cleanups
  16. Julien Nabet fixed some TIFF image handling issues, fixed an issue with copying complete rows in Firebird databases, implemented VBA.FormatPercent function and removed an unwanted restriction the field “Width of numbering” in list style dialog. He also made crash fixes and code cleanups
  17. Jim Raykowski made many polishing fixes to Navigator, including to the ordering of items and more precise categorisation
  18. Andreas Heinisch made it so inserting a hyperlink in Calc without being in edit mode uses cell text content as the link text, improved font family handling in Insert Special Character dialog and fixed XLS export of charset used in VBA macros
  19. László Németh continued improving change tracking and made pasting and inserting rows into Writer tables more robust
  20. Xisco Faulí (TDF) made nearly forty improvements and additions to automated tests. He also added INT formula support into Writer tables for DOCX interoperability, fixed colour problems with bullet points and underlines in PPTX files and made a crash fix
  21. Heiko Tietze (TDF) fixed a layout issue in options dialog
  22. Armin Le Grand (allotropia) worked on Advanced Diagram support
  23. Ilmari Lauhakangas (TDF) and Timur Gadzo created a

05 May, 2022


LibreOffice is now available for download also on SourceForge

Berlin, May 4, 2022 – LibreOffice 7.3.3 Community, the third minor release of the LibreOffice 7.3 family, targeted at technology enthusiasts and power users, is available for download from https://www.libreoffice.org/download/. In addition to the LibreOffice website, starting from tomorrow it will be possible to download LibreOffice from SourceForge: https://sourceforge.net/projects/libreoffice/files/libreoffice/stable/.

Logan Abbott, SourceForge’s President and COO, says: “We’re happy to add to our open source download library an amazing open source office suite such as LibreOffice, which is without a doubt one of the best office suites ever and one which I personally use often. I highly recommend it to anyone that needs a powerful FOSS office suite.”

The LibreOffice 7.3 family offers the highest level of compatibility in the office suite market segment, starting with native support for the OpenDocument Format (ODF) – beating proprietary formats in the areas of security and robustness – to superior support for DOCX, XLSX and PPTX files.

Microsoft files are still based on the proprietary format deprecated by ISO in 2008, which is artificially complex, and not on the ISO approved standard. This lack of respect for the ISO standard format may create issues to LibreOffice, and is a huge obstacle for transparent interoperability.

LibreOffice for enterprise deployments

For enterprise-class deployments, TDF strongly recommends the LibreOffice Enterprise family of applications from ecosystem partners, with long-term support options, professional assistance, custom features and Service Level Agreements: https://www.libreoffice.org/download/libreoffice-in-business/.

LibreOffice Community and the LibreOffice Enterprise family of products are based on the LibreOffice Technology platform, the result of years of development efforts with the objective of providing a state of the art office suite not only for the desktop but also for mobile and the cloud.

Products based on LibreOffice Technology are available for major desktop operating systems (Windows, macOS, Linux and Chrome OS), mobile platforms (Android and iOS) and the cloud. They may have a different name, according to each company brand strategy, but they share the same LibreOffice unique advantages, robustness and flexibility.

Availability of LibreOffice 7.3.3 Community

LibreOffice 7.3.3 Community represents the bleeding edge in term of features for open source office suites. For users whose main objective is personal productivity and therefore prefer a release that has undergone more testing and bug fixing over the new features, The Document Foundation provides LibreOffice 7.2.6 and soon LibreOffice 7.2.7.

LibreOffice 7.3.3 change log pages are available on TDF’s wiki: https://wiki.documentfoundation.org/Releases/7.3.3/RC1 (changed in RC1) and https://wiki.documentfoundation.org/Releases/7.3.3/RC2 (changed in RC2). Over 80 bugs and regressions have been solved.

LibreOffice Technology based products for Android and iOS are listed here: https://www.libreoffice.org/download/android-and-ios/, while for App Stores and ChromeOS are listed here: https://www.libreoffice.org/download/libreoffice-from-microsoft-and-mac-app-stores/

LibreOffice individual


If you have started your journey to become an experienced developer, you already know that you have to describe what you have done when you change the code and submit it to be merged in the master branch. In git and many other source code management systems, this description is called a commit message.

The commit message has a title, and can have a detailed description. You should separate the description from the title by adding a blank line after the title.

Why it matters to write a good commit message

Some may argue that the code itself is the most important thing, and you should provide a readable clean code. This is true, and you should care most for the code. But, on the other hand, when you are working on a big project with hundreds of developers, it is also important to write descriptive commit message that is easy to read for other developers who work on the same project.

In order to be able to search and find the relevant historical information about different aspects in the code, a good way would be searching in the commit messages. You can invoke:

$ git log

You can press “/” for search, then type a search phrase. By pressing “Enter”, you will get a match, and then the next match by pressing the key “n”. This happens if matches are found.

This is only possible if you and others have previously provided good information on what each change does, providing enough details and keywords, so that others could be able to search efficiently.

If you have added your changes to the staging area of the git, then you can invoke this command to commit the changes.

$ git commit

You should provide a good title and description. Here’s how.

Information Beyond the Commit Message

Git commits also have other information, that are automatically generated. For example, the “Author” field comes from your git settings. You should use your complete first name and surname, and a valid email. Your timezone also comes from your system settings.

The Change-Id is generated when you commit, and it is used to identify a submission across different patch sets. Gerrit adds “Reviewed-on”, “Reviewed-by” and “Tested-by” fields automatically. For example, consider this commit:

Author: Miklos Vajna <vmiklos@collabora.com>
Date: Wed Apr 27 20:12:52 2022 +0200

sd theme: add PPTX import for shape fill color effects

This is always direct formatting, so FillProperties::pushToPropMap()
always has the needed info at hand.

Change-Id: I3317b618e0e8bb7688d0f0fbfe4546e2e8b4e947
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133525
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Use an informative title with 50 characters or less

You should describe what you have done in a commit in the commit title. The suggested maximum length for the commit title is 50 characters. Also, you should limit the amount of work in a single commit to only one thing. There are many reasons for that; one of them is to be able to roll back

03 May, 2022


Here’s our summary of updates, events and activities in the LibreOffice project in the last four weeks – click the links to learn more…

  • How do different free and open source software projects do mentorship, and how can we all learn from each other? Daniel Garcia Moreno (EndlessOS Foundation and GNOME), Emily Gonyer (openSUSE), Ilmari Lauhakangas (The Document Foundation), and Marie Nordin (Fedora) discuss this in a panel moderated by Ben Cotton:

Please confirm that you want to play a YouTube video. By accepting, you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

Keep in touch – follow us on Twitter, Facebook and Mastodon. Like what we do? Support our community with a donation – or join us and help to make LibreOffice even better!


Writer now has the start of content controls: a new way to set properties on a piece of text, primarily for form filling purposes. This feature improves compatibility with the DOCX format: inline content control types "rich text" and "checkbox" are the first two types we can now import.

Figure 1. Word-style inline content controls in Writer.

First, thanks to NGI DAPSI who made this work by Collabora possible.

Figure 2. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 871498


Word users expect to be able to import their document to Writer and experience a matching feature set: form filling is not an exception. Word provides several content control kinds (inline, block, row and cell content controls), this project focuses on inline ("run") content controls.

In the scope of inline content controls, the plan is to support rich text, checkbox, dropdown, picture and date content controls. This blog post presents the already implemented rich text and checkbox types.

You might wonder why content controls are useful, since Writer already has form controls and fieldmarks, which provide something similar. Here are some properties of content controls, which make them incompatible with field-based fillable forms or form controls:

  • inline content controls can’t span over multiple paragraphs, while this is allowed for fieldmarks (bookmark-based fields)

  • content controls must be well-formed XML elements, this allows nesting (while Writer fields can’t be nested), but does not allow the start/end position to be a random place in the document (while this is allowed for fieldmarks, which have separate XML elements for start and end)

  • content controls just have a set of properties, while fieldmarks are supposed to have a field command and a result (with a separator between the two)

  • content controls can contain rich text (full set of character formatting), while Writer fields can only have one character formatting (e.g. half of the field can’t be bold)


The feature consists of menu items to insert rich text or checkbox content controls, and then you can interact with the inserted content controls:

Figure 3. Menu items to insert rich text and checkbox content controls.

Rich text content controls simply show an indicator when you’re inside the content control:

Figure 4. A rich text content control.

This is similar to input fields, just allows rich text content, not limited to plain text.

Checkbox content controls contain a single character, but you can interact with them: clicking on the content control toggles the checked state of the checkbox:

Figure 5. Checkbox content controls.

And these content controls can be saved to ODT and DOCX.

How is this implemented?

If you would like to know a bit more about how this works, continue reading… :-)

As usual, the high-level problem was addressed by a series of incremental commits:

01 May, 2022


Boost your skillset and learn new things- join the Month of LibreOffice! The software is a worldwide, community open source project – and many people who help to improve it, actually started out as regular users of the software.

So in the coming four weeks, we’d love it if you get involved, join our community, and have fun. You can build up valuable skills for a future career – and you don’t need to be a programmer. There are many ways to help make LibreOffice awesome, as we’ll see in a moment.

And best of all: everyone who contributes to LibreOffice in the next four weeks can claim a cool sticker pack, and has the chance to win extra LibreOffice merchandise such as mugs, hoodies, T-shirts, rucksacks and more (we’ll choose 10 participants at random at the end):

How to take part

So, let’s get started! There are many ways you can help out – and as mentioned, you don’t need to be a developer. For instance, you can be a…

  • Handy Helper, answering questions from users on Ask LibreOffice. We’re keeping an eye on that site so if you give someone useful advice, you can claim your shiny stickers.
  • First Responder, helping to confirm new bug reports: go to our Bugzilla page and look for new bugs. If you can recreate one, add a comment like “CONFIRMED on Windows 10 and LibreOffice 7.3.2”.
  • Drum Beater, spreading the word: tell everyone about LibreOffice on Twitter or Mastodon! Just say why you love it or what you’re using it for, add the #libreoffice hashtag, and at the end of the month you can claim your stickers.
  • Globetrotter, translating the user interface: LibreOffice is available in a wide range of languages, but its interface translations need to be kept up-to-date. Or maybe you want to translate the suite to a whole new language? Get involved here.
  • Docs Doctor, writing documentation: Whether you want to update the online help or add chapters to the handbooks, here’s where to start.

We’ll be updating this page every few days with usernames across our various services, as people contribute. So dive in, get involved and help make LibreOffice better for millions of people around the world – and enjoy your sticker pack at the end as thanks from us! And who knows, maybe you’ll be lucky enough to win bonus merch as well…

Let’s go! We’ll be posting regular updates on this blog and our Mastodon and Twitter accounts over the next four weeks – stay tuned!

29 April, 2022


The LibreOffice Conference is the annual gathering of the community, our end-users, developers, and everyone interested in free office software. This year, it took place online once again.

(This is part of The Document Foundation’s Annual Report for 2021 – we’ll post the full version here soon.)

New and translated guides

Throughout the year, the documentation project closed the gap between LibreOffice major releases, and the updates of the corresponding user guides. By the year end, all of the version 7 guides updated to match the release of LibreOffice 7.2, and ready to continue for the forthcoming release – 7.3 – which arrived in February 2022. The goal of tracking the software release closely was achieved, and the documentation team is now in a steady state of small updates between releases.

The updates and enhancements of the guides was an effort of all the team, coordinated by Jean Weber (Writer and Getting Started Guide), Steve Fanning (Calc and Base guides), Peter Schofield (Impress and Draw guides), Rafael Lima (Math guide). A number of volunteers also worked in each guide by writing and reviewing contents and suggesting improvements. Special thanks to Jean Weber for making the guides available for sale in printed format via Lulu Inc.

In the last quarter of 2021, thanks to The Document Foundation’s budget, some master documents bugs were fixed under contract by Michael Stahl of allotropia, and now the documentation team can safely assemble it guides with master documents, and produce PDFs with hidden sections and correct navigation indexes in PDF readers.

ScriptForge Library and Wiki Pages

The documentation community also had a nice contribution from Jean Pierre Ledure, Alain Romedenne and Rafael Lima, for the development of the ScriptForge macro library, in synchronization with the much-needed Help pages on the subject, a practice rarely followed by junior developers of LibreOffice. As we know, undocumented software is software that’s lacking; features that are unknown to the user can be a cause of costly calls to a help desk in corporate deployments. ScriptForge developments came together with its documentation, demonstrating the ScriptForge team’s professional maturity.

Special thanks to Steve Fanning for his leadership of the Calc Functions wiki pages maintenance. The wiki pages were initially developed by Ronnie Gandhi in 2020 under the Google Season of Docs programme, and are now run by Steve, providing richer content about the functions, with better descriptions, new examples, and other reference information. The in-depth review of the Calc Function wiki pages gave very good feedback for the Help pages, which also lead to help content improvements. The Calc functions wiki pages are available for translation, thanks to the dedication of Ilmari Lauhakangas at TDF.

Very important as well: the documentation community also had a team of Help page bug fixes, closing Help documentation bugs, bridging gaps, fixing typos and improving quality, a must-have update to keep LibreOffice in-shape for its user base. The Help pages, which are part of the LibreOffice code, were also refactored continuously

26 April, 2022


LibreOffice supports many file formats, and among them are some raster and vector image formats from Microsoft. Metafile formats WMF, EMF and EMF+ are among the vector formats usable in Microsoft products, and also in LibreOffice. Here we discuss the implementation of the  support for these file formats in LibreOffice.

We call these file formats metafiles, as they are means of storing drawing commands that are calls to the Windows API that draws shapes and text on the screen. It is possible to replay these metafiles to have a graphical output in an appropriate context.

It is possible to create complex shapes using metafiles. For example, if you take a look at the odk/examples/basic/forms_and_controls folder in the LibreOffice source code, you will see some nice examples. Here is one of them: A delicious burger created using vector primitives.



The oldest metafile format is WMF, which goes back to Windows 3.1 during 1990s, but EMF and EMF+ are newer formats and support many new features.

LibreOffice can open these file formats. It is also possible to use them as the images inside another formats. For example, you can have WMF inside a DOC or DOCX file, or in native ODT format of LibreOffice.

Code Structure for Metafile Support

The emfio module of LibreOffice handles reading of the metafile records. It essentially translates these records into the mataactions. Then, vcl and drawinglayer display them. You can take a look at emfio/source/reader to see the main source files, wmfreader.cxx and emfreader.cxx in which rely on mtftools.cxx.

An important class which is used here is the GDIMetaFile class, which is described in the vcl/README.GDIMetaFile.md as:

The GDIMetaFile class reads, writes, manipulates and replays metafiles via the VCL module.

A typical use case is to initialize a new GDIMetaFile, open the actual stored metafile and read it in via GDIMetaFile::Read( aIStream ). This reads in the metafile into the GDIMetafile object – it can read in an old-style VCLMTF metafile (back in the days that Microsoft didn’t document the metafile format this was used), as well as EMF+ files – and adds them to a list (vector) of MetaActions. You can also populate your own GDIMetaFile via AddAction(), RemoveAction(), ReplaceAction(), etc.

Once the GDIMetafile object is read to be used, you can “play” the metafile, “pause” it, “wind forward” or “rewind” the metafile.

Other than reading, LibreOffice can write metafile formats as the output. For the output filter, vcl/source/filter/wmf is the place to look at.

Tools for Working with Metafile Formats

As the metafile formats are binary files, you will need tools to be able to work with these formats. We discuss three useful tools among others: mso-dumper, limerest and mtf-demo.


The mso-dumper is an in-house developed tool created and used by LibreOffice developers to dump information from the Microsoft binary formats. It reads the binary files WMF, EMF, EMF+ in addition to DOC, PPT, XLS and other

20 April, 2022


So I've been working on improving LO text layout performance, as specified by the TDF tender. As it says, text layout in LO can be rather slow, because of problems like repeated text layout calls for the same text.

Let's have a look at a perf profile for PDF export of the document from bug#116400 :

There are two major costs here:

The first one is splitting text into script runs (separating runs of e.g. latin text from RTL text). About 61% of time is spent in vcl::text::TextLayoutCache. Which is rather strange for something called 'cache'. But this is one of the cases of poor naming, as the class is actually not a cache, it is the result of the script run splitting. It is called TextLayoutCache probably because callers are supposed to cache it and pass the same item to several OutputDevice calls ... which mostly does not happen. So whenever a text is to be drawn, this gets recreated. To make things even worse, it is done for the entire string, even if only a part of it is drawn, so this supposed cache actually makes things slower.

This can be fairly easily fixed by turning the class into an actual cache. Each TextLayoutCache instance depends only on the string, so it's easy to keep a reasonable number of them in one global cache.

The second problem is breaking text into multiple lines at suitable places. In this case the problem was in the ICU library we use. The common scenario when breaking text is finding the first break and then continuing with the same text to find the following break, and so on. ICU code tries to cache this if the position in the text is close enough to the previous one, and if it's not close enough but after the last position, it tries to only walk back a bit instead of repeating the entire work from the beginning of the string. But for whatever strange reason this walking back didn't work, and it walked back until the very beginning. And the test handling the result of the walking back didn't check what the result was and reset the position to whatever the result was. So in practice the breaking almost always started from the beginning, even if the last position was a way more reasonable place to start breaking from. So 26% of time is spent breaking the same text over and over (and it's only 26% because script run splitting is even more expensive).

I've reported this to ICU together with a suggested fix to not reset position to beginning if the last position is better, they've confirmed the problem, but apparently want to look at why the walking back doesn't work in the first place, and there has not been an actual fix from them yet. So I've at least pushed my patch for now.

The resulting perf profile now

19 April, 2022


These days, many C++ projects are built using build tools like cmake and meson in addition to GNU make (gmake). In this blog, I have already written on how to compile and run LibreOffice SDK examples using gmake. Now I want to discuss instructions for compiling and running C++ examples using cmake as the build tool. For the previous instructions using gmake, see this older post:

Working with LibreOffice SDK Examples

Compiling and Running using cmake

Using Official LibreOffice Binaries and SDK

To be able to compile and run the C++ examples using cmake, you should have installed LibreOffice and LibreOffice SDK, then you should set LOROOT in CMakeLists.txt to appropriate folder. For LibreOffice 7.3 SDK, you should use this line:

set (LOROOT /opt/libreoffice7.3)

Compiling and running the C++ programs would be easy. For some of the examples, you need to run an instance of LibreOffice to listen for the incoming connections. So, you have to invoke:

$ libreoffice7.3 "--accept=socket,port=2083;urp;"

and then just open the project file in Qt Creator (or any other IDE of your choice that supports cmake), and click Build and then Run.

Local Build

If you have built LibreOffice yourself, use the instdir path for LOROOT:

set(LOROOT = /home/hossein/Projects/libreoffice/core/instdir)

If you use a local build, you may need a running instance of LibreOffice. For this purpose, invoke:

$ ./instdir/program/soffice.bin "--accept=socket,port=2083;urp;"

And execute the project from your IDE.

Building and Running from Command Line using cmake

Here I assume that the project is named example. To build and run the example from the command line using cmake, go to the source folder, and then invoke:

$ mkdir build
$ cd build
$ cmake ..
$ make
$ ./example

The CMakeLists.txt file containing the instructions for building the the example project can be as following:

cmake_minimum_required(VERSION 3.5)

project(example LANGUAGES CXX)


set(LOROOT /opt/libreoffice7.3)

add_executable(example main.cpp)


target_link_directories(example PRIVATE

execute_process(COMMAND ${LOROOT}/sdk/bin/cppumaker -Gc -O. ${LOROOT}/program/types.rdb ${LOROOT}/program/types/offapi.rdb)

Essentially, the above file specifies these:

1) Include directories: sdk/include, com/sun/star and also the source directory.

2) Library directories: sdk/lib and program.

3) Name of the linked libraries: -luno_sal -luno_cppu -luno_cppuhelpergcc3 -luno_salhelpergcc3 -lunoidllo -lxmlreaderlo -lreglo -lmergedlo

4) Using cppumaker utility to generate UNO headers from the binary description offapi.rdb. You can read more about LibreOffice SDK utilities in LibreOffice DevGuide chapter 4.

Important Environment Variables

Several environment variables are set when you use the original scripts provided by the LibreOffice SDK. When using cmake, you may have to set these environment variables:

On Linux:

export UNO_PATH=/opt/libreoffice7.3/program
export URE_BOOTSTRAP=vnd.sun.star.pathname:/opt/libreoffice7.3/program/fundamentalrc


17 April, 2022


The motivation here is Use attention-attracting cue when pressing Ctrl+F while in the find bar and do "something" to call attention to the widget. I thought I'd try some of the built-in GTK CSS support. So here we animate the widget to reduce its left and right margins inwards a little and its opacity to 50% before returning to its original properties.

Nothing is ever simple, so in order to repeat the animation (the second time ctrl+f is pressed while the widget has focus) we have to duplicate the animation and use the other copy when the previous copy was last run.

12 April, 2022



Custom Gtk Cell Renderer in GTK4 GtkComboBox in LibreOffice now working as hoped for.

11 April, 2022


Configuring tables is an every day task for word processors. Most users likely insert a table via menu or toolbar and size the columns per mouse. This usually wont result in a satisfying precision and the table properties dialog would be the next step.…


Any code submission to LibreOffice should pass Gerrit code review in order to get merged into the LibreOffice codebase. This is possible using the code review tool Gerrit.

To understand more, refer to these articles:

For getting started with LibreOffice development in general, watch this video.

Here, I assume that you have read those articles, you have created your account, and you have done your first contributions to the LibreOffice – but you want to know more about how to effectively use Gerrit. This is what I am discussing in this article.

LibreOffice Gerrit

LibreOffice Gerrit

How to Find Reviewers

If you are a newcomer, possibly I (Hossein) and Ilmari can help you. You can add us as the reviewers, and we will review your submissions. Just search for our names in front of the “Reviewers” part in your submission, and you can easily add me or Ilmari as the reviewer.

If you want to work on more complicated tasks, you can also refer to this page to find experts in different areas.

We have experts in these areas:

Access2Base, Automated tests, BASIC, Bugzilla, build system (gbuild), Calc, Chart, Database, Debian, adding dictionaries, documentation, Draw, General UI problems, git⁠ and Writer RTF filters, gerrit⁠, GUI design questions, headless (–without-x build switch), i18nlangtag, i18npool, Impress presentation, KDE, Libcdr and Corel Draw import, libvisio and Visio import, localization fixes / l10n / non-English bug description, localization fixes / l10n tools, Mac, ODF filter, Pebble, PostgreSQL integration, QA, ScriptForge, Translation, Ubuntu, UI, UNO, sal, configmgr, VCL, Weblate, Wiki, Wiki Extension, Wiki Config, Editing, Windows, Windows Installer, Writer, writerfilter, X11-specific

Quite a lot of topics!

But, as you can read in that Wiki page, please “Please do not email these developers personally with your personal pet bug”. Just add them as the CC or the reviewer of a relevant submission.

Handling Problems with the Jenkins builds

Sometimes it happens that Jenkins can not build your submission. This can happen for several reasons. It can be because of a problem in your code, or a problem with the build system itself.

If the problem is from your side, then fix the problem and re-submit your code as a new patch set, and Jenkins will try to build it again.

But, if the problem is with Jenkins, you can either ask on #tdf-infra and someone with appropriate access will resume your build. Another solution would be doing a re-base and then Jenkins will build your submission again. For doing this, you do not need any special permissions.

Please be patient, and keep in mind that CI is a limited resource, so you should use it carefully. Please note that you should build (using make) and test (using make check) on your computer locally before submitting the code to the Gerrit.

Working on Multiple Gerrit Submissions

Sometimes you want to work simultaneously on multiple submissions. Then, you have to create a branch for each of these submissions to be able to

08 April, 2022


General Activities

  1. LibreOffice 7.3.1 and 7.3.2 were released on March 3 and March 31 respectively
  2. LibreOffice 7.2.6 was released on March 10
  3. Adolfo Jayme Barrientos updated and cleaned up menu paths in Help and updated some tips of the day
  4. Seth Chaiklin improved the Help and tooltip for Reset button
  5. Alain Romedenne improved the Help page for CallByname Basic function as well as several other functions
  6. Olivier Hallot (TDF) added or updated the Help pages for several toolbars, improved the Track Changes help, updated Calc’s Tools menu help and added a page for Share Spreadsheet
  7. Rafael Lima added help ID targets for the Manage Changes dialog and improved the ScriptForge library help pages
  8. Miklos Vajna (Collabora) added a clearing breaks feature into Writer and wrote a help page for it, continued working on colour themes in OOXML documents and improved the layout XML dump developer feature.
  9. Jean-Pierre Ledure worked on the ScriptForge library
  10. Tünde Tóth (NISZ) worked on fixing the PPTX export of media files, fixed an issue with text colour in DOCX shapes and an old issue with embedded images getting multiplied upon OOXML export
  11. Paris Oplopoios made some code cleanups
  12. Sarper Akdemir (Collabora) made it so section break formatting will not leak into bullets in imported DOCX files
  13. Jürgen Funk (CIB) fixed a couple of regressions
  14. Lemures Lemniscati fixed loss of precision in MediaBox elements in exported PDFs
  15. Michael Meeks (Collabora) fixed a crash affecting collaborative editing
  16. Dennis Francis, Mert Tumer, Andras Timar and Szymon Kłos (Collabora) worked on LOKit improvements
  17. Áron Budea (Collabora) fixed a Calc crash and an issue where shapes in certain cases were missing in imported XLSX files on Windows
  18. Vasily Melenchuk (CIB) fixed an issue with cross-references and paragraph numbering and several RTF import issues
  19. Eike Rathke (Red Hat) made improvements to Calc’s evaluation of IFS() and SWITCH() functions, made DDE links from Calc to Writer more robust and made internal improvements to Calc’s text import code
  20. Bartosz Kosiorek implemented the SETARCDIRECTION EMF graphic feature
  21. David Gilbert made it so hyperlinks with user:password authentication do not get lost in PDF export
  22. Vaibhav Malik wrote his first unit test
  23. Tomaž Vajngerl (Collabora) worked on sparkline support for Calc
  24. Regina Henschel fixed shapes losing their fill after PPTX export
  25. Arnaud Versini fixed a regression in the math formula editor and made some code cleanups
  26. Julien Nabet made it so save transparency option works for PNG export, fixed an issue with creating Firebird database table views and fixed some assertion crashes. He also made many code cleanups
  27. Kunal Pawar improved starting time on Windows by removing GetCaseCorrectPathName usage
  28. zhutyra fixed a couple of security issues
  29. Jim Raykowski worked on sorting and performance improvements for the Navigator, fixed an issue with docking split toolbar buttons using a shortcut key, improved the search wrapping messaging behaviour in Writer for frames, images, and OLE objects. He also made several other improvements to the Navigator and

04 April, 2022


Writer now supports what we call clearing breaks: a new property on line breaks which controls where to put the next line in case the line break is at the end of a line which intersects with an anchored object. This feature improves compatibility with the DOCX and HTML formats.

Figure 1. Word-style "all" clearing in Writer, new result.

First, thanks to NGI DAPSI who made this work by Collabora possible.

Figure 2. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 871498


Word users expect to be able to import their documents to Writer and experience high fidelity rendering: this means Writer has to support clearing breaks, which instruct the layout to put the next line after a line break not necessarily at the next available vertical position, but perhaps the next line should "just down" to the next full line, or perhaps just do this partially. (Jump down to the next line, so no anchored object causes an additional indentation on the left or right side.)


The easiest case is the "none" clearing break, i.e. when it’s not actually clearing. This looks like this:

Figure 3. Word-style not clearing break, new result.

This is just a plain line break, and there are no changes here. It used to look like this in the past as well:

Figure 4. Word-style not clearing break, old result.

And both match the reference rendering:

Figure 5. Word-style not clearing break, reference.

Now, what’s more interesting is the "all" clearing break, when the next line is placed in a way that it’s a full line. Figure 1 already shows how it now looks like in Writer. Here is how it used to look like:

Figure 6. Word-style "all" clearing break, old result.

Finally you can compare that with the reference:

Figure 7. Word-style "all" clearing break, reference.

This is the most interesting case, and Word still provides UI to insert such breaks, so it frequently appears in documents out there. But there are two other cases, still. The "left" clearing break "jumps down", below anchored objects on the left. Here is how it looks now in Writer:

Figure 8. Word-style "left" clearing break, new result

And this is how it used to look like:

Figure 9. Word-style "left" clearing break, old result

Finally you can compare that with the reference:

Figure 10. Word-style "left" clearing break, reference

The last case is the mirror of this, when the "right" clearing break "jumps down", below anchored objects on the right. Here is how it looks now in Writer:

Figure 11. Word-style "right" clearing break, new result

And this is how it used to look like:

Figure 12. Word-style "right" clearing break, old result

Finally you can compare that with the reference:

Figure 13. Word-style "right" clearing break, reference

Other than the layout, there is also user interface for this in both LibreOffice and Collabora Online:

Figure 14. Insert

01 April, 2022


This year’s GSoC is coming; and this year, I suggest that we handle one big problem plaguing LibreOffice: deadlocks.

Users know that sometimes, program hangs. Often that is because of deadlocks. It is well known that one of industry’s most widely used ways to handle this problem is Ostrich algorithm [1].

This proposal is to audit the LibreOffice core code for possible deadlocks, and handle all the found places using the most robust and efficient implementation of Ostrich algorithm. The task includes study of available implementations; the chosen one should be efficient, robust, and available under a compatible open-source license.

Students that choose this task may assume that I would gladly mentor their work on this.

Happy hacking!

[1] https://en.wikipedia.org/wiki/Ostrich_algorithm

31 March, 2022


 So I've updated my Clang to the newly released version 14, and while doing the LibreOffice rebuild afterwards I noticed that it seemed to build faster. I didn't measure it, but the build finished sooner than I expected. So of course I've measured it.

As a simple reference I used my year-old post about Clang 11 building faster with PCH, where Calc'c Library_sc built in 4 minutes and 39 seconds. And indeed now it's faster:

 1105.84user 88.35system 2:55.07elapsed 682%CPU (0avgtext+0avgdata 1666576maxresident)k
 180904inputs+2272520outputs (41390major+23529938minor)pagefaults 0swaps

Just to make sure it's not something else, I went back to Clang 13 to test it:

 1581.76user 93.84system 4:14.75elapsed 657%CPU (0avgtext+0avgdata 1916380maxresident)k
 153912inputs+2316696outputs (41891major+27245569minor)pagefaults 0swaps

So yes, it's real, and it's the compiler. It also suggests that there was an improvement also between Clang 11 and Clang 13, although not as noticeable as this.

I have no idea why that is, it seems too big of a difference to be just something random, but I see nothing relevant in the release notes (and it's not DWARF5, I tested that one). I also have no idea if it's a code change or if it's the compiler being faster because it generates faster code and is self-built. But hey, it's nice. I still vaguely remember the times when I was trying to avoid full Calc rebuilds like a plague, but that seems like a long time ago.


We’re continually contributing improvements to the LibreOffice code-base as a member of the community (Collabora Online Forum). Here are a few highlights of the last week’s work on behalf of our customers.

“Collabora is a commercial organisation; of course we serve the needs of our paying customers, but it is a real pleasure to be able to contribute alongside the development community to LibreOffice,” said Michael Meeks, General Manager of Collabora Productivity. “It, not only, helps us offer our customers business values and benefits other companies can’t, but it provides us with an incredibly robust development and support resource.”

There’s a lot going on in the community and here are few current projects that demonstrate what people are hacking.

Enabling Calc support for 16384 columns by default

Over the last couple of weeks Luboš Luňák (Llunak) has been working for Collabora on the 16k columns support in Calc. There’s been a lot of work on this already by Noel Grandin and others, but so far this has been hidden behind the experimental option, and normally documents open only with the “normal” 1024 columns support. The goal of this work is to finish the 16k support stable enough for it to be the default, so that people who need this many columns can finally get them without any complications.

If all goes well, and so far Luboš doesn’t see why it shouldn’t, LibreOffice 7.4 will ship with 16k columns being the default. Calc users will then be able to get a lot more columns to work with.

This work is funded/sponsored by DEVxDAO as part of its mission to support Open Source and transparent research and development of emerging technologies and frameworks. Interestingly finishing this work was also a project that was proposed by to be funded by TDF, and ranked as one of the top requested features, it is great that this budget can now be re-applied to another task.

If you have ever been bitten by the “too many columns” dialog box then, why not find out more about what Luboš is working on.

Word-style border fixes in Writer: pages, tables and paragraphs

Miklos Vajna (vmiklos) has been looking at Writer and how it can better render Word-style borders around pages, tables and paragraphs.

Word users expect to able to import their documents to Writer and experience high-fidelity rendering. This means Writer has to support the way page / table / paragraph borders are painted according to the OOXML model as well. This is all done conditionally, so existing ODF documents are left unchanged.

As a result of this work, Writer now has a set of improvements to better render Word-style borders around pages, tables and paragraphs.

Thanks must go to Docmosis and TUBITAK that have made this work by Collabora possible.

Find out more and take a look at some of the improvements that have been made.

Sparklines in Calc

Sparklines are mini charts available in OOXML (XLSX) documents

25 March, 2022


Cover of LibreOffice 7.3 Getting Started GuideCover of LibreOffice 7.3 Writer GuideThe latest user guides from the LibreOffice documentation team are LibreOffice 7.3 Getting Started and LibreOffice 7.3 Writer, available in free PDF, ODT, or to read in a browser. Low-cost printed copies are available from Lulu.com.

Visit the Documentation page on the LibreOffice website for links.

24 March, 2022


One of the trending UX features right now is dark mode. According to one study, 58% of Americans experience digital eye strain from using computers. One of the factors causing it is blue light radiation from the screen. That's where the possible idea of ​​a screen that slows down your tired eyes more comes from.

Windows, as one of the biggest consumer desktop platforms, does not escape the dark mode feature. Since Windows 10, dark mode can be enjoyed by its users. Unfortunately, LibreOffice which is on the GNU/Linux platform has remarkable stand at following this trend thanks to its ability to blend in with system themes which has been a bitter pill to swallow over the past few years.

Let's say huge thanks to Caolán McNamara, one of the LibreOffice developers from Redhat who is usually on the UX/UI side of improving LibreOffice integration with GTK, for sending a patch so that LibreOffice for Windows can now enjoy dark mode.

Actually, this article wants to discuss the presence of the dark variant of the Colibre icon theme, but somehow after I sent the dark variant of the Colibre theme patch to the core, Caolán actually fulfilled the expectations of many years later.

Basically, apart from following the interface of the system in which it is installed, LibreOffice supports custom themes via Firefox personas, but unfortunately not all parts of the interface are changed with this Firefox persona. Only the standard toolbar can be themed, while the sidebar let alone the tabbed UI are completely untouched.

Half-hearted theme:

It getting worse with Tabbed UI:

Initially I wanted to make this Colibre variant dark icon theme as a trigger so that the dark mode in Windows is immediately materialized. It turned out that not long after that my wish was granted. To enable it, first thing first you must enable dark mode in OS level, then in LibreOffice, enable experimental features in Tools > Options > LibreOffice > Advanced. Check "Enable experimental feature (may be unstable)". LibreOffice will ask for restart and then automatically switch the UI to dark mode along with Colibre dark icon after restart.

Here is what dark mode looks like on my Windows 11.

The Start Center looks very promising, the title bar got dark also.