Caolán McNamara
LibreOffice Dev Blog
LibreOffice QA Blog
Marius Popa Adrian
Michael Meeks
Miklos Vajna
Official TDF Blog
Last updated:
July 03, 2022 12:01 AM
All times are UTC.
Powered by:
Imprint
Privacy Policy
by Popa Adrian Marius (noreply@blogger.com) at July 01, 2022 02:57 PM
Today we’re talking to রিং/ring (S R Joardar) from Bangladesh, who’s helping to spread the word about Free Software (as in freedom) – including LibreOffice – in his country…
I am a GNU/Linux user, lover, translator and supporter since 2000, and a sysadmin since 2003 using Red Hat 5.0, later Fedora and RHEL. I am using Ubuntu in personal computers since December 2006. Canonical sent me a zero-priced gift pack of 10 CDs with Ubuntu 6.10 back then. I have started deployment of Ubuntu servers with Ubuntu 8.04 manual installations in 2009, and just provisioned a few instances with 22.04 on Linode and Digital Ocean. In the years 2009-2017, I personally made over 6,000 new desktop or laptop installations with Ubuntu and LinuxMint.
I am from Dhaka, Bangladesh. In 2011, I along with 21 more Free software enthusiasts formed an organization titled “FOSS Bangladesh (Foundation for Open Source Solutions Bangladesh)” and started with official tour to the Universities here in Bangladesh. Up to December 2019, FOSS Bangladesh had organized 75 events in various universities and colleges and schools to spread out the digital freedom knowledge among the pupils, the future leaders. I have invited Mr. Richard M. Stallman came in Dhaka, Bangladesh at Daffodil International University for a session in 2014 and he agreed to my request and visited. I am also a Mozillian (Mozilla Firefox and Thunderbird Fan, User and Supporter and end user support volunteer). At present I am working as the General Secretary of FOSS Bangladesh.
I am an IT Freelancer, working on PPH and Freelancer. I love to cook food and play cricket besides my computing and voluntary support to spread Free Software knowledge. 
In 2011, FOSS Bangladesh ran an online survey to gather approximate user data about GNU/Linux users, with the help of various online local language forums sites here in Bangladesh. Back then, it was around 9,000 people. As per my statistical knowledge nowadays, the pupils I had served with installations and had met by 2017 became professionals, and GNU/Linux users is now more than 100 times of that 15,000 count.
The obstacles to adoption of GNU/Linux and LibreOffice in here in Bangladesh is the lack of law bindings regarding software piracy. So far, can obtain a pirated copy of Windows 10 with Microsoft Office, and many more and get used to that closed, bind and blinded ecosystem. So when it comes to the professional workplace, most people got bound into that closed software ecosystem. They do not think that they are stealing – and on the piracy index globally, they make Bangladesh ashamed. Government offices here also go alike with the closed software ecosystem.
But the scenario is changing day to day. Those who once got the chance to get out of that closed system embracing the GNU/Linux ecosystem or the Free Software getting hold for his/her lifetime. They also spreads the enjoyment of Freedom to their surroundings.
Spreading the knowledge of Free Software and Digital Freedom is a must. Only sharing and caring, and contributing to the Freedom Ecosystem, can make that happen in the future. But the COVID-19 pandemic affected local events ing FOSS Bangladesh since 2020. We hope to start with a new run soon, by November 2022.
Translation and helping others to use LibreOffice can help grow the community in Bangladesh more quickly. Since 2010, I have transformed three industries in Bangladesh from Microsoft Windows to Ubuntu, and then LibreOffice came along. To this date, date they are using Ubuntu 20.04 or Linux Mint 20.3 with LibreOffice 7.3.2. I have to install, train end users to get into the ecosystem, and provide day-to-day user support. Around 500 users are migrated and get evolved in this Free Software ecosystem, and using it in the professional arena. I can recall 15,000 valid contacts, but the real count is many more than that.
In Bangladesh, I know that there are there are more private companies running only on Free software.
We have already have setup a Telegram group – join it here.
Many thanks to Ring and all members of the Bangladesh community for their work and support!
Here’s our summary of updates, events and activities in the LibreOffice project in the last four weeks – click the links to learn more…
In 2019, the German LibreOffice community unfortunately lost one of its most active members, Klaus-Jürgen Weghorn. In his memory, The Document Foundation decided to support a student through the Deutschlandstipendium initiative.
Let’s get to know him…
I come from near Lüneburg. I graduated from the Wilhelm-Raabe-Schule Gymnasium in Lüneburg last year.
I have quite a wide range of interests, which certainly contributed to my Abitur [qualification at the end of secondary education] average of 1.0 and did not make my decision to study any easier. However, my main focus is certainly in the mathematical/scientific/technical subjects.
I like to ride my road bike and go cycling in general, and I like to travel, gladly combining both interests together.
I am currently studying computer science in my second semester. The course is interesting and I like the challenge. However, I have found out that the course is not quite right for me. Therefore, I would like to change to business informatics for the coming winter semester, for which I am currently already taking the appropriate modules. I am impressed by what I have already learned in a comparatively short time during my studies. Apart from that, I have been able to maintain my Abitur during my studies.
I have already used free and open source software, for example the Linux distribution Ubuntu as part of my studies, or Eclipse even before my studies. However, I have not yet participated in such a project myself.
Apart from the questions, I would also like to thank you again for the support and recognition of my achievements.
You’re welcome, Julian! We wish you every success in your studies.
by Popa Adrian Marius (noreply@blogger.com) at June 22, 2022 07:09 PM
The LibreOffice Quality Assurance ( QA ) Team is happy to announce LibreOffice 7.4 Beta1 is available for testing!
LibreOffice 7.4 will be released as final in mid August, 2022 ( Check the Release Plan for more information ) being LibreOffice 7.4 Beta1 the second pre-release since the development of version 7.4 started at the end of November, 2021. Since the previous release, LibreOffice 7.4 Alpha1, 920 commits have been submitted to the code repository and 220 issues got fixed. Check the release notes to find the new features included in this version of LibreOffice.
LibreOffice 7.4 Beta1 can be downloaded from here for Linux, macOS and Windows, and it can be installed alongside the standard version.
In case you find any problem in this pre-release, please report it in Bugzilla ( You just need a legit email account in order to create a new account ).
For help, you can contact the QA Team directly in the QA IRC channel or via Telegram.
LibreOffice is a volunteer-driven community project and your help is much appreciated.
Happy testing!!
…
Berlin, June 9, 2022 – LibreOffice 7.3.4 Community, the fourth 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/.
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.4 Community
LibreOffice 7.3.4 Community is the best office suite for personal productivity. With the LibreOffice 7.2 family approaching the end of life, all users are invited to upgrade to this version as soon as possible.
LibreOffice 7.3.4 change log pages are available on TDF’s wiki: https://wiki.documentfoundation.org/Releases/7.3.4/RC1 (changed in RC1) and https://wiki.documentfoundation.org/Releases/7.3.4/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 users are assisted by a global community of volunteers: https://www.libreoffice.org/get-help/community-support/. On the website and the wiki there are guides, manuals, tutorials and HowTos. Donations help the project to make all of these resources available.
LibreOffice users are invited to join the community at https://ask.libreoffice.org, where they can get and provide user-to-user support. People willing to contribute their time and professional skills to the project can visit the dedicated website at https://whatcanidoforlibreoffice.org
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.3.4 is built with document conversion libraries from the Document Liberation Project: https://www.documentliberation.org
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
524 bugs, 53 of which are enhancements, have been reported by 269 people.
Top 10 Reporters
662 bugs have been triaged by 83 people.
Top 10 Triagers
607 bugs have been set to RESOLVED.
Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
210 bugs have been fixed by 43 people.
Top 10 Fixers
List of critical bugs fixed
List of high severity bugs fixed
List of crashes fixed
List of performance issues fixed
List of old bugs ( more than 4 years old ) fixed
144 bugs have been retested by 44 people.
Top 10 testers
110 bugs have been duplicated by 37 people.
Top 10 testers
80 bugs have been verified by 24 people.
Top 10 Verifiers
360 bugs have been categorized with a metabug by 30 people.
Top 10 Categorizers
At the start of May, we revved up a new Month of LibreOffice, celebrating community contributions all across the project. We do these every six months – so how many people got sticker packs this time? Check it out…
Awesome work, everyone! Hundreds of people, all across the globe, have helped out in our projects and communities. We’re hugely thankful for your contributions – and, of course, everyone who’s listed on the wiki page can get a sticker pack, with these stickers and more:
If you see your name (or username) on this page, get in touch! Email mike.saunders@documentfoundation.org with your name (or username) from the wiki page so that we can check, along with your postal address, and we’ll send you a bunch of stickers for your PC, laptop and other kit.
(Note: your address will only be used to post the stickers, and will be deleted immediately afterwards.) If you contributed to the project in November but you’re not on the wiki page, please let us know what you did, so that we can add you!
And we have an extra bonus: 10 contributors have also been selected at random to get an extra piece of merchandise – a LibreOffice hoodie, T-shirt, rucksack or snazzy glass mug. Here are the winners – we’ll get in touch personally with the details:
Writer already had rich text and checkbox content controls: a new way to set properties on a piece of text, primarily for form filling purposes. This feature now gained 3 additional types: dropdown, picture and date picker types. This improves compatibility with the DOCX format: there are now 5 inline content control types we can now import.
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 above linked blog post already described the rich text and checkbox types. In this post, we’ll focus on the new dropdown, picture and date content controls.
You might wonder why content controls are useful, since Writer already has form controls and fieldmarks, which provide something similar. Here are some benefits:
Dropdown content controls have a list of dropdown items. Each item is a display-text and value pair, allowing to differentiate between a human-readable string and a machine-readable value. Fieldmarks only handled (machine-readable) values, resulting in document text different from Word.
Picture content controls allow the author of a form to pre-format the image before the filler of the form inserts the actual image. Writer already had placeholder fields for images in the past, but that was just text, allowing image format only after insertion of the actual image.
Date content controls were emulated with Writer fieldmarks in the past, which created trouble during export, since Word itself doesn’t have a date form-field.
The feature consists of menu items to insert dropdown/picture/date content controls, and then you can interact with the inserted content controls or with their properties:
Drop-down content controls show a dropdown button when you’re inside the content control:
This is similar to dropdown fields, just allows display-text and value pairs, not limited to just values.
Picture content controls contain a single as-character image, but you can interact with them: clicking on the content control opens the file open dialog to provide a replacement for the placeholder:
And these content controls can be saved to ODT and DOCX.
There is also a content control properties dialog, which allows setting if the content controls are in placeholder mode or not:
It has additional widgets for dropdowns. There is UI to create, update or delete these list items:
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:
https://gerrit.libreoffice.org/c/core/+/133742 sw content controls, drop-down: add doc model & UNO API
https://gerrit.libreoffice.org/c/core/+/133801 sw content controls: enable indicator on the RHS of the content control end
https://gerrit.libreoffice.org/c/core/+/133874 sw content controls, drop-down: show list items on click
https://gerrit.libreoffice.org/c/core/+/133915 sw content controls, drop-down: select list item on click
https://gerrit.libreoffice.org/c/core/+/134034 sw content controls, drop-down: add ODT filter
https://gerrit.libreoffice.org/c/core/+/134041 sw content controls: only try to insert placeholders if there is no selection
https://gerrit.libreoffice.org/c/core/+/134104 sw content controls, drop-down: add DOCX export
https://gerrit.libreoffice.org/c/core/+/134143 sw content controls, drop-down: add DOCX import
https://gerrit.libreoffice.org/c/core/+/134151 sw content controls: introduce a word breaking dummy char at the end
https://gerrit.libreoffice.org/c/core/+/134215 sw content controls, dropdown: add insert UI
https://gerrit.libreoffice.org/c/core/+/134239 sw content controls: fixes for the ending dummy char
https://gerrit.libreoffice.org/c/core/+/134256 sw content controls, dropdown: add LOK API
https://gerrit.libreoffice.org/c/core/+/134278 sw content controls, dropdown: add an initial properties dialog
https://gerrit.libreoffice.org/c/core/+/134379 sw content controls, dropdown: edit list items in the properties dialog
https://gerrit.libreoffice.org/c/core/+/134405 sw content controls, dropdown: edit list items: add modify and delete
https://gerrit.libreoffice.org/c/core/+/134457 sw content controls, picture: add doc model & UNO API
https://gerrit.libreoffice.org/c/core/+/134511 sw content controls, picture: replace placeholder image on click
https://gerrit.libreoffice.org/c/core/+/134538 sw content controls, dropdown: disable NOP buttons in the property dialog
https://gerrit.libreoffice.org/c/core/+/134595 sw content controls, picture: add ODT filter
https://gerrit.libreoffice.org/c/core/+/134657 sw content controls, picture: add DOCX filter
https://gerrit.libreoffice.org/c/core/+/134681 sw content controls, picture: add insert UI
https://gerrit.libreoffice.org/c/core/+/134750 sw content controls, picture: add LOK API
https://gerrit.libreoffice.org/c/core/+/134847 sw content controls, date: add doc model & UNO API
https://gerrit.libreoffice.org/c/core/+/134926 sw content controls, date: show a date picker on click
https://gerrit.libreoffice.org/c/core/+/134977 sw content controls, date: add ODT filter
https://gerrit.libreoffice.org/c/core/+/135022 sw content controls, picture: add LOK API testcase
https://gerrit.libreoffice.org/c/core/+/135033 sw content controls, date: add DOCX export
https://gerrit.libreoffice.org/c/core/+/135035 sw content controls, date: add current date handling
https://gerrit.libreoffice.org/c/core/+/135039 sw content controls, date: preserve more properties
https://gerrit.libreoffice.org/c/core/+/135109 sw content controls, date: add DOCX import
https://gerrit.libreoffice.org/c/core/+/135153 sw content controls, date: add insert UI
https://gerrit.libreoffice.org/c/core/+/135214 sw content controls, date: add LOK API
To make this more interesting, Rashesh Padia of Collabora continued exposing this in Collabora Online, see the PR at https://github.com/CollaboraOnline/online/pull/4803.
You can get a snapshot / demo of Collabora Office 22.05 and try it out yourself right now: try unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF’s next release too (7.4).
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 Review bot, which is one of the QA (Quality Assurance) tools for the LibreOffice QA team to manage old submissions.
You may have received messages from some bots, including Review 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:
Abandoned
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.
You can find more information about
Also, you can read this previous post on how to use Gerrit code review.
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.
Except then, GetColumnsRange() clamping to allocated columns becomes incorrect, because now it's possible to have set data even beyond allocated columns, such as this bold flag. So I changed GetColumnsRange() to simply return the given range, without any adjustments, and then added the better-named GetAllocatedColumnsRange() for cases where the code knows it wants only the allocated range.
Somewhat similarly to the bold case, merely showing or going to an unallocated column should not allocate it. Otherwise hit e.g. Ctrl+Right one time too many and the cursor going to column XFD would make all columns get allocated. But that causes yet another complication - I am now at an unallocated column and all operations should either detect the column is not allocated and return, or allocate the column if needed. The initial 16k work added CreateColumnIfNotExists() exactly to protect such accesses and allocate the column if needed. It's just that this needed adding to quite many places, and some were still missing it, and others were calling it unnecessarily causing unnecessary column allocations. So I needed to work on these over time. I eventually went as far as change Calc to initially allocate just one column. Since before that Calc used to allocate 64 columns by default, a number of places missing such checks kept working because normally people didn't work with more than 64 columns (and so this 64 default was a reasonable choice at the time, as there was really a lot to check and fix). Now that I have changed this to just one column and fixed all tests, it looks like I've rooted them all out (at least I'm still getting only very few bugreports about something breaking :) ).
Drawing, somewhat unexpectedly, turned out to be a possible performance problem too. There are few ways in which cells to the left can affect drawing of cells to the right. If you enter a too-long text into a cell, it will overflow to the right, into the space of the next cell, or possibly even several cells. So when Calc is drawing let's say a couple of cells around the 10000th column, it actually needs to check also all the 10000 columns before. Somebody back in the day thought about optimizing it, and so before Calc draws cells, function FillInfo() first collects information about all the cells to draw and also all the cells to the left. What possibly(?) was an optimization with 256 or 1024 column is a problem with 16384 columns. Even allocating and clearing all the memory actually had a noticeable performance impact. Sadly, as sometimes happens to be the case with optimizations from the OpenOffice.org times, whoever wrote this made it slow. Function FillInfo() collects all data necessary for drawing a cell into struct CellInfo, and all that info is collected also for all the cells to the left, even though most of it is not used for them. So I had to find out what was necessary and split that out (and provide proper abstraction, because real programmers back in the day used direct data access, right).
I expect the real test of this comes when it becomes part of the LibreOffice 7.4 release or Collabora Online. But so far it seems to work rather well.
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.
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
552 bugs, 58 of which are enhancements, have been reported by 279 people.
Top 10 Reporters
563 bugs have been triaged by 65 people.
Top 10 Triagers
475 bugs have been set to RESOLVED.
Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
167 bugs have been fixed by 34 people.
Top 10 Fixers
List of high severity bugs fixed
List of crashes fixed
List of performance issues fixed
List of old bugs ( more than 4 years old ) fixed
67 bugs have been retested by 31 people.
Top 10 testers
112 bugs have been duplicated by 32 people.
Top 10 testers
54 bugs have been verified by 20 people.
Top 10 Verifiers
315 bugs have …
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.
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.
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>
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 your changes with a single git revert.
For LibreOffice commits, you should provide the issue id at the first of the title. For example, tdf#xyz refers to the bug number xyz in the Bubzilla:
Another abbreviation, cid#xyz refers to the Coverity scan report number xyz:
For other abbreviations, please refer to this Wiki article:
You can refer to the module with its abbreviation (sw, sc, etc.) to emphasize the module that the patch is related to. Here is an overview of the modules of LibreOffice.
It is important to keep the title short, because other people can get the whole idea of the change that you have done at a glance. You can see the list of recent changes in this page:
Also, you can pull the latest changes, and use information from git locally, using these commands:
$ ./g pull -r $ git log --oneline --since=1week
The above command lists the title of commits from the previous week.
Beyond the title, you should provide detailed description of what you have done in the current commit. You can link to other commits with the commit hash if needed.
Using lists with *, +, – or characters like that can help to provide a better formatting for the texts. For example, consider this commit:
Author: Miklos Vajna <vmiklos@collabora.com> Date: Thu Apr 21 09:08:03 2022 +0200 sw content controls: add insert UI - add an SwWrtShell::InsertContentControl() to put the current selection into a content control - if there is no selection, add a non-empty placeholder - expose this as a new .uno:InsertContentControl uno command - add this new command to the bottom of the form menu -- probably we can have a sub-menu there once there will be more types
Various details are provided as a list. The syntax is mostly similar to the Markdown. Some people argue that the width of the lines should be limited to 72 characters, but there is no consensus on the exact maximum width for line wrapping.
Include relevant information that can help other developers, including but not limited to:
It all depends on you, but please describe what you are doing! Remember that what you write will be read in the future by the others, thus it should describe the changes that you have done in the commit.
Writing a paragraph is the minimum thing that is expected, so the suggestion is that you avoid submitting patches with blank description.
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.
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:
Rich text content controls simply show an indicator when you’re inside the 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:
And these content controls can be saved to ODT and DOCX.
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:
https://gerrit.libreoffice.org/c/core/+/132291 sw content controls: add document model
https://gerrit.libreoffice.org/c/core/+/132350 sw content controls: add UNO API to insert this
https://gerrit.libreoffice.org/c/core/+/132404 sw content controls: add UNO API to insert this with custom props
https://gerrit.libreoffice.org/c/core/+/132491 sw content controls: include this in the UNO API text portion enum
https://gerrit.libreoffice.org/c/core/+/132556 sw content controls: add initial layout support
https://gerrit.libreoffice.org/c/core/+/132618 sw content controls: add overlay to render a border around the text portions
https://gerrit.libreoffice.org/c/core/+/132652 sw content controls: select the content on click when showing placeholder
https://gerrit.libreoffice.org/c/core/+/132717 sw content controls: add ODT export
https://gerrit.libreoffice.org/c/core/+/132804 sw content controls: add ODT import
https://gerrit.libreoffice.org/c/core/+/132875 sw content controls: add initial DOCX export
https://gerrit.libreoffice.org/c/core/+/132944 sw content controls, DOCX export: handle SDT end at para end
https://gerrit.libreoffice.org/c/core/+/133195 sw content controls: add initial DOCX import
https://gerrit.libreoffice.org/c/core/+/133241 sw content controls: add insert UI
https://gerrit.libreoffice.org/c/core/+/133314 sw content controls: add LOK API
https://gerrit.libreoffice.org/c/core/+/133363 sw content controls, checkbox: add document model & UNO API
https://gerrit.libreoffice.org/c/core/+/133424 sw content controls, checkbox: toggle the checkbox on click
https://gerrit.libreoffice.org/c/core/+/133467 sw content controls, checkbox: add ODT filter
https://gerrit.libreoffice.org/c/core/+/133532 sw content controls, checkbox: add DOCX export
https://gerrit.libreoffice.org/c/core/+/133588 sw content controls, checkbox: add DOCX import
https://gerrit.libreoffice.org/c/core/+/133685 sw content controls, checkbox: add insert UI
To make this even more interesting, Rashesh Padia of Collabora started exposing this in Collabora Online, see the PR at https://github.com/CollaboraOnline/online/pull/4703.
You can get a snapshot / demo of Collabora Office 2022 and try it out yourself right now: try unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF’s next release too (7.4).
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.
berger.wmf
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.
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
GDIMetaFileclass reads, writes, manipulates and replays metafiles via theVCLmodule.A typical use case is to initialize a new
GDIMetaFile, open the actual stored metafile and read it in viaGDIMetaFile::Read( aIStream ). This reads in the metafile into theGDIMetafileobject – it can read in an old-styleVCLMTFmetafile (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) ofMetaActions. You can also populate your ownGDIMetaFileviaAddAction(),RemoveAction(),ReplaceAction(), etc.Once the
GDIMetafileobject 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.
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 Microsoft formats, and dumps it as xml.
To be able to dump a metafile, you should do this:
$ git clone https://git.libreoffice.org/mso-dumper $ cd mso-dumper $ ./wmf-dump.py burger.wmf $ ./emf-dump.py computer_mail.emf
Please note that the burger.wmf and computer_mail.emf files are available inside the LibreOffice source. You should replace the burger.wmf and computer_mail.emf with the path of the file you want to dump its structure.
Re-lab provides this tool which had the former name of OLEToy. It is a graphical tool that is suitable for understanding the binary file formats including the metafiles, and investigating the contents of the sample binary files. In addition to the visual display of records and their contents, it has a nice hex viewer that is very handy when debugging binary formats.
You can download this tool from here:
https://gitlab.com/re-lab-project/limerest
The mtf-demo is also a useful tool for displaying the metafiles WMF, EMF/EMF+, and also dumping the metaactions.
A demo renders of a metafile using vcl be seen by:
./bin/run mtfdemo odk/examples/basic/forms_and_controls/burger.wmf
This opens the burger.wmf as displays it in a window. You should have built the LibreOffice from sources to be able to run the above command from the LibreOffice source folder.
For debugging purposes, it is also possible to dump metaactions created as the intermediary format before rendering the metafile using -d option:
./bin/run mtfdemo -d odk/examples/basic/forms_and_controls/burger.wmf
If the command is successful, this message will be shown, and metadump.xml will be put in the current folder. The output will be:
Dumped metaactions as metadump.xml
The actual drawing is done using vcl and drawinglayer. One can dump the drawinglayer primitives for debugging purposes. We don’t have a dedicated tool to dump the primitives, but if you look at the tests inside emfio/qa/cppunit/emf/EmfImportTest.cxx, you can add this code snippet to do this:
Primitive2DSequence aSequence = parseEmf(u"emfio/qa/cppunit/wmf/data/stockobject.emf");
drawinglayer::Primitive2dXmlDump dumper;
Primitive2DContainer aContainer(aSequence);
dumper.dump(aContainer, "/tmp/drawinglayer.xml");
Then, after invoking make CppunitTest_emfio_emf, /tmp/drawinglayer.xml will be the dump of the drawinglayer primitives to the /tmp/drawinglayer.xml.
Support of metafile formats in LibreOffice is not complete. Some unimplemented records, and some bugs remaining. If you want to help, you can refer to the emfio documentation to see the list of unimplemented records in WMF and EMF/EMF+. Please look at the “Limitations” section.
Recently, Bartosz Kosiorek implemented SETARCDIRECTION record of the EMF. He added the support for this specific record to the LibreOffice core with this commit:
His implementation consists of several changes, including a change in emfio/source/reader/emfreader.cxx to read the record from the file and create tools::Polygon aPoly with additional parameter IsArcDirectionClockWise(). Also, change in emfio/source/reader/mtftools.cxx to set the mbClockWiseArcDirection member variable of the MtfTools class, adding setter/getter for this variable, and also changes in tools/source/generic/poly.cxx to change Polygon::Polygon() and ImplPolygon::ImplPolygon() to add support for the extra parameter, a boolean variable bool bClockWiseArcDirection.
This commit also contains a sample document and a new unit test, TestSetArcDirection() to make sure that the support for this record does not break easily in the future.
For a detailed tutorial on how to fix regressions, you can refer to this blog post:
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 looks much better:
As can be seen from the number of cycles at the bottom, this is now almost 10x faster (well, ok, 8x to be more precise). The script run splitting can't be seen anymore (it's ~0.1% now), text breaking is still there, but way smaller (6%, and that's 6% of a total that's 8x smaller, so it would be 0.75% compared to the original 26%). Not bad. The PDF generation still takes a couple of seconds (it's 400 pages after all), but it's way faster.
Other problem I noticed while working on this was the related bugreport #144515 (and a couple more that I've closed as its duplicates):
So as a fix I've moved the caching code to VCL and turned it into a generic SalLayoutGlyphsCache class, and then made this place use that cache ... which didn't really help that much. After investigation it turned out that EditEngine tries to fit the given text into the given paper size (Calc's cell in this case), and so it repeatedly asks to lay out the entire long string in the cell, then breaks the line at the needed width, and then it repeats the same with the rest of the string for the next line, and so on. Which again results in horrible O(N^2) performance that mostly repeats the same over and over again.
But that should be possible to avoid, right? If it's repeatedly the same text, just a subset with increasing starting index, then presumably the glyphs are the same, and their positions are also the same, just at an offset. Well, it's not that simple actually, as in some cases it's not possible to cut glyphs for text at a random place and hope it'll be exactly the same as text layout would give, since text layout may try e.g. to position several adjacent spaces more nicely. But after a couple of attempts Noel pointed out to me that Harfbuzz actually provides information about places where it's not safe to break. Finally, I noticed that the problem with a number of those bugreports is people having small Calc cells with long text, where most of the text is not seen. So for the default case it can be made to show only the start of the text that fits, and so I made it possible for EditEngine to stop breaking lines when the given size is filled in instead of trying to pointlessly process lines that won't be needed.
Again, the resulting profile looks much better:
In other somewhat related news, the fontconfig library has a new stable release that finally includes some performance improvemens when looking up fonts (not updated on its webpage, but available for download in release list).
BTW, since this was a TDF tender work, these improvements have been funded by TDF donations.
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:
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.
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.
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(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(LOROOT /opt/libreoffice7.3)
add_executable(example main.cpp)
SET(CMAKE_INCLUDE_CURRENT_DIR ON)
include_directories(
${CMAKE_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR}/com/sun/star
${LOROOT}/sdk/include
)
target_link_directories(example PRIVATE
${LOROOT}/program
${LOROOT}/sdk/lib
)
target_link_libraries(example
-luno_sal
-luno_cppu
-luno_cppuhelpergcc3
-luno_salhelpergcc3
-lunoidllo
-lxmlreaderlo
-lreglo
-lmergedlo
)
add_definitions(-DLINUX)
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.
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
and on Windows:
SET UNO_PATH=C:/Progra~1/LibreOffice/program SET URE_BOOTSTRAP=vnd.sun.star.pathname:C:/Progra~1/LibreOffice/program/fundamental.ini
I have previously talked about using cmake to build LibreOffice SDK examples in LibOCon 2021. You can see the presentation below:
Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.
If you accept this notice, your choice will be saved and the page will refresh.
Presentation: LibreOffice SDK Examples Overhaul – Hossein Nourikhah
This talk was presented in the LibreOffice Conference 2021 (LibOCon 2021) (Slides)
LibreOffice Conference 2021
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.
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
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.
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.
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 work on them.
A tool named git review can help you manage your submissions easily. It is a review tool, but you can use it both for submissions from others (for reviewing), and also your own submissions.
To download a submission with the id of 1234, you can easily do:
git review -d 1234
The id (1234 here) is the number you see in the end of the submission URL, for example: https://gerrit.libreoffice.org/c/core/+/1234. Then, your patch is downloaded, and a new branch is created for that submissions.
If you want to do a re-base, do this:
./g pull -r
If you face a merge conflict, you have to download your changes using the above method, do a re-base, and then try to resolve the conflicts. Then, you have to use git add to stage the changed source files.
When you have finished fixing your submission, you can do:
git commit --amend ./logerrit submit master
If you want to go back to the master branch, just use:
git checkout master
In the review process, you should do the changes requested from the reviewers. Sometimes, you may disagree with the reviewers, but then you should provide good reasons for not doing the requested changes in order to convince the reviewers.
Anyway, you should know that your code must conform to certain requirements in order to be eligible for merging. So, try to convince the reviewers that your code deserves to get merged into the code.
For the code conventions and coding style, it is suggested that you refer to these links:
For newer files, you may have to use clang-format, to re-format the code, and convince the CI that your code is fine!
There are many rules in the above links. Among them, this list on variable name prefixes is very useful. The list is extracted and suggested by Mike and Heiko:
xNamepNamerNamenNamefNamebName, or isName, or canNamesName (for char * -> pName; for OUString -> aName)aNameOther conventions are gathered as extensive set of rules. If you had any doubts, you can refer to the appropriate section that discuss design, implementation, testing and other aspects.
On the other hand, you should know that the easiest part of the change is the coding style! There are many things related to good design and implementation that you should take care to be able to pass the code review and get a +2.
By clicking on the name of each person in the Gerrit, you can see their contributions. But, this is not the whole story! Gerrit has a powerful query language that you can use inside the search box. For example:
owner:self: My own contributions
reviewer:self: Submissions that I am reviewing
owner:self status:merged: My merged contributions
owner:self status:open: My open contributions
You can use boolean operators between the queries:
AND -(negation) OR
If you do not specify anything, then AND is used.
You can do a lot of complicated searches among the submissions using its manual.
Gerrit is a powerful tool, and you can use many features of it to work more effectively. But, keep in mind that your focus should be on fixing the possible problems of your code, and improving your code quality.
Don’t worry! Reviewers usually help you on the road to fix the problems. Although in the end, it is your responsibility to address the concerns and do the recommendations – and eventually fix your code.
To get more help, you can always refer to its manuals.
I hope that you will get the best out of this review tool!
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
552 bugs, 63 of which are enhancements, have been reported by 338 people.
Top 10 Reporters
488 bugs have been triaged by 86 people.
Top 10 Triagers
460 bugs have been set to RESOLVED.
Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
162 bugs have been fixed by 37 people.
Top 10 Fixers
List of high severity bugs fixed
List of crashes fixed
List of performance issues fixed
List of old bugs ( more than 4 years old ) fixed
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.
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:
This is just a plain line break, and there are no changes here. It used to look like this in the past as well:
And both match the reference rendering:
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:
Finally you can compare that with the 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:
And this is how it used to look like:
Finally you can compare that with the 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:
And this is how it used to look like:
Finally you can compare that with the reference:
Other than the layout, there is also user interface for this in both LibreOffice and Collabora Online:
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:
https://gerrit.libreoffice.org/c/core/+/130687 sw clearing breaks: add document model
https://gerrit.libreoffice.org/c/core/+/130741 sw clearing breaks: add UNO API to insert this
https://gerrit.libreoffice.org/c/core/+/130818 sw clearing breaks: add UNO API to insert this with custom clear / char props
https://gerrit.libreoffice.org/c/core/+/130903 sw clearing breaks: include this in the UNO API text portion enum
https://gerrit.libreoffice.org/c/core/+/130961 sw clearing breaks: initial layout support
https://gerrit.libreoffice.org/c/core/+/131093 sw clearing breaks: fix rendering of the line break char itself
https://gerrit.libreoffice.org/c/core/+/131167 sw clearing breaks: add DOCX import
https://gerrit.libreoffice.org/c/core/+/131231 sw clearing breaks: add DOCX export
https://gerrit.libreoffice.org/c/core/+/131297 sw clearing breaks: fix layout when the line is empty
https://gerrit.libreoffice.org/c/core/+/131346 sw clearing breaks: add ODF export
https://gerrit.libreoffice.org/c/core/+/131645 sw clearing breaks: add ODF import
https://gerrit.libreoffice.org/c/core/+/131697 sw clearing breaks: add DOC import
https://gerrit.libreoffice.org/c/core/+/131732 sw clearing breaks: add DOC export
https://gerrit.libreoffice.org/c/core/+/131886 sw clearing breaks: add RTF filter
https://gerrit.libreoffice.org/c/core/+/131924 sw clearing breaks: add HTML filter
https://gerrit.libreoffice.org/c/core/+/131958 sw clearing breaks: add plain text export
https://gerrit.libreoffice.org/c/core/+/132024 sw clearing breaks: add insert UI
https://gerrit.libreoffice.org/c/core/+/132093 sw clearing breaks: add clearing indicator during rendering
https://gerrit.libreoffice.org/c/core/+/132162 sw clearing breaks: add layout support for the left and right cases
https://gerrit.libreoffice.org/c/core/+/132317 sw clearing breaks: link ODF proposal
You can get a snapshot / demo of Collabora Office 2022 and try it out yourself right now: try unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF’s next release too (7.4).
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!
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 that up to now were not supported by LibreOffice Calc.
Tomaz Vajngerl explained that to add support in LibreOffice for sparklines, they first needed to be read into the LibreOffice data model, but the data model for sparklines didn’t exist, so it first needed to be created. Once the data model was ready we could render the sparklines in the cell area.
Currently the code for this is in a feature branch (feature/sparklines), but it’s in the process of being up-streamed to master. The feature will be available in LibreOffice 7.4.
Thanks to the funding of NGI and the European Union, this missing feature is now being implemented. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 871498.
Find out more about the work going into the development of sparklines in Calc.
These are just a sample of the good work going on to support and develop LibreOffice for the next release. If you’d like to find out more about what Collabora is doing or, perhaps, you’d like to get involved then please visit the Collabora Online User Forum.
The post Recent Contributions from Collabora to LibreOffice appeared first on Collabora Office and Collabora Online.
The 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.
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.