Today we’re talking to Dione Maddern, who helps out in LibreOffice’s documentation team…
I’m 44. Originally from Brisbane, Australia but I currently live in Baltimore, on the East Coast of the USA. I’ve worked in a variety of administration, document production roles in the engineering and insurance industries.
Most of my technical writing experience has been writing procedures, instructions, and other documentation for Health Safety Environment and Quality (HSEQ) systems. This is my first software project.
In my spare time, I like to bake, draw, and play video games and tabletop RPGs.
I’m working on the Offline Help (F1) function of LibreOffice, fixing broken links and updating instructions and terminology.
I saw the banner on the user guide page asking for volunteers to work on Documentation Team. I’d been looking for a volunteer opportunity where I could use my skills in document production for a while and this seemed perfect. So I followed the link and posted my bio on the Documentation forum.
I felt a bit daunted at first because a lot people had more experience than me, or were from a software development background. Everyone has been very welcoming and I feel like I’ve been able to make a contribution to the project. I’ve learned a lot too, including a crash course in XML and Gerrit.
Dive in! It can seem a bit daunting at first, but it’s easier to get started than you think.
Thanks so much to Dione for all the help! Indeed, everyone is welcome to dive in, help out, and pick up valuable experience along the way. Who knows – perhaps it could lead to a career in technical writing…
One of the areas that can help LibreOffice, but may not directly be visible to the users, but has a big impact is the quality assurance, and the automated tests. Here, I discuss some areas and notes around improving tests for LibreOffice. First, I start with the regression and bug fixes without tests.
This is the description from GSoC ideas page:
While there are some automated tests for LibreOffice, there are not nearly enough. Adding more and better tests helps developers who work on the code to be more productive by allowing them to find regressions as early as possible.
To elaborate more, I should say there are many regressions and bugs in general that are fixed, but lack testing. It is important to have tests for those bug fixes, to avoid such problems in the future. You can see list of those fixed issues that lack tests here:
If you want to add some new tests for the bug fixes, first you should read the bug report very carefully to understand what is it about, and try to test the fix yourself. You can either use git revert
command to revert the fix, and see the problem in action, or try changing back the fix in the code, if it is not too big.
That is important, because you have to see that the test fails without the fix in place, but succeeds when it is applied. This is an essential step when writing the test.
To know more about the unit tests, you may look into these Wiki pages:
Some tests are written in the past, but not have issues because of the way they are written. In this case, porting them can provide improvement.
Tests can be written in multiple languages. At least, C++, Python, Java and BASIC are currently in use for different tests across the LibreOffice code base. Again in the GSoC ideas page, you can read:
There is some support in LibreOffice for automated tests, both at the level of unit tests, and at the level of system tests that drive a full LibreOffice instance. Currently tests can be written in C++, Java, or Python. Various new automated tests should be developed to improve the test coverage.
Tests written exclusively for Java (eg. the JUnit framework) should be ported to C++ so that they can execute much more rapidly. Similarly, tests that do remote control of an existing LibreOffice instance, should be re-factored to run inside that instance to make debugging much easier.
Almost all of the JUnitTests and UITests and also some smoke tests run as outside process. The trick to verify is to remove the soffice
(.exe
) binary, or to remove its execute permission (on Linux). In this way, out of process tests should fail, as they need to run the soffice
binary. After a successful build, you can see if this works. For example, try this:
make -d JunitTest_framework_complex
As an example, we have this issue around complex tests that should be ported to Python:
You may find many examples of the previously ported test in the issue page. Keep in mind that usually old Java tests should be removed in the same patch that provides the CppUnitTest port.
Also, you may find examples that UITests are ported to C++ from Python. For example, see this patch:
It ports a previously implemented UITest from Python to C++. The result is a faster test, which is more robust.
If you want to add or port some tests, please focus on a specific area of the code. LibreOffice code base is huge, and consists of more than 200 modules. It is not easy, and in fact not suggested, to work across different applications and modules. It is much better that you pick a specific application, and even inside that application, like Writer, Calc, Impress, etc., focus on specific module. In this way, it would be much easier to understand the ideas and the way tests are implemented.
One important question is around the complexity of writing or porting tests. The answer is not straightforward, as it depends on the area that the test is written. But one take a look at what others did in the past. By looking into Gerrit and or git log, you can find what other people, including the GSoC applicants where able to achieve during their work.
After writing a few tests, or porting a few tests, it may become easier for you to write more tests. Another thing is that you don’t have to write tests from scratch. There are many tests available in the LibreOffice code base, and you create your new test based on the existing tests, and customize it to match the purpose of the issue your are working on. Read the rest
One of the areas that can help LibreOffice, but may not directly be visible to the users, but has a big impact is the quality assurance, and the automated tests. Here, I discuss some areas and notes around improving tests for LibreOffice. First, I start with the regression and bug fixes without tests.
This is the description from GSoC ideas page:
While there are some automated tests for LibreOffice, there are not nearly enough. Adding more and better tests helps developers who work on the code to be more productive by allowing them to find regressions as early as possible.
To elaborate more, I should say there are many regressions and bugs in general that are fixed, but lack testing. It is important to have tests for those bug fixes, to avoid such problems in the future. You can see list of those fixed issues that lack tests here:
If you want to add some new tests for the bug fixes, first you should read the bug report very carefully to understand what is it about, and try to test the fix yourself. You can either use git revert
command to revert the fix, and see the problem in action, or try changing back the fix in the code, if it is not too big.
That is important, because you have to see that the test fails without the fix in place, but succeeds when it is applied. This is an essential step when writing the test.
To know more about the unit tests, you may look into these Wiki pages:
Some tests are written in the past, but not have issues because of the way they are written. In this case, porting them can provide improvement.
Tests can be written in multiple languages. At least, C++, Python, Java and BASIC are currently in use for different tests across the LibreOffice code base. Again in the GSoC ideas page, you can read:
There is some support in LibreOffice for automated tests, both at the level of unit tests, and at the level of system tests that drive a full LibreOffice instance. Currently tests can be written in C++, Java, or Python. Various new automated tests should be developed to improve the test coverage.
Tests written exclusively for Java (eg. the JUnit framework) should be ported to C++ so that they can execute much more rapidly. Similarly, tests that do remote control of an existing LibreOffice instance, should be re-factored to run inside that instance to make debugging much easier.
Almost all of the JUnitTests and UITests and also some smoke tests run as outside process. The trick to verify is to remove the soffice
(.exe
) binary, or to remove its execute permission (on Linux). In this way, out of process tests should fail, as they need to run the soffice
binary. After a successful build, you can see if this works. For example, try this:
make -d JunitTest_framework_complex
As an example, we have this issue around complex tests that should be ported to Python:
You may find many examples of the previously ported test in the issue page. Keep in mind that usually old Java tests should be removed in the same patch that provides the CppUnitTest port.
Also, you may find examples that UITests are ported to C++ from Python. For example, see this patch:
It ports a previously implemented UITest from Python to C++. The result is a faster test, which is more robust.
If you want to add or port some tests, please focus on a specific area of the code. LibreOffice code base is huge, and consists of more than 200 modules. It is not easy, and in fact not suggested, to work across different applications and modules. It is much better that you pick a specific application, and even inside that application, like Writer, Calc, Impress, etc., focus on specific module. In this way, it would be much easier to understand the ideas and the way tests are implemented.
One important question is around the complexity of writing or porting tests. The answer is not straightforward, as it depends on the area that the test is written. But one take a look at what others did in the past. By looking into Gerrit and or git log, you can find what other people, including the GSoC applicants where able to achieve during their work.
After writing a few tests, or porting a few tests, it may become easier for you to write more tests. Another thing is that you don’t have to write tests from scratch. There are many tests available in the LibreOffice code base, and you create your new test based on the existing tests, and customize it to match the purpose of the issue your are working on.
Working on this involves understanding the controlls, specially the spinedit, finding some way to modify it so that clicking on the units “the last 2 characters of the label in the spinedit entry” shows a dropdown, from which we can select a different unit.
I find working on this as a great opportunity to get deeper insights into widget implementations
I had no idea about where to start. One approach that appealed to me was if somehow I find the cursor position when the spinedit goes into edit mode, and compare it to the text length in the GtkEntry (internal) of the spinedit, then I can easily say that if the cursor is on the last 2 characters, then show a dropdown here. But that would not work, because “creating a new widget” ==> the logic should be built into the widget itself (I don’t know, it’s just guess-work).
Then I went to #gtk IRC channel, and asked about how to approach this problem.
IRC Conversation | |
---|---|
sahil_ | hi, I have a task to write a custom spinedit control, which will have a fontsize field (with a number and a unit like mm, pt, etc). It should be such that if I click on the unit with mouse, then it should show me a dropdown to use different units. Mockup Here’s the mockup. How can I approach it? |
sahil_ | Libreoffice uses glade and custom welding for widgets. And from the research I did on it, I found that a normal gtkentry is aware of the cursor position, which can be used like if the cursor is on the last 2 characters, then show the popup. |
sahil_ | But a new control has to be created for that (in my understanding). |
mclasen | The pieces are GtkText and GtkGestureClick . You just have to glue them together in the right way |
sahil_ | mclasen: and for the dropdown? |
mclasen | GtkPopover is what is used for that |
sahil_ | Also the spinedit doesn’t expose the gtkEntry (it’s internal). So do I have to create one from scratch? |
sahil_ | or does it? |
mclasen | you can take a look at how GtkEntry, GtkSpinButton, etc are put together nowadays they are all just wrappers around a GtkText widget |
This was more than enough to get started.
Looking into it, I found that I was mixing up GtkComboBox, which is used as
fontsizebox, and GtkSpinButton, which is what I was supposed to explore and
modify. weld::SpinButton
, which is libreoffice’s wrapper over GtkSpinButton
(if I am not wrong) has functions which give access to the cursor location in
the Entry. It would require some playing around to understand the dynamics
though.
I am also curious about how a dialog, or any UI element, which is created using glade, which usually has the widgets as Gtk types (GtkLabel, GtkButton etc.) is loaded into different backends. Knowing how the welding works would answer it I think.
The LibreOffice Community Documentation Team is happy to announce the immediate release of the latest Writer and Calc guides for the new LibreOffice 24.2 office suite.
The two books are updates of the respective LibreOffice 7.6 guides, and describe the new features available in LibreOffice 24.2.
Jean Weber and Steve Fanning leaded the update of the Guides and provided valuable inputs to the contents.
Updated and review by Jean Weber, the Writer Guide is the authoritative guide for using Writer to edit documents, from a single page to a full book. The latest Writer guide includes all these updates:
Updated by Steve Fanning, the guide contains description of the new features of Calc 24.2, the spreadsheet program of LibreOffice:
LibreOffice Community 24.2 also includes many other changes, including:
The Guides are available in PDF, in source OpenDocument Format and printed versions from the bookshelf and documentation web pages.
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
477 bugs, 55 of which are enhancements, have been reported by 313 people.
458 bugs have been triaged by 79 people.
419 bugs have been set to RESOLVED.
Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
147 bugs have been fixed by 40 people.
List of critical bugs fixed
List of high severity bugs fixed
List of crashes fixed
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
477 bugs, 55 of which are enhancements, have been reported by 313 people.
458 bugs have been triaged by 79 people.
419 bugs have been set to RESOLVED.
Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
147 bugs have been fixed by 40 people.
List of critical bugs fixed
List of high severity bugs fixed
List of crashes fixed
It’s important to set some target before jumping into and starting to do the thing. I would like to make an annoying “Donate Now” dialog
The dialog would show up whenever the user starts libreoffice, or whenever he switches to different modules like calc or writer etc.
The dialog would look something like the mockup shown below. The dialog should have a faint background image which shows all the community members, to give out cheerfull vibes. Other than that it would have a text which would be some interesting fact about libreoffice.
It would have an image on the top, and a “donate now” and a “close” button on the bottom It would also have a checkbox saying “I am broke”, which would be unchecked by default. If the user checks it, then the dialog will stop asking for monitory donations, and instead pester the user with “Other Ways To Contribute”, which would include all the getting involved stuff.
Other than that It would also have an “I don’t care” checkbox, which will be
unchecked by default, and if checked, the dialog won’t show up again, and
then one has to reactivate it from about > user-hostile-donation-dialog
.
This would makeup for a nice and fun learning experience. It would involve playing around with the UI, listeners, strings, “the user centiments” etc.
It’s not a rigid outline, but rather an idea to atleast get started. Patch on gerrit.
I will start with understanding how the about dialog is implemented, how does it display images and custom text etc. One thing that I noticed previously is that the “Tip Of The Day” dialog uses GtkDrawingArea while the about dialog uses GtkImage.
I asked on the #gtk IRC channel, and found that GtkImage is an image loaded from the disk at a specific size, while GtkDrawingArea is a canvas you draw on using cario.
This might have been the reason for why Libreoffice was carshing when I used GtkImage while trying to recreate the “Tip Of The Day” dialog. There I just created a bare constructor, without specifying the image.
Well for the user hostile dialog, GtkImage would work fine as I don’t need to change the image on the go.
I created a dialog box using glade. The challenge that I faced was that I was
not able to move the checkboxes in the ButtonBox of the GtkDialog to the left
side. All 4 controls were stuck together. Then I looked into how the
tip-of-the-day dialog does it, and there I found that whatever control I wanted
to left align (in the button box), I had to turn on the packing > secondary
control. What that is, I am still to investigate into.I got this Documentation Reference
from the #gtk IRC channel.
For some reason, the dialog doesn’t carsh now :). Other issue that I faced was
related to text wrapping. So if I set some long text in a weld::Label
using
the set_label(OUString)
function, then it just expands the dialog to fit in
one line. GtkImage is just a bitmap image, for which we specify the size
(width) while loading it. For label wrapping, I will look into how the
tip-of-the-day dialog does it. Making the dialog resizable doesn’t work as
well. Under general > formatting
of the GtkLabel there is an option to specify
wrapping properties, and just below that are boxes for max width. Playing around with
those, I was able to get text wrapping to work.
Sometimes these things feel hard, and I tend to avoid them as much as I can. But Now I realize that it is those hard moments which build me to tackel bigger challenges, and I should be looking for such opportunities. Today I find glade easier to use compared to yesterday
I got the dialog as I wanted. Looks nice! When I was working on the dialog, I
changed the SID_ABOUT:
unocommand to display the user-hostile-dialog instead
of the about dialog. This way I was able to test whether it works as expected
or not.
Then I went ahead to work on the listeners and the configuration logic. There should be some way for us to remember what options were checked/unchecked when the dialog was closed (configuration), and some way know which module we are entering, so that we can change the text accordingly (listeners).
I figured that for each dialog, we have a generic wrapper class called
VclAbstractDialog
. It provides “one type for all dialogs” solution, which
makes sense. I followed the about/tip-of-the-day dialog to write all these
functions and classes. And since I want a menu entry as well, I had to create
an unocommand as well. I found that each module, and the start center etc have
their own menubar.xml file. I added the user-hostile-dialog entry to most of
those.
Looking into tip-of-the-day dialog, I found that when it is created, it adds a listener on the parent window, and checks if it is dying or not, and if so then it terminates as well. Then in the destructor, it removes the listener.
For adding listeners to show the dialog on such and such events, I had to read
through the SfxViewFrame::Notify
function, as described in the Blog.
It listens for changes like document created/opened and creates the dialog then.
The last part was to remember whether the user checked some checkbox or not, and
remember that throughout the session, and between new sessions. I defined configuration
defaults in xml file officecfg/registry/schema/org/openoffice/Office/Common.xcs
and
used the path to define a struct, through which we access/set the values, similar to
how tip-of-the-day dialog does it.
struct UserHostileDialogDontCare : public comphelper::ConfigurationProperty<LastTipOfTheDayShown, sal_Int32> {
static OUString path() { static constexpr OUString PATH(u"/org.openoffice.Office.Common/Misc/UserHostileDialogDontCare"_ustr); return PATH; }
private:
UserHostileDialogDontCare(); // not defined
~UserHostileDialogDontCare(); // not defined
};
...
Now when the dialog is created , these configuration values are checked, and are used to set the state of the controls. When the dialog is destroyed, these choices are not lost. I forgot to set the type to boolean in the xml file, and as a result, the dialog was not showing up, so that’s something to reember as well, while copy pasting ;).
I added links to the checkboxes as well to change the Donate
button to
Contribute
, if the user says “I’m broke!”
Since the user can either donate or contribute, I had to redirect him to the correct
page. For that I looked at how .uno:Donation
does it. At first I tried to do it how
the .uno:Donation does it, but then I thought why don’t I just call the uno commands!
So when the button is clicked, it dispatches uno commands depending on whether “[ ] I’m broke!” is checked or not.
Since I want it to be User Hostile, there should be some way to show it when start center is opened. Other than that there should be some way to tell which module is opened, and change the label according to that.
// load and arrange 8x pixel chunks & a shifted version vpermd %ymm0,%ymm1,%ymm5 vmovdqu 0x20(%rdi,%r10,4),%ymm0 vpand %ymm5,%ymm2,%ymm5 vpermd %ymm0,%ymm3,%ymm6 vpand %ymm4,%ymm6,%ymm6 vpor %ymm5,%ymm6,%ymm5 // compare and turn that into a bitmask of duplicates vpcmpeqd %ymm0,%ymm5,%ymm5 vmovmskps %ymm5,%eax // store that bitmask (win was here) mov %al,(%rcx) mov %eax,%r11d not %r11b shl $0x5,%rax // pack only new pixels into memory vmovdqa (%rax,%r9,1),%ymm5 vpermd %ymm0,%ymm5,%ymm5 vmovdqu %ymm5,(%r8) movzbl %r11b,%eax popcnt %rax,%rax lea (%r8,%rax,4),%r8 add $0x8,%r10 inc %rcx cmp $0xf8,%r10 jb // loop to top
// simplified inner loop for 64 pixel chunks for (; bitToSet; ++x, bitToSet <<= 1) { if (from[x] == lastPix) rleMask |= bitToSet; else { lastPix = from[x]; scratch[outp++] = lastPix; } }
Suraj Bhattarai, our Nepalese LibreOffice Community Liaison, writes:
We shared some positive words around the LibreOffice project, among students of IOE Purwanchal Campus enrolled in CS50x Nepal. The LibreOffice orientation was scheduled for two hours on 21st February, 2024 at the MSC special classroom of the same campus; it was a special session in the CS50x Nepal timeline.
The session that I delivered gave a general overview of the LibreOffice project, The Document Foundation, the Document Liberation Project, past activities carried out by the local Nepali community, customization tips and tricks for familiarity, and how to contribute or connect in the community.
Moreover, the session – organized for 30 CS50x Students – included a total participation of 47 people, seven of whom were Nepali Community members, six of whom were other students, and the rest were the CS50x staff. The session was primarily intended to introduce the LibreOffice suite and provide hands-on experience with it, to the newly enrolled, first-year students in the campus, who were actually enrolled for the CS50x classes.
The session had this breakdown:
The competition was facilitated by our community volunteers, where they distributed some gifts as well. The challenge for the competition was to create a visually appealing, quick three-page presentation using LibreOffice Impress on-the-spot, in 25 minutes. All they had to do was recreate the presentation slide version of the LibreOffice university/school (English) flyer.
The gifts were LibreOffice T-shirts, water bottles, Document Liberation Project stickers, pens and more. The same gifts were distributed to winners of the Plane Rush activity as well, and some light items like stickers and pens were given to everyone present in the session.
After some hands-on experience with LibreOffice Impress, a quick survey was conducted, where 27 of the participants claimed that they tried LibreOffice for the very first time. The same survey had asked what they love about LibreOffice. And honestly, a majority of them mentioned the reasons to be: open source, free, compatible with Microsoft Office files, community driven, cross-platform, privacy, and feature-rich.
The latter half of the session was filled with fun, as we cut and shared the vanilla-flavored release party cake with everyone present in the room. The environment was really fun with flashes, noise, claps, smiles, and cameras and eyes all over the cake.
Lastly, in the sunset and the open ground, participants flew their own paper planes based on LibreOffice PaperPlaneFront.odg. The session was totally fun and a unique experience for everyone. And yes, they did collect the planes for paper recycling later on. And with this, the day, joy and celebration all came down to a happy ending with the efforst from the Nepali community.
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.
If you accept this notice, your choice will be saved and the page will refresh.
FOSDEM is the biggest meetup of free and open source software (FOSS) developers in Europe, and takes place every year, in early February, in Brussels. And the LibreOffice project is always there!
We had a stand with merchandise, and community members were present to answer questions, provide information about new features in LibreOffice, and meet people from other FOSS projects.
Our LibreOffice pens were very popular, as were Document Liberation Project stickers and flyers. Many visitors to the stand were regular LibreOffice users and just wanted to say thank you, some buying a T-shirt or hoodie as well. We even had a couple of donations on the spot! Others asked what they can do for LibreOffice.
And here are a few photos from the event, and our community dinner. This is just the beginning though – we plan to be at many more events this year!
The new Board of Directors of The Document Foundation has just started its two-year term on 18 February 2024.
The full members are, in alphabetical order: Eliane Domingos, Sophie Gautier, Björn Michaelsen, László Németh, Simon Phipps, Eike Rathke, Italo Vignoli.
The deputies are again in alphabetical order: Osvaldo Gervasi, Mike Saunders, Paolo Vecchi.
Mike Saunders was elected to the Board for the first time. All the other members have served either on the Steering Committee from 2010 to 2012 (Sophie Gautier and Italo Vignoli) or on the Board of Directors since 2014 as full or deputy members.
At its first meeting, the Board unanimously elected Eliane Domingos as Chair and Simon Phipps as Vice-Chair.
At the same time, they decided to review and reorganise responsibilities and areas of oversight to ensure a more agile decision-making process.
Six people who served during the previous term have left the Board, but will continue to contribute to the project as TDF Members: Thorsten Behrens, Gábor Kelemen, Gabriel Masei, Cor Nouws, Emiliano Vavassori, Ayhan Yalçınsoy.
We are deeply grateful to all of them for their dedication, their contribution to decision making and all the time they have volunteered to serve on the Board, as well as their ongoing contribution to FOSS and LibreOffice.
Writer now supports legal numbering for two more formats: DOC and RTF (ODT and DOCX were working already.)
This work is primarily for Collabora Online, done as a HackWeek project, but the feature is fully available in desktop Writer as well.
Legal numbering is a way to influence the number format of values inherited in a multi-level numbering. Say, the outer numbering uses Roman numerals and the inner numbering uses X.Y as the number format, but the inner level wants to display the outer values as Arabic numerals. If this is wanted (and guessing from the name, sometimes lawyers do want this), then the inner number portion will expand to values like "2.01" instead of "II.01", while the outer number portions will remain values like "II".
Mike did 80% of the work, what you can see here is just the RTF/DOC filters.
Picking a smaller feature task like this looked like a good idea, since I wanted to spend some of the time on regression fixing around last year's multi-page floating table project.
For (binary) DOC, the relevant detail is the fLegal
bit in the LVLF
structure. Here is the
result:
It shows how the outer "II" gets turned into "2", while it remained "II" in the past. This works for both loading and saving.
The same feature is now handled in the RTF filter as well. There the relevant detail is the
\levellegal
control word, which has an odd 1 default value (the default is usually 0). Here is the
result:
It shows that the RTF filter is up to speed with the DOC one by now.
As for the multi-page floating tables, I looked at tdf#158986 and tdf#158801.
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 small changes:
You can get a snapshot / demo of Collabora Office 24.04 and try it out yourself right now: try the 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 (24.8).
If you copy contents from LibreOffice Writer to a plain text editor like gedit or Notepad, you will see that it does a straightforward thing: It copies the text and some basic formatting like converting bullets to ‘•’. For the Writer tables, the conversion is very simple right now: every cell is written in a separate line.
For example, if you have a table like this:
A | B --|-- C | D
When you copy the table from LibreOffice Writer and paste it into a plain text editor, it will become something like this, which is not always desirable.
A B C D
It is requested that like LibreOffice Calc, or Microsoft Word, and many other programs, the copy/paste mechanism should create a text like this:
A B C D
The columns are separated by <tab>.
This feature request is filed in Bugzilla as tdf#144576:
There are many steps in copy/pasting, including the data/format conversion and clipboard format handling. Here, you have to know that the document is converted to plain text via “text” filter.
The plaintext (ASCII) filter is located here in the LibreOffice core source code:
Therefore, to change the copy/paste output, you have to fix the ASCII filter. That would also provide the benefit that plain text export will be also fixed as requested here.
In this folder, there are a few files:
$ ls sw/source/filter/ascii/ ascatr.cxx parasc.cxx wrtasc.cxx wrtasc.hxx
To change the output, you have to edit this file:
In this file, there is a loop dedicated to create the output.
// Output all areas of the pam into the ASC file do { bool bTstFly = true; ... }
Inside this loop, the code iterates over the nodes inside the document structure, and extracts text from them. To check for yourself, add the one line below to the code, build LibreOffice, and then test. You will see that a *
is appended before each node.
SwTextNode* pNd = m_pCurrentPam->GetPoint()->GetNode().GetTextNode();
if( pNd )
{
+ Strm().WriteUChar('*');
...
}
For example, having this table, with 1 blank paragraph up and down:
A | B --|-- C | D
You will get this after copy/paste into a plain text editor:
* *a *b *c *d *
To fix the bug, you have to differentiate between table cells and other nodes. Then, you should take care of the table columns and print tab between them.
To go further, you can only add star before table cells:
if( pNd )
{
SwTableNode *pTableNd = pNd->FindTableNode();
+ if (pTableNd)
+ {
+ Strm().WriteUChar('*');
+ }
...
}
You can look into how other filters handled tables. For example, inside sw/source/filter/html/htmltab.cxx you will see how table is managed, first cell is tracked and appropriate functions to handle HTML table are called.
For the merged cells, the EasyHacker should first checks the behavior in other software, then design and implement the appropriate behavior.
To gain a better understanding of the Writer document model / layout, please see this document:
This presentation is also very helpful to gain a good understanding of Writer development:
Introduction to Writer Development – LibreOffice 2023 Conference Workshop, Miklos Vajna
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.
If you copy contents from LibreOffice Writer to a plain text editor like gedit or Notepad, you will see that it does a straightforward thing: It copies the text and some basic formatting like converting bullets to ‘•’. For the Writer tables, the conversion is very simple right now: every cell is written in a separate line.
For example, if you have a table like this:
A | B --|-- C | D
When you copy the table from LibreOffice Writer and paste it into a plain text editor, it will become something like this, which is not always desirable.
A B C D
It is requested that like LibreOffice Calc, or Microsoft Word, and many other programs, the copy/paste mechanism should create a text like this:
A B C D
The columns are separated by <tab>.
This feature request is filed in Bugzilla as tdf#144576:
There are many steps in copy/pasting, including the data/format conversion and clipboard format handling. Here, you have to know that the document is converted to plain text via “text” filter.
The plaintext (ASCII) filter is located here in the LibreOffice core source code:
Therefore, to change the copy/paste output, you have to fix the ASCII filter. That would also provide the benefit that plain text export will be also fixed as requested here.
In this folder, there are a few files:
$ ls sw/source/filter/ascii/ ascatr.cxx parasc.cxx wrtasc.cxx wrtasc.hxx
To change the output, you have to edit this file:
In this file, there is a loop dedicated to create the output.
// Output all areas of the pam into the ASC file do { bool bTstFly = true; ... }
Inside this loop, the code iterates over the nodes inside the document structure, and extracts text from them. To check for yourself, add the one line below to the code, build LibreOffice, and then test. You will see that a *
is appended before each node.
SwTextNode* pNd = m_pCurrentPam->GetPoint()->GetNode().GetTextNode();
if( pNd )
{
+ Strm().WriteUChar('*');
...
}
For example, having this table, with 1 blank paragraph up and down:
A | B --|-- C | D
You will get this after copy/paste into a plain text editor:
* *a *b *c *d *
To fix the bug, you have to differentiate between table cells and other nodes. Then, you should take care of the table columns and print tab between them.
To go further, you can only add star before table cells:
if( pNd )
{
SwTableNode *pTableNd = pNd->FindTableNode();
+ if (pTableNd)
+ {
+ Strm().WriteUChar('*');
+ }
...
}
You can look into how other filters handled tables. For example, inside sw/source/filter/html/htmltab.cxx you will see how table is managed, first cell is tracked and appropriate functions to handle HTML table are called.
For the merged cells, the EasyHacker should first checks the behavior in other software, then design and implement the appropriate behavior.
To gain a better understanding of the Writer document model / layout, please see this document:
This presentation is also very helpful to gain a good understanding of Writer development:
Introduction to Writer Development – LibreOffice 2023 Conference Workshop, Miklos Vajna
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.
When working with LibreOffice Impress, “Slide Master” is the place where you can change the templates used for different types of the slides used in your presentation. Here we discuss a possible improvement for the “Slide Master” by making the copy from master slides possible.
To see the problem and the room for enhancement, open LibreOffice Impress, then choose “View->Master->Slide Master” from the menus. Then, try to copy the master page on the left in the slide sorter. Unfortunately, it is not possible.
Having this feature is helpful, because different page types have many things in common, and being able to copy/paste helps creating templates much faster.
Looking into sd/source/core/drawdoc3.cxx
, you can see a huge function SdDrawDocument::InsertBookmarkAsPage
, which is relevant here. It contains ~600 lines of code. This huge function is in itself a problem. Therefore, to implement the enhancement, on should try to first refactor the function, then add a unit test in sd/qa/unit
, find and then separate all the ~6 use cases, and fix the style/name merging.
After the cleanup, the main fix should be implemented. The suggested path to implement this comes from Jean-Francois. He suggest to improve the duplicate()
method, which is described in the documentation:
As described in the above documentation, its role is to duplicate a page:
Creates a duplicate of a DrawPage or MasterPage, including the Shapes on that page and inserts it into the same model.
However, the implementation does not work for master slides, as the macros in the attachment file implies. The solution should add the needed implementation for master slides.
The implementation is inside sd/source/ui/unoidl/unomodel.cxx
inside duplicate function:
// XDrawPageDuplicator uno::Reference< drawing::XDrawPage > SAL_CALL SdXImpressDocument::duplicate( const uno::Reference< drawing::XDrawPage >& xPage ) { ... }
The above issue is filed as tdf#45617. If you like to work on it, just follow the Bugzilla link to see more information.
To implement this feature, first you have to build LibreOffice from the sources. If you have not done that yet, please refer to this guide first:
When working with LibreOffice Impress, “Slide Master” is the place where you can change the templates used for different types of the slides used in your presentation. Here we discuss a possible improvement for the “Slide Master” by making the copy from master slides possible.
To see the problem and the room for enhancement, open LibreOffice Impress, then choose “View->Master->Slide Master” from the menus. Then, try to copy the master page on the left in the slide sorter. Unfortunately, it is not possible.
Having this feature is helpful, because different page types have many things in common, and being able to copy/paste helps creating templates much faster.
Looking into sd/source/core/drawdoc3.cxx
, you can see a huge function SdDrawDocument::InsertBookmarkAsPage
, which is relevant here. It contains ~600 lines of code. This huge function is in itself a problem. Therefore, to implement the enhancement, on should try to first refactor the function, then add a unit test in sd/qa/unit
, find and then separate all the ~6 use cases, and fix the style/name merging.
After the cleanup, the main fix should be implemented. The suggested path to implement this comes from Jean-Francois. He suggest to improve the duplicate()
method, which is described in the documentation:
As described in the above documentation, its role is to duplicate a page:
Creates a duplicate of a DrawPage or MasterPage, including the Shapes on that page and inserts it into the same model.
However, the implementation does not work for master slides, as the macros in the attachment file implies. The solution should add the needed implementation for master slides.
The implementation is inside sd/source/ui/unoidl/unomodel.cxx
inside duplicate function:
// XDrawPageDuplicator uno::Reference< drawing::XDrawPage > SAL_CALL SdXImpressDocument::duplicate( const uno::Reference< drawing::XDrawPage >& xPage ) { ... }
The above issue is filed as tdf#45617. If you like to work on it, just follow the Bugzilla link to see more information.
To implement this feature, first you have to build LibreOffice from the sources. If you have not done that yet, please refer to this guide first:
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
515 bugs, 76 of which are enhancements, have been reported by 297 people.
523 bugs have been triaged by 67 people.
456 bugs have been set to RESOLVED.
Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
181 bugs have been fixed by 39 people.
List of high severity bugs fixed
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
515 bugs, 76 of which are enhancements, have been reported by 297 people.
523 bugs have been triaged by 67 people.
456 bugs have been set to RESOLVED.
Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
181 bugs have been fixed by 39 people.
List of high severity bugs fixed
After a long slog since November when the previous version of coverity was EOLed and we had to start using 2022.6.0 with its new suggestions for std::move etc, LibreOffice is now finally back to a 0 warnings coverity state
This post describes some challenges around having multiple views of one opened document in LibreOffice core, when those views belong to LOK views, representing different users, with their own language, locale and other view settings.
This work is primarily for Collabora Online, but is useful for all clients of the LOK API.
LOK views are meant to represent separate users, so we need to make sure that when a user sets their preferences and trigger an action, then the response to that action goes to the correct view, with the correct view settings.
This is different from the desktop LibreOffice use-case, where multiple windows are still meant to share the same user name, language, undo stack and so on.
In this post, I would like to present 4 small improvements that recently happened to the LOK API to provide this wanted separation of views.
The first was an issue where two users were editing the same document, one busily typing and the other clicked on a link in Calc. What could happen sometimes is the link popup appeared for the user who typed, not for the user who clicked on the link:
This specific problem can be fixed by making sure that link click callbacks are invoked synchronously (while the clicking view is still active) and not later, when the current view may or may not be the correct one.
It turns out the same problem (async command dispatch) affects not only hyperlinks, but many other cases as well, where we want to stay async, for example, when one dialog would invoke another dialog, like the Calc conditional format -> add dialog:
There you don't want to change async commands into sync commands, because that may mean spinning the main loop inside a dialog, resulting in nested main loops. This can be fixed by making sure that async commands to be dispatched (sfx2 hints in general) are processed in a way that the current view at dispatch & processing is the same, which is now the case.
The third problem was around wrong language & locale in the status bar:
This is not simply a problem of missing translation, the trouble was that the status bar update is also async and by the time the update happened, the locale of the view on the left was used, for a string that appears on the right.
The way to fix this is to perform the update of toolbars/statusbar/etc (in general: SfxBindings) in a way that the language at job schedule time and at UI string creation time is the same.
The last problem was quite similar, still about bad language on the UI, but this time on the sidebar:
This is similar to the statusbar case, but the sidebar has its own executor for its async jobs, so that needed a fix similar to what the statusbar already had, now done.
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 small changes:
You can get the latest Collabora Online Development Edition 23.05 and try it out yourself right now: try the development edition. 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 (24.8).
In this blog post, I discuss gbuild for Java tests. The goal is to write a Makefile to compile and run a JUnit test for LibreOffice. You can also refer to part 1 and part 2 for a brif overiew on gbuild, the LibreOffice build system.
In the first post on gbuild, I have mentioned some macro examples including gb_Output_announce
which was used to print nice messages like the ones including “[CXX]”. Now let’s explain some more macros related to Java tests.
Consider that you want to compile and run a JUnitTest. To do that, you need to write the test in a Java file, and create a Makefile to run that.
This is an example for running a test defined in Java file sw/qa/complex/indeterminateState/CheckIndeterminateState.java.
$(eval $(call gb_JunitTest_JunitTest,sw_complex)) $(eval $(call gb_JunitTest_add_sourcefiles,sw_complex,\ sw/qa/complex/indeterminateState/CheckIndeterminateState \ )) $(eval $(call gb_JunitTest_use_unoapi_jars,sw_complex)) $(eval $(call gb_JunitTest_add_classes,sw_complex,\ complex.indeterminateState.CheckIndeterminateState \ ))
The make file for running this Java test consists of calling multiple macros. It starts with gb_JunitTest_JunitTest
macro, which defines the test by its name, sw_complex
. This macro is defined in solenv/gbuild/JunitTest.mk
. If you grep
for define in the same file, you will see this result:
$ grep -w define solenv/gbuild/JunitTest.mk define gb_JunitTest_JunitTest define gb_JunitTest_set_defs define gb_JunitTest_add_classes define gb_JunitTest_add_class define gb_JunitTest_add_sourcefile define gb_JunitTest_add_sourcefiles define gb_JunitTest_use_jar define gb_JunitTest_use_jars define gb_JunitTest_use_jar_classset define gb_JunitTest_add_classpath define gb_JunitTest_use_system_jar define gb_JunitTest_use_system_jars define gb_JunitTest_use_external define gb_JunitTest_use_externals define gb_JunitTest_use_customtarget define gb_JunitTest_use_customtargets define gb_JunitTest_use_unoapi_jars define gb_JunitTest_use_unoapi_test_class define gb_JunitTest_set_unoapi_test_defaults define gb_JunitTest_JunitTest
To stick to the macros used in the above example, I describe these macros:
gb_JunitTest_add_sourcefiles
: This macro adds a Java source file to the test. It defines the code that adds the sw/qa/complex/indeterminateState/CheckIndeterminateState.java
to the test. But please note that you should drop the .java
extension:
$(eval $(call gb_JunitTest_add_sourcefiles,sw_complex,\ sw/qa/complex/indeterminateState/CheckIndeterminateState \ ))
The other macro gb_JunitTest_use_unoapi_jars
, adds the UNO API JAR files to be used with the test.
And in the end, you need to add the test class name using gb_JunitTest_add_classes
macro. The class name is visible in the end.
The result can be quite complex, but it works. 🙂
java.exe -Xmx64M -classpath "$W/JavaClassSet/JunitTest/sw_complex;C:/cygwin64/home/user/lode/opt/share/java/junit.jar;$I/program;$W/Jar/OOoRunner.jar;$I/program/classes/libreoffice.jar;$W/Jar/test.jar" -Dorg.openoffice.test.arg.soffice="path:$I/program/soffice" -Dorg.openoffice.test.arg.env=PATH="$PATH" -Dorg.openoffice.test.arg.user=file:///$W/JunitTest/sw_complex/user org.junit.runner.JUnitCore complex.indeterminateState.CheckIndeterminateState
The above is the actual command that runs the test. Please note that if you forget the gb_JunitTest_add_classes
macro to define the class name, the test may compile, but it will not run.
As an example, you can see the below patch. This patch fixes the problem of the JUnit test not running:
Many macros are available in gbuild, making easier to create Makefiles to compile and run tests, build libraries and executable applications and many other relevant tasks. The best way to find and understand these macros is to look at the Makefiles written by others to the same task. Look for .mk
files, and if you want to see the implementation of the macros, look into solenv/gbuild/
.
I will write more about gbuild macros in the next series of blog posts on gbuild. Read the rest
In this blog post, I discuss gbuild for Java tests. The goal is to write a Makefile to compile and run a JUnit test for LibreOffice. You can also refer to part 1 and part 2 for a brif overiew on gbuild, the LibreOffice build system.
In the first post on gbuild, I have mentioned some macro examples including gb_Output_announce
which was used to print nice messages like the ones including “[CXX]”. Now let’s explain some more macros related to Java tests.
Consider that you want to compile and run a JUnitTest. To do that, you need to write the test in a Java file, and create a Makefile to run that.
This is an example for running a test defined in Java file sw/qa/complex/indeterminateState/CheckIndeterminateState.java.
$(eval $(call gb_JunitTest_JunitTest,sw_complex)) $(eval $(call gb_JunitTest_add_sourcefiles,sw_complex,\ sw/qa/complex/indeterminateState/CheckIndeterminateState \ )) $(eval $(call gb_JunitTest_use_unoapi_jars,sw_complex)) $(eval $(call gb_JunitTest_add_classes,sw_complex,\ complex.indeterminateState.CheckIndeterminateState \ ))
The make file for running this Java test consists of calling multiple macros. It starts with gb_JunitTest_JunitTest
macro, which defines the test by its name, sw_complex
. This macro is defined in solenv/gbuild/JunitTest.mk
. If you grep
for define in the same file, you will see this result:
$ grep -w define solenv/gbuild/JunitTest.mk define gb_JunitTest_JunitTest define gb_JunitTest_set_defs define gb_JunitTest_add_classes define gb_JunitTest_add_class define gb_JunitTest_add_sourcefile define gb_JunitTest_add_sourcefiles define gb_JunitTest_use_jar define gb_JunitTest_use_jars define gb_JunitTest_use_jar_classset define gb_JunitTest_add_classpath define gb_JunitTest_use_system_jar define gb_JunitTest_use_system_jars define gb_JunitTest_use_external define gb_JunitTest_use_externals define gb_JunitTest_use_customtarget define gb_JunitTest_use_customtargets define gb_JunitTest_use_unoapi_jars define gb_JunitTest_use_unoapi_test_class define gb_JunitTest_set_unoapi_test_defaults define gb_JunitTest_JunitTest
To stick to the macros used in the above example, I describe these macros:
gb_JunitTest_add_sourcefiles
: This macro adds a Java source file to the test. It defines the code that adds the sw/qa/complex/indeterminateState/CheckIndeterminateState.java
to the test. But please note that you should drop the .java
extension:
$(eval $(call gb_JunitTest_add_sourcefiles,sw_complex,\ sw/qa/complex/indeterminateState/CheckIndeterminateState \ ))
The other macro gb_JunitTest_use_unoapi_jars
, adds the UNO API JAR files to be used with the test.
And in the end, you need to add the test class name using gb_JunitTest_add_classes
macro. The class name is visible in the end.
The result can be quite complex, but it works.
java.exe -Xmx64M -classpath "$W/JavaClassSet/JunitTest/sw_complex;C:/cygwin64/home/user/lode/opt/share/java/junit.jar;$I/program;$W/Jar/OOoRunner.jar;$I/program/classes/libreoffice.jar;$W/Jar/test.jar" -Dorg.openoffice.test.arg.soffice="path:$I/program/soffice" -Dorg.openoffice.test.arg.env=PATH="$PATH" -Dorg.openoffice.test.arg.user=file:///$W/JunitTest/sw_complex/user org.junit.runner.JUnitCore complex.indeterminateState.CheckIndeterminateState
The above is the actual command that runs the test. Please note that if you forget the gb_JunitTest_add_classes
macro to define the class name, the test may compile, but it will not run.
As an example, you can see the below patch. This patch fixes the problem of the JUnit test not running:
Many macros are available in gbuild, making easier to create Makefiles to compile and run tests, build libraries and executable applications and many other relevant tasks. The best way to find and understand these macros is to look at the Makefiles written by others to the same task. Look for .mk
files, and if you want to see the implementation of the macros, look into solenv/gbuild/
.
I will write more about gbuild macros in the next series of blog posts on gbuild.
In the first blog post on LibreOffice build system, gbuild
which uses GNU Make, I discussed some of the features of it. Here I discuss more about some gbuild tips and tricks that you may need.
In order to build a single module, you need to use its name. For example, to build only “odk”, which contains office development kit, you only have to type:
make odk
On the other hand, there are many other build targets associated with odk. By typing make odk, and then pressing tab, you will see this list, which shows possible targets:
odk odk.buildall odk.perfcheck odk.uicheck odk.all odk.check odk.screenshot odk.unitcheck odk.allbuild odk.checkall odk.showdeliverables odk.allcheck odk.clean odk.slowcheck odk.build odk.coverage odk.subsequentcheck
Each of the above is related to a specific task, in which many of them are common on different modules. Let’s discuss some of them:
make odk
-> Builds odk module.
make odk.clean
-> Cleans the odk module, removing the generated files.
make odk.check
-> Runs test in odk module
make odk.uicheck
-> It runs UI tests inside odk module
make odk.perfchek
-> Runs performance/callgrind tests inside odk module
make odk.screenshot
-> Creates screenshots inside odk module
To get a complete list and detailed description, run make help
.
Sometimes because of OS crash or power outage, you may face problems when a build is stopped forcefully. In that case, you may see several zero byte object (*.o) files that exist, and prevent a successful build. In that case, you can find and remove them using this command:
$ rm `find -name *.o -size 0`
After that, you can retry your build without the above problem.
The process of creating Makefile starts from configuring LibreOffice for build. This is done by invoking ./autogen.sh
. The configuration parameters are read from autogen.input
. The build configuration is done via configure.ac
, which is an input for GNU autoconf.
There are various steps before the Makefiles are generated. For example, in order to make sure that a library is there when configuring the build, a very small C/C++ file is created, compiled and tested to ensure that the library is ready, and available to use with C/C++ code.
It is also possible to check for some specific version of library, and available functions. As an example, see this patch, which checks for specific version of ZXing library:
In the above example, multiple situations are handled:
1) When there is no ZXing library
2) When system ZXing library is used
And also, it is checked that specific version of ZXing is available:
1) When ZXing::ToSVG
is not usable
2) When ZXing::ToSVG
is usable
Then, the HAVE_ZXING_TOSVG
symbolic constant is used in config_host/config_zxing.h.in
, which can be used in C++ code.
If you are interested in knowing more about gbuild, you can start from my first post on gbuild in this blog. I plan to write more about gbuild, and describe some of the frequently used macros.
Also, you can take a look at the article devoted to gbuild in the TDF Wiki:
Read the restIn the first blog post on LibreOffice build system, gbuild
which uses GNU Make, I discussed some of the features of it. Here I discuss more about some gbuild tips and tricks that you may need.
In order to build a single module, you need to use its name. For example, to build only “odk”, which contains office development kit, you only have to type:
make odk
On the other hand, there are many other build targets associated with odk. By typing make odk, and then pressing tab, you will see this list, which shows possible targets:
odk odk.buildall odk.perfcheck odk.uicheck odk.all odk.check odk.screenshot odk.unitcheck odk.allbuild odk.checkall odk.showdeliverables odk.allcheck odk.clean odk.slowcheck odk.build odk.coverage odk.subsequentcheck
Each of the above is related to a specific task, in which many of them are common on different modules. Let’s discuss some of them:
make odk
-> Builds odk module.
make odk.clean
-> Cleans the odk module, removing the generated files.
make odk.check
-> Runs test in odk module
make odk.uicheck
-> It runs UI tests inside odk module
make odk.perfchek
-> Runs performance/callgrind tests inside odk module
make odk.screenshot
-> Creates screenshots inside odk module
To get a complete list and detailed description, run make help
.
Sometimes because of OS crash or power outage, you may face problems when a build is stopped forcefully. In that case, you may see several zero byte object (*.o) files that exist, and prevent a successful build. In that case, you can find and remove them using this command:
$ rm `find -name *.o -size 0`
After that, you can retry your build without the above problem.
The process of creating Makefile starts from configuring LibreOffice for build. This is done by invoking ./autogen.sh
. The configuration parameters are read from autogen.input
. The build configuration is done via configure.ac
, which is an input for GNU autoconf.
There are various steps before the Makefiles are generated. For example, in order to make sure that a library is there when configuring the build, a very small C/C++ file is created, compiled and tested to ensure that the library is ready, and available to use with C/C++ code.
It is also possible to check for some specific version of library, and available functions. As an example, see this patch, which checks for specific version of ZXing library:
In the above example, multiple situations are handled:
1) When there is no ZXing library
2) When system ZXing library is used
And also, it is checked that specific version of ZXing is available:
1) When ZXing::ToSVG
is not usable
2) When ZXing::ToSVG
is usable
Then, the HAVE_ZXING_TOSVG
symbolic constant is used in config_host/config_zxing.h.in
, which can be used in C++ code.
If you are interested in knowing more about gbuild, you can start from my first post on gbuild in this blog. I plan to write more about gbuild, and describe some of the frequently used macros.
Also, you can take a look at the article devoted to gbuild in the TDF Wiki:
LibreOffice 24.2 – with a new year.month versioning scheme – will be released as final at the beginning of February, 2024 ( Check the Release Plan ) being LibreOffice 24.2 Release Candidate 2 (RC2) the forth pre-release since the development of version 24.2 started in mid June, 2023. Since the previous release, LibreOffice 24.2 RC1, 113 commits have been submitted to the code repository and 61 issues got fixed. Check the release notes to find the new features included in this version of LibreOffice.
LibreOffice 24.2 RC2 can be downloaded for Linux, macOS and Windows, and it will replace the standard installation.
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 Matrix.
LibreOffice is a volunteer-driven community project, so please help us to test – we appreciate it!
Happy testing!!
LibreOffice 24.2 – with a new year.month versioning scheme – will be released as final at the beginning of February, 2024 ( Check the Release Plan ) being LibreOffice 24.2 Release Candidate 2 (RC2) the forth pre-release since the development of version 24.2 started in mid June, 2023. Since the previous release, LibreOffice 24.2 RC1, 113 commits have been submitted to the code repository and 61 issues got fixed. Check the release notes to find the new features included in this version of LibreOffice.
LibreOffice 24.2 RC2 can be downloaded for Linux, macOS and Windows, and it will replace the standard installation.
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 Matrix.
LibreOffice is a volunteer-driven community project, so please help us to test – we appreciate it!
Happy testing!!
Using comments is a key feature in text processing. A typical workflow might be to review a document where notes are made by different colleagues. LibreOffice Writer currently shows these comments in the document margin, which is limited to the page height, ending up in the need to scroll long text (even while editing [1]) and eventually in paging-like interactions if the number of comments exceed the total size.…
Using comments is a key feature in text processing. A typical workflow might be to review a document where notes are made by different colleagues. LibreOffice Writer currently shows these comments in the document margin, which is limited to the page height, ending up in the need to scroll long text (even while editing [1]) and eventually in paging-like interactions if the number of comments exceed the total size.…
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
453 bugs, 71 of which are enhancements, have been reported by 283 people.
412 bugs have been triaged by 64 people.
438 bugs have been set to RESOLVED.
Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
153 bugs have been fixed by 32 people.
List of critical bugs fixed
List of high severity bugs fixed
List of crashes fixed
List of old bugs ( more than 4 years old ) fixed
Kudos to Ilmari Lauhakangas for helping to elaborate this list.
453 bugs, 71 of which are enhancements, have been reported by 283 people.
412 bugs have been triaged by 64 people.
438 bugs have been set to RESOLVED.
Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.
153 bugs have been fixed by 32 people.
List of critical bugs fixed
List of high severity bugs fixed
List of crashes fixed
List of old bugs ( more than 4 years old ) fixed
LibreOffice 24.2 – with a new year.month versioning scheme – will be released as final at the beginning of February, 2024 ( Check the Release Plan ) being LibreOffice 24.2 Release Candidate 1 (RC1) the third pre-release since the development of version 24.2 started in mid June, 2023. Since the previous release, LibreOffice 24.2 Beta1, 158 commits have been submitted to the code repository and 59 issues got fixed. Check the release notes to find the new features included in this version of LibreOffice.
LibreOffice 24.2 RC1 can be downloaded for Linux, macOS and Windows, and it will replace the standard installation.
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 Matrix.
LibreOffice is a volunteer-driven community project, so please help us to test – we appreciate it!
Happy testing!!
LibreOffice 24.2 – with a new year.month versioning scheme – will be released as final at the beginning of February, 2024 ( Check the Release Plan ) being LibreOffice 24.2 Release Candidate 1 (RC1) the third pre-release since the development of version 24.2 started in mid June, 2023. Since the previous release, LibreOffice 24.2 Beta1, 158 commits have been submitted to the code repository and 59 issues got fixed. Check the release notes to find the new features included in this version of LibreOffice.
LibreOffice 24.2 RC1 can be downloaded for Linux, macOS and Windows, and it will replace the standard installation.
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 Matrix.
LibreOffice is a volunteer-driven community project, so please help us to test – we appreciate it!
Happy testing!!
This post is part of a series to describe how Writer now gets a feature to handle tables that are both floating and span over multiple pages.
This work is primarily for Collabora Online, but is useful on the desktop as well. See the 10th post for the previous part.
Previous posts described the hardest part of multi-page floating tables: making sure that text can wrap around them and they can split across pages. In this part, we'll look at a case where that content is not just text, but the wrapping content itself is also a table.
Regarding testing of the floating table feature in general, the core.git repository has 92 files now
which are focusing on correct handling of floating tables (filenames matching
floattable-|floating-table-
). This doesn't count cases where the document model is built using C++
code in the memory and then we assert the result of some operation.
Here are some screenshots from the improvements this month:
The first screenshot shows a situation where the mouse cursor is near the right edge of the first page of a floating table. What used to happen is we found this position close to the invisible anchor of the floating table on that page, then corrected this position to be at the real anchor on the last page. In short, the user clicked on one page and we jumped to the last page. This is now fixed, we notice that part of the floating table is close to the click position and we correct the cursor to be at the closest position inside the table's content.
The next screenshot shows a floating table where the content wrapping around the table happens to be an inline table. You can see how such wrapping didn't happen in the past, and the new rendering is close to the reference now.
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 small changes:
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the 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 (24.8).
This post is part of a series to describe how Writer now gets a feature to handle tables that are both floating and span over multiple pages.
This work is primarily for Collabora Online, but is useful on the desktop as well. See the 9th post for the previous part.
Previous posts described the hardest part of multi-page floating tables: reading them from documents, so we layout and render them. In this part, you can read about UI improvements when it comes to creating, updating and deleting them in Writer.
Regarding testing of the floating table feature in general, the core.git repository has 89 files now which are focusing on correct
handling of floating tables (filenames matching floattable-|floating-table-
). This doesn't count
cases where the document model is built using C++ code in the memory and then we assert the result
of some operation.
Here are some screenshots from the improvements this month:
The first screenshot shows that the underlying LibreOffice Insert Frame dialog is now async (compatible with collaborative editing) and is now exposed in the Collabora Online notebookbar.
There were other improvements as well, so in case you select a whole table and insert a new frame, the result is close to what the DOCX import creates to floating tables. This includes a default frame width that matches the table width, and also disabling frame borders, since the table can already have one.
The next screenshot shows an inserted floating table, where the context menu allows updating the properties of an already inserted floating table, and also allows to delete ("unfloat") it.
Several of these changes are shared improvements between LibreOffice and Collabora Online, so everyone benefits. For example, inserting a frame when a whole table was selected also cleared the undo stack, which is now fixed. Or unfloating table was only possible if some part of the table was clipped, but now this is always possible to do.
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 small changes:
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the 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 (24.2).
(And do you have a vacancy for a back-scrubber?)
Thank you, Red Hat, for generously letting me work for so long on stuff that is near and dear to my heart. At the intersection of theory and practice, of compiler technology and the LibreOffice code base. But, to keep doing what I love, I need to move on.
So, thank you, allotropia, for having me. I’m excited.
And, above all, thank you, LibreOffice, family of friends. Lets make sure to keep this a happy family, one that Tolstoy would have nothing to write home about. With quarrels and arguments, for sure; feud even. But happy at heart. I wish to keep meeting you all for years to come, virtually, and for a feast at FOSDEM or LOCon. And booze.
To paraphrase Hamburger Tafel (donations needed, btw), “Wir haben LibreOffice noch lange nicht satt.”
Have fun, stay safe, peace,
sberg
Hello LibreOffice Planet!
This is my first blog post on the topic of LibreOffice. Let me quickly explain my link to LibreOffice. I work for a data protection authority in the EU and help navigate the digital transformation of our office with about 100 staff members. While many of our partner organisations adopt Microsoft 365, our office decided to pilot Nextcloud with Collabora Office Online.
In the future, I want to blog (in my personal capacity) about my thoughts related to the use of alternative word processing software in the public sector in general and in our specific case.
As there are no dedicated resources for training, preparation of templates etc., during the pilot of LibreOffice, the experience so far covers a large spectrum of user satisfaction. Generally, our staff has been spent years of their life using Microsoft Office and has the expectation that any other software works the same way. If it does not, they send an email to me (best case) or switch back to Microsoft Office.
During the week, I discussed again some smaller LibreOffice bugs. Then, I showed this weekend some FOSS Blender animated short videos to family members. It seems that Blender is more successful in its domain than LibreOffice. Is that possible? Or are animated short videos just more capturing due to their special effects? 😅
You can watch the 1min Blender animated short movie “CREST� on Youtube or the making-off. The latter you find here below.
I find it very inspiring to see what talented artists can do with Blender. For my part, I have once installed Blender and deinstalled it. Back then it was not easy to use for people not familiar with video animation software. Blender competes with proprietary software such as Maya or Cinema 4D. The latter is about 60Â USD per month in the annual subscription plan. Not exactly cheap.
Then, I read in the fediverse about people working with LibreOffice:
I just tried to use #LibreOffice #Draw to draw some arrows and boxes onto JPEG images for emphasizing stuff.
The UX is really bad for somebody not working with Draw all the time.
Whatever I do, instead of drawing onto the image, the image gets selected instead.
Could not find any layer-sidebar.
Could not scale text without starting the “Character …� menu, modifying font size blindly + confirming > just to see its effect and then start all over.
Dear #FOSS, we really should do better.
— Author Karl Voit (12 November 2023 at 14:51)
In my past, I have worked on online voting systems. They are not very good yet despite years of efforts. xkcd dedicated a comic to voting software
Elections seem simple—aren’t they just counting? But they have a unique, challenging combination of security and privacy requirements. The stakes are high; the context is adversarial; the electorate needs to be convinced that the results are correct; and the secrecy of the ballot must be ensured. And they have practical constraints: time is of the essence, and voting systems need to be affordable and maintainable, and usable by voters, election officials, and pollworkers.
— Author Matthew Bernhard et al. in their paper Public Evidence from Secret Ballots from 2017
What is the unique challenge of developing word processing software? Happy to hear back from you in the blog comments or on the companion fediverse post!
This post is part of a series to describe how Writer now gets a feature to handle tables that are both floating and span over multiple pages.
This work is primarily for Collabora Online, but is useful on the desktop as well. See the 8th post for the previous part.
Multi-page floating tables always wrapped their anchor text only on the last page, to be compatible with Word's default behavior. There is a special flag in DOCX files to wrap on all pages, though. In this part, you can read about handling of this flag in Writer.
Regarding testing of the floating table feature in general, the core.git repository has 84 files now which are focusing on correct
handling of floating tables (filenames matching floattable-|floating-table-
). This doesn't count
cases where the document model is built using C++ code in the memory and then we assert the result
of some operation.
Here are some screenshots from the fixes this month:
The first screenshot shows a case where multi-page floating tables are nested. For this document, we not only have an inner and an out table, but we also have a middle one, giving us 3 nesting tables. Some of the inner table frames had a bad position, leading to overlapping text, now fixed.
The next screenshot shows the case where the magic allowTextAfterFloatingTableBreak
flag is set.
We used to wrap content of the anchor only on the last page, unconditionally. Now we either wrap on
the last page (default) or on all pages (when this flag is present).
The last screenshot shows a document full of floating tables. These used to be inline ones, and then they could not overlap by definition, but now extra effort was needed to position them in a way that no overlap happens between the tables. Now our render result matches Word.
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 small changes:
You can get a snapshot / demo of Collabora Office 23.05 and try it out yourself right now: try the 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 (24.2).
I attended LibreOffice Conference Asia x UbuCon Asia 2023 (LOUCA23) in Surakarta, Indonesia, on October 7~8.
This was the second time LibreOffice Conference Asia has been held in Tokyo in 2019, as it could not occur due to the COVID-19 pandemic. UbuCon Asia was first held online in 2021, and the first in-person event was held in Seoul, Korea in 2022, and this still was the second in-person event.
I was burnt out by the pandemic and had stopped most of my OSS activities, but I still had many friends in the OSS world, so I went to Indonesia to meet with them.
Therefore, I had initially intended to be a general participant. Still, a friend of the speaker was suddenly unable to attend due to illness, so I gave a presentation in his place. Here is my slide:
As mentioned, I am halfway out of OSS activities, but I know what my friends are doing, so it was not so difficult to talk about this subject.
Although I cannot say that the presentation itself was a great success (due to my English language skills), I was pleased because the audience was very responsive and easy to talk to, and many people approached me after the presentation was over.
Other than my presentation, I was naturally interested in the two keynote speeches by The Document Foundation and was surprised and grateful when Franklin Weng mentioned my name as an "Asian activist to be featured at the LibreOffice Latin America Conference. "
I listened to Muhammad Syazwan Md Khusaini's "Hands-On on Translating in Ubuntu" with great interest; however, I was a bit surprised to hear from a friend that many Indonesians use English for desktop environments and applications like LibreOffice. I recognized that this was quite different from Japan.
The event itself was just as enthusiastic. Unlike OSS events in Japan (laugh), the participants were young, and there were many women. I was also surprised to see junior high school students among the speakers.
Both lunch and dinner were complimentary, and the one-day Surakaruta city tour the day after the event was delightful. I appreciated the hospitality of the local staff.
This was my first time in Indonesia, and although short, I enjoyed many things, including the train trip. In Yogyakarta, I visited a museum and learned a lot about the history of Indonesia. However, I was overcharged by the tuk-tuk in Yogya.
I know it was a lot of work for the organizers, but as I have many friends in LibreOffice and am also an Ubuntu user, I was very grateful that the two events were co-hosted. Thanks to all the sponsors, global/local organizers, and everyone who talked to me there. See you soon!
LibreOffice is a complex application with a large and growing number of options. It is not easy to find the right needle in the haystack. Like most other complex applications, it will be valuable and useful enhancement to add a search field to the “Tools > Options” dialog that iterates over the various tabs and filters where the search text is found. The Search Field in Options project aims to provide this search functionality in “Tools > Options” page.
GetAllStrings()
method to fetch strings from 69 dialogs step by stepsalhelper::Thread
- asynchronously)_
) and Tilde (~
) symbols from fetched strings to make the search function work correctlyDuring 13 weeks GSoC program, I added a search field in Options dialog and included the node names and their .ui strings into searching. Since sub-dialogs under the Options are not initialized at startup of Options dialog, it was not possible to access their .ui strings. To overcome this issue we had two options:
When I felt that Option A is just wasting my time (~5 weeks); I switched to Option B where I can -at least- make some progress. The main issue in Option B was initializing all dialogs which takes about 4-8 secs. I tried to initialize them at background but there was some errors on Win10 that I don’t reproduce the issue on my linux machine. Then I tried to see the errors on Win10 with a virtual machine, but it was too slow to test. Therefore I uninstalled Manjaro/Linux (which I’ve been using it more than 1.5 years) from my computer and had to install Win10 (which I last used 6 years ago) on my machine to see the problems in there. There was some visual inconsistencies while initializing sub-dialogs using salhelper::Thread
at background.
After working long hours for weeks meanwhile the time was running out, I decided to initialize almost half of them at Options dialog startup and the remaining ones at the time of searching. In that way, time of initializing process is divided by ~2 which can be acceptable time in some degree in terms of user experience.
There is a single patch on Gerrit for this project: https://gerrit.libreoffice.org/c/core/+/152519. The patch has more than 30 patchsets and includes “+2255 -47” changes.
The most challenging part was implementing GetAllStrings() function for every ~69 dialogs step by step. Current implementation may not be the best solution for user experience, but at least searching through the numerous options is now possible.
Following tasks are left and can be implemented after GSoC:
salhelper::Thread
- asynchronously)I’m very happy that we all reached the end of GSoC. During that time, I know that I had a responsibility for doing everything that I can. Therefore I worked hard and tried to complete as much tasks as I can.
I learned a lot of things during the GSoC. Although GSoC is finished, I will definitely continue to contribute to LibreOffice. I am really happy to be a part of the LibreOffice community and Google Summer of Code. I’m really thankful to LibreOffice and Google for providing us this such a great opportunity which helped me gain this amazing experience!
I always tried to be active on IRC #libreoffice-dev channel, and I want to thank for everybody who helped me about my questions.
And most importantly, greatly thankful to Andreas Heinisch and Heiko Tietze who were my mentors throughout the GSoC period. They always guided me everything about my questions. Thank you endlessly for your time and effort. I appreciate that you always motivating and encouraging me in all that I attempt and do. I can never truly express how grateful I am. Your guidance, reviews, help and shared experiences have been invaluable. Thank you very much for everything.
I’d like to express my gratitude to everyone in the LibreOffice community for their help and kindness. They always tried to answer my questions on IRC. I fell very lucky to work with this amazing community. I have learned a lot from you and I will never forget this wonderful experience.
Regards,
Bayram Çiçek
All weekly GSoC reports:
Useful links:
Writer supports Small Caps, but Impress and drawing shapes in general never fully supported Small Caps. The option was available, and the character dialog provided a preview, but Small Caps was rendered the same as All Caps, as seen here.
This has lingered for years and it's not easy as a user to try and manually workaround with varying font sizes because underline/overline/strike-through decorations won't link up, as seen in this example:
to:
Also noticed during all of this was the wrong width scaling used for the red wave line underneath incorrect spelling in impress when the text is superscript or subscript so the line didn't stretch over the whole text, as seen here:
Now corrected as:
and finally added was a missing implementation in the RTF export of shape text to allow the small caps format to be copy and pasted into other applications from impress.