Nine more videos from the LibreOffice Conference 2021

Here are some more videos from the LibreOffice Conference 2021! Check out the playlist, using the button in the top-right – or scroll down for links to individual videos:

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.

Individual links

Note: many of these are also available on PeerTube, and more will be added…

There are just a few videos remaining – we’ll post them very soon!

LibreOffice extension to remove blank cells – Help to improve it!

Rafael Lima from the Brazilian LibreOffice community is working on an extension to remove blank cells in LibreOffice Calc. It has four modes (single column, single row, blank rows and blank columns). Here’s a quick animation of it in action:

So far, the main functionality is there, but Rafael would like to improve it. We asked him for some more info…

What does the extension do?

The main purpose of this extension is to remove blank cells to easily compact data. For instance, suppose you have a table with data and then you delete the contents of some rows. The next thing you might want to do is remove these blank rows to compact your table. By using the Remove Blank Cells extension this can be done with a single click.

Currently the extension supports four modes to remove blank cells. The simplest one is when you select a single row or column, then the extension will detect the selection and compact the data removing all blank cells. However, if a matrix is selected, then a message will be displayed and you can choose if blank rows or blank columns are to be removed.

When did you start making it?

I started writing the extension in February this year and finished the first version in less than one month. Then I kept testing it and working on improvements and the final version was finished in July.

At first the extension focused on my use case, because in my work with data analysis I often have to remove blank rows and columns. However, after seeing many people asking about how to remove blank cells in LibreOffice, I decided to pack it and make it available for everyone since it might be useful for other people.

What are the current limitations of it?

The main limitation of the extension is when the user wants to process very large tables (with tens of thousands of rows), which might take some time to finish. In these cases a progress bar is shown so the user can keep track of the data processing.

Moreover, the extension still does not support translations, so the user interface is only available in English. I plan to support translations in the next release.

How can people help to improve it?

Because this is the first released version of the extension, I would appreciate having more people testing it and reporting issues on the extension’s GitHub page.

I would also like to invite the community to create a better icon for the extension, so that it would be more in line with the default icon theme in LibreOffice.

In the future I will also need some assistance with translating the extension’s strings.

So, everyone is welcome to try out the extension – and if you have some technical knowledge, jump in and help Rafael and the community to improve it! Check out the wiki for more information on extension development.

Ten more videos from the LibreOffice Conference 2021

Here are some more videos from the LibreOffice Conference 2021! Check out the playlist, using the button in the top-right – or scroll down for links to individual videos:

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.

Individual links

Note: many of these are also available on PeerTube, and more will be added…

Stay tuned for more videos from rooms 2 and 3 of the conference!

LibreOffice and Google Summer of Code 2021: The results

Google Summer of Code logo

This year, LibreOffice was once again a mentoring organization in the Google Summer of Code (GSoC), a global program focused on bringing more student developers into free and open source software development. Seven projects were finished successfully. Students and mentors enjoyed the time, and here we present some of the achievements, which should make their way into LibreOffice 7.3 in early February 2022!

You can experiment with the new features by using daily builds and report any problems in our bug tracker.


100 Paper Cuts by Bayram Çiçek

Mentors: Muhammet Kara (Collabora), Heiko Tietze (TDF)

100 Paper Cuts aims to improve user interface, implementing enhancement requests and solving the most annoying issues on the user experience (UX) side of LibreOffice.

Bayram fixed six bugs from different topics. Most notable are border preview not showing the diagonal border option, a bug where cropping flipped images occurred at the wrong side, and mouse-over effect for different palettes in the area tab.

Learn more about 100 Paper Cuts in the final report.

Screenshot of diagonal borders


Integrate .ui dialogs with translation tooling/string search webservice to help translators by Sary Nasser

Mentors: Christian Lohmaier, Olivier Hallot (TDF)

Sary automated the adding of screenshots to our translation platform, Weblate, while associating them with translatable words. This will greatly help translators by providing context for their work.

Learn more about the translation tooling in the final report.


Tests for the VCL graphic backends by Akshit Kushwaha

Mentors: Tomaž Vajngerl, Luboš Luňák (Collabora)

LibreOffice adapts its user interface to different operating systems with the help of its graphics toolkit Visual Class Library (VCL). Thanks to Akshit’s work, we have a working suite of automated graphics rendering tests. There is now also the ability for users to run the tests manually, inspect the results and attach them to our bug tracker in case there is a problem.

Learn more about the tests in the final report.

Screenshot of VCL tests


Improving table styles by Balázs Sántha

Mentors: László Németh (independent), Michael Stahl (allotropia)

This project resulted in fixes for the most annoying Writer table style issues. Further work is needed to provide full DOCX compatibility.

Learn more about DOCX tables styles in the final report.


Make SVM (StarView Metafile) format independent of the VCL Metafile + tests of the format by Panos Korovesis

Mentors: Tomaž Vajngerl, Miklos Vajna (Collabora)

Thanks to the work of Panos, the SVM file format is handled independently of internal VCL constructs, which will make important reorganisation of the VCL code possible. Panos also created automated tests for the SVM format.

Learn more about the SVM project in the final report.


Show text styles together in the sidebar by Anshu Khare

Mentors: Mike Kaganski, Tomaž Vajngerl (Collabora), Heiko Tietze (TDF)

Both paragraph as well as character styles are essential means to format text. Many users struggle with this concept and use direct formatting. Also, we don’t show both at once, and the two style families are not obvious to spot for casual users.

In order to improve the handling of styles (and as necessary preparation for the styles highlighter), Anshu started to rework the code. The new code makes it now possible to merge both lists into one view. A first patch was also part of the project – although it is not finished yet.


Implement Interface for external data source import into Calc by Tushar Kumar Rai

Mentors: Markus Mohrhard (independent), Heiko Tietze (TDF)

The data provider allows to import various data such as local CSV files or streams from external sources, and to apply transformations like adding/removing rows or columns, formatting and numerical operations with the data before it is inserted into the sheet. Plus, to update the data by still applying the transformations is just a click.

The project aimed to rework the user interface. Tushar organized the layout according the user workflow and common UI principles and made the workflow of adding/removing transformations easy to understand. He also added a couple of transformations.

Learn more about the data provider project in the final report.

Screenshot of Data Provider


Wrapping up

Many thanks to all students who spent their summer time improving LibreOffice. You are awesome! And special thanks also to the mentors who always put so much love and energy into these tasks. That’s what makes LibreOffice rock.

Now we are looking forward to next year’s GSoC. If you are interested, why not prepare early? Learn more at out wiki page where some ideas are listed.

Participating in GSoC is a great way to build your skills, and show future employers what you’re capable of!

Next batch of videos from the LibreOffice Conference 2021

Here are some more videos from the LibreOffice Conference 2021! Check out the playlist, using the button in the top-right – or scroll down for links to individual videos:

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.

Individual links

Note: many of these are also available on PeerTube, and more will be added…

Stay tuned for more videos from rooms 2 and 3 of the conference!

Tender to implement C++ accessibility tests (#202110-01)

The Document Foundation (TDF) is the charitable entity behind the world’s leading free/libre open source (FLOSS) office suite LibreOffice.

We are looking for an individual or company to implement C++ accessibility tests.

The work has to be developed on LibreOffice master, so that it will be released in the next major version.

The current accessibility tests are rather incomplete and hard to maintain. Additionally, they are written in Java.

The scope of this tender is to convert them into in-process cppunit-based tests and create a solid foundation in both code as well as documentation to facilitate extending the coverage both as part of this tender as well as for follow-up contributions. TDF aims to prepare a good infrastructure and documentation, so that adding further tests is much simpler in the future, even for new kinds of widgets, up to a point where they could be implemented as part of our EasyHacks. The implementation therefore has to be solid and thorough to support future test cases easily.

We recommend the following steps to approach the tender deliverable:

  • assessing the technical requirements (both using the existing tests to convert, plus the various requirements of a11y in general)
  • assessing the current status
  • designing and creating the new required interfaces, or adapting or augmenting existing ones
  • creating helpers to ease writing tests
  • writing some tests to both serve as examples and proof of concept (at least a couple for each key aspect of testing, but exercising the infrastructure to validate it is key to having something that has a chance of withstanding the test of time)
  • extensive documentation on all those, plus how to write tests and such
  • peer review

Therefore, this tender should provide the infrastructure to:

  • Test the interfaces (AT-SPI, UIA, MSAA, etc.) allowing accessibility tools (ATs) such as e.g. screen readers, magnifier glasses, etc. to access the information required to perform their tasks. This requires testing the LibreOffice implementation of the AT interfaces themselves to catch issues at the outer edge. It is crucial because even if all is well working inside LibreOffice itself, but the information is not properly sent to the platform, it still won’t work for users. Also, it probably has to be done for each platform separately (Desktop Linux (AT-SPI2), Windows (UIA, MSAA), macOS etc.) as their APIs are different, even if often similar, and have separate modules in LibreOffice.
  • Test that there is enough information sent through those interfaces and that it is accurate and usable. This could rely on internal unified interfaces to fetch information and interact with the UI, but there still is a fair bit of diversity on what needs to be tested.
  • Test that functionalities are usable with different type of input (e.g. work with the keyboard, as it’s the most common offender). Also this could rely on internal unified interfaces to fetch information and interact with the UI, but there still is a fair bit of diversity on what needs to be tested.

A key item of the deliverables for this tender is the extensive documentation (in addition to the source-code documentation) that will allow to both maintain the converted tests as well as create additional tests. The documentation shall include (but is not limited to) common pitfalls with accessibility related tests (like timeouts/waiting for events/deal with load dependent/parallelism differences) and how to deal with them. The documentation could walk the developer through the process behind the creation of newly created tests, showcasing both the obvious and not-so-obvious hurdles with that specific tests/a11y related tests in general and how they were dealt with. Aiming for an extendable framework, this likely requires creating new interfaces for missing functionality for reuse in tests.

We expect bidders to provide information on both the code and the non-code parts of this tender, e.g. methodology, structure and technical aspects. The Document Foundation will publish this under a free and open source license and make it available to the general public.

Required skills

  • Extensive knowledge of C++
  • Experience working on the LibreOffice source code

Other skills

  • English (conversationally fluent in order to coordinate and plan with members of TDF)

We use free, libre and open source (FLOSS) software for development wherever possible, and the resulting work must be licensed under the Mozilla Public License v2.0.

TDF welcomes applications from all suitably qualified persons regardless of their race, sex, disability, religion/belief, sexual orientation or age.

Bidders will get a preference for including a partner or independent developer who has not been involved in a successful tender before.

As always, TDF will give some preference to individuals who have previously shown a commitment to TDF, including but not limited to certified developers and/or members of TDF. Not being a member, or never having contributed before, does not exclude any applicants from consideration.

The task offered is a project-based one-off, with no immediate plans to a mid- or long-term contractual relationship. It is offered on a freelance, project basis. Individuals and companies applying can be located anywhere in the world.

When budgeting, we anticipated that this project (all items combined) to take in the region of 30 days of work. Should bidders’ assessment result in a significantly different number, please reach out to us before sending your bid, so we can clarify upfront.

TDF is looking forward to receiving your applications for one or more of the aforementioned tasks, your financial expectations and the earliest date of your availability, via e-mail to a committee at tender20211001@documentfoundation.org no later than November 26, 2021.

Applicants who have not received feedback by December 23, 2021 should consider that their application, after careful review, was not accepted.

All bidders are invited to ask their questions on this tender until November 19, 2021. Questions and answers will be made public in a collected and anonymized form.