Home » LibreOffice » Page 85

Category: LibreOffice

Community Member Monday: Jessé Moreira

Love LibreOffice too? Want to help us spread the word about it, and other free and open source software (FOSS) projects? Then we appreciate your help! Everyone can raise awareness about the importance of FOSS and open standards, like the OpenDocument Format, LibreOffice’s native format.

For instance, Jessé Moreira from the Brazilian Portuguese LibreOffice community has created a set of tutorial videos. Here’s what he has to say:

Hello! I am a high school math teacher. I love LibreOffice and make videos demonstrating educational software applications. I have a channel that talks about libreoffice in Portuguese on Odysee and YouTube.
I intend to continue promoting LibreOffice by recording videos and contributing to the incredible project. Greetings from Brazil!

Thanks, Jessé! We have more videos created by other community members too. Recently, we talked to Harald Berger from the German community about how he makes his tutorials. To anyone reading this who also wants to contribute videos in their language, drop us a line and let’s work together!

And one more thing: Jessé recently became a Member of The Document Foundation, the non-profit entity behind LibreOffice. This means that he can help to steer the project and vote for the Board of Directors, amongst other things. All LibreOffice contributors are welcome to become Members and help us to keep doing awesome things:

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

YouTube privacy policy

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

Fixing an Interoperability Bug in LibreOffice: Missing Lines from DOCX (part 2/3)

By Hossein Nourikah, Developer Community Architect at The Document Foundation

In LibreOffice, interoperability is considered a very important aspect of the software. Today LibreOffice can load and save various file formats from many different Office applications from different companies across the world. But, bugs are inevitable parts of every software: There are situations where the application does not behave as it should, and a developer should take action and fix it, so that it will behave as it is expected by the user.

What if you encounter a bug in LibreOffice, and how a developer fixes the problem? In these series of articles, we discuss the steps needed to fix a bug. In the end, we will provide a test and make sure that the same problem does not happen in the future, again.

The article is presented in three parts:

  1. Understanding the Bugs and QA
  2. Developing a Bug Fix
  3. Writing the Tests and Finishing the Task

This is the second part.

2. Developing a Bug Fix

So, if you have read the previous part of “Fixing an Interoperability Bug: Missing Lines in Save and Load” (part 1), this is the sequel. Here we try to develop a solution for the problem with our knowledge of C++.

The first thing we need is to build the LibreOffice core. Depending on the platform, you can find the instructions in the TDF wiki.

See the instructions for building LibreOffice on:

2.1. Finding the Responsible Change

So, now we know that through this commit, these files were changed. One (or possibly all) of the changes is responsible for the regression. So we try to find a minimize set of changes that lead to the problem. We can use --name-only option from git:

$ git show d72e0cadceb0b43928a9b4f18d75c9d5d30afdda --name-only

So, the changed files are:

  1. filter/source/msfilter/escherex.cxx
  2. filter/source/msfilter/msdffimp.cxx
  3. include/svx/msdffdef.hxx
  4. sw/qa/extras/ww8export/data/tdf91687.doc
  5. sw/qa/extras/ww8export/ww8export2.cxx
  6. sw/source/filter/ww8/wrtw8esh.cxx

Sometimes we have to go back to this specific commit using git checkout command to be able to work on the exact commit before the one that created the bug. But, most of the time, reverting the specific commit is easier, and the build will be much faster. Also, building older versions of LibeOffice is tricky. We can instead invoke this command:

$ git revert d72e0cadceb0b43928a9b4f18d75c9d5d30afdda

Now we should try to resolve the possible conflicts, then build the code and make sure the problem has gone away! Then we can try to re-introduce one or more changes to achieve a minimal set of changes that reproduces the problem.

We can start at the file level to find the relevant files to work on. Files 4 and 5 are related to the tests, so they should have no impact. File 1 and 2 seem to be related, as both are from filter/source/msfilter folder, file 3 is also related to these two files. After leaving out all the files, we see that changes from 6 (sw/source/filter/ww8/wrtw8esh.cxx) is enough to reproduce the problem. So, we have few lines of code changes in front of us:

@@ -756,7 +756,12 @@ void PlcDrawObj::WritePlc( WW8Export& rWrt ) const
                OSL_ENSURE(pObj, "Where is the SDR-Object?");
                if (pObj)
                {
-                   aRect = pObj->GetSnapRect();
+                   aRect = pObj->GetLogicRect();
+
+                    // We have to export original size with padding
+                    const SfxItemSet& rSet = pObj->GetMergedItemSet();
+                    const SdrMetricItem* pItem = static_cast(rSet.GetItem(SDRATTR_TEXT_UPPERDIST));
+                    aRect.SetSize(Size(aRect.GetWidth(), aRect.GetHeight() + pItem->GetValue()));
                }
            }

If we work further on this piece of code, we will find that the change from pObj->GetSnapRect() to pObj->GetLogicRect() is the source of regression: Good catch!

2.2. Creating a Fix

As described in the previous section, going back to pObj->GetSnapRect() fixes the problem, but wait! Isn’t that change supposed to fix a problem?

(GOOD)

(BAD)

Figure 1: Wrong increase of watermark size
after save and reload

If we go back to git master using:

git reset --hard HEAD^1

and then only change pObj->GetSnapRect() to pObj->GetSnapRect(), this test fails with the change. Try:

$ make CPPUNIT_TEST_NAME="testTdf91687" -sr CppunitTest_sw_ww8export2

If we take a look at the tdf#91687 in the Bugzilla, we see the example sw/qa/extras/ww8export/data/tdf91687.doc that contains a watermark (Figure 1) that gets bigger by save and reload! Looking more carefully to the changes, it becomes clear that rotation is important here. If we change the watermark example in order to set rotation to zero, nothing happens.

This is not limited to watermarks: Saving and re-loading any custom shape leads to such a wrong increase in size. On the other hand, this does not have any effect on the lines, rotated or not.

2.3. Fixing the Side Effects

In order to fix the undesired side effects, we should make a difference between the lines and the complex shapes. So, what is the difference? If we look closely to the code, we find out that pObj object is from SdrObj class, which is abstract DrawObject. The documentation for this class can be found here:
https://docs.libreoffice.org/svx/html/classSdrObject.html

Figure 2. Class hierarchy for SdrObject

So, objects from different SdrObject subclasses are sent here, and appropriate GetSnapRect() or GetLogicRect() is called. But which method? According to the runtime polymorphism, this is determined at runtime. So without debugging, nothing becomes clear.

By setting a break-point at this modified line and stepping into the GetLogicRect() function, it becomes clear that two types of object are created for the shapes:

  • pObj is SdrObjCustomShape (x4): representing 4 ellipeses
  • pObj is SdrPathObj (x5): representing 5 lines

So, the trick would be creating a GetLogicRect() method for SdrPathObj and make it invoke GetSnapRect(). In this way, lines and custom shapes are treated differently.

We declare GetLogicRect() in include/svx/svdopath.hxx:

virtual const tools::Rectangle& GetLogicRect() const override;

and add its implementation in svx/source/svdraw/svdopath.cxx:

const tools::Rectangle &SdrPathObj::GetLogicRect() const
{
    return GetSnapRect();
}

Then we rebuild the LibreOffice by invoking make, and then start the LibreOffice from instdir/program/soffice. After loading, saving, and re-loading the example DOCX file, we see that this fix actually works!

In the third part, we are going to talk about the steps needed to get our changes merged into the LibreOffice Code. If you want to get involved in LibreOffice development, it is suggested that you join the LibreOffice development mailing list. See the instructions here.

Hossein Nourikhah is the Developer Community Architect at the The Document Foundation (TDF), the non-profit behind LibreOffice. If you need assistance getting started with LibreOffice development, you can get in touch with him:

E-Mail: hossein@libreoffice.org

IRC: hossein in the IRC channel #libreoffice-dev on the Libera.Chat network connect via webchat

LibreOffice project recap: July 2021

Check out our summary of what happened in the LibreOffice community last month…

  • We started July by welcoming allotropia to The Document Foundation’s Advisory Board. Founded in late 2020 with five long-time LibreOffice developers, allotropia’s stated mission is to bring LibreOffice to shine – in as many different shapes and forms as necessary, to serve the modern needs of office productivity software. allotropia was spun off from CIB, another long-time provider of LibreOffice-based products and services (and also a member of the Advisory Board).

  • On the very same day, our documentation team announced the LibreOffice Getting Started Guide 7.1. Covering all LibreOffice modules, from the Calc spreadsheet to the Base database and including chapters on the suite settings as well as macro coding, the Getting Started Guide 7.1 is a valuable companion for organizations that want to deploy documentation on LibreOffice together with the software suite on their offices and also at user’s homes.

  • Meanwhile, we chatted with Tim Brennan Jr. from the Brazilian LibreOffice community. He’s on the Brazilian Portuguese translation and editing team, and recently decided to become a Member of The Document Foundation. Welcome, Tim!

  • Then the Spanish-speaking community held an online meeting with video talks streamed live. The activity was attended by several members, who are recognized for their participation and collaboration in the project.

  • Looking for LibreOffice tutorial videos? We have playlists in English, German and French – but the videos don’t just happen by magic. They’re created by volunteers, so we asked Harald Berger how he makes the German videos. Check it out, and help us to make more!

  • LibreOffice 7.2 is tantalisingly close; it’s due to be released in the middle of this month. We held a Bug Hunting Session for the first release candidate, to identify and squash any last bugs before it goes live.

  • Our LibreOffice New Generation project aims to bring new – and especially younger – contributors into the LibreOffice community. Earlier in the year, we created a flyer for schools and universities, and we’ve sent out printed versions to many people around the world. Now, here’s an alternative design, thanks to Rizal Muttaqin and the Indonesian community!

  • LibreOffice’s documentation team is driven by volunteers around the world. We wanted, we want to say a special thanks to members of the Brazilian Portuguese community, who’ve worked hard to translate and update user guides. So we sent out Open Badges – special, customised badges with embedded metadata, describing their achievements.

  • Our second community interview in the month was with Jackson Cavalcanti Junior, who told us about his work in the documentation project.

  • Release-wise, we had one update in July: LibreOffice 7.1.5 with 55 bugfixes and compatibility improvements.

  • The LibreOffice Conference 2021 is coming up: check out the sponsorship package. The event will run online again this year, due to the ongoing pandemic situation, from September 23 – 25.

  • Just before the end of the month, the documentation team announced another guide: the Draw Guide 7.1. This covers all aspects of the image-editing component of the suite. Great work, everyone!

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

LibreOffice Conference 2021: Announcing the logo!

In late June, we started a competition to design the logo for our upcoming LibreOffice Conference 2021. We received 22 submissions with many great ideas – thanks to everyone who took part!

The conference organisers examined every design and ranked them, and today we’re announcing the winner, which is created by Alan Ward. Here’s how it looks:

Alan also provided a simplified monochrome version which can be used on merchandise – stay tuned to this blog for more on that. And here’s what he had to say about the design:

This design is inspired by the theme of a community coming together to share common experience. The hexagonal grid motif suggests networking from a technical and a human standpoint. The viewer’s attention is drawn to the LibreOffice emblem, as a focal point in the center. Colors have been chosen from a palette derived from the official LibreOffice typography, to suit both light and dark backgrounds.

Several versions of the logo have been prepared, to suit different applications. These include both full color and monochrome versions, in both hi and low resolution. High resolution printing process can reproduce thinner lines correctly (eg printed documents, PDF files). However, the use of several colors increases production costs or may not be available, so a simple monochrome may be required as an alternative to full-color. Either color or monochrome hires versions of the logo may easily be adapted as a base for a themed wallpaper.

Low-resolution printing processes such as those used to print T-shirts or engrave metal or wood articles require the use of relatively bold lines to show up correctly on the finished product. This is why a simple design with few elements is most effective in this situation. The use of several colors also increases production costs, so a simple monochrome approach is perhaps best for these applications. The monochrome design can easily be adapted for different colors of the support material (e.g. T-shirts in white, gray, black).

Thanks again to Alan for his design – a magic box of LibreOffice goodies is on his way to him! And thanks to everyone else for their submissions (we’ll get in touch and send you some LibreOffice stickers). Even though we had to choose one design in the end, there were plenty of great and creative ideas, and we really appreciate the input.

Now, onwards and upwards to the conference! Keep an eye on this blog for more updates…

Fixing an Interoperability Bug in LibreOffice: Missing Lines from DOCX (part 1/3)

By Hossein Nourikah, Developer Community Architect at The Document Foundation

In LibreOffice, interoperability is considered a very important aspect of the software. Today, LibreOffice can load and save various file formats from many different office applications from different companies across the world. But bugs are inevitable parts of every software:there are situations where the application does not behave as it should, and a developer should take action and fix it, so that it will behave as it is expected by the user.

What if you encounter a bug in LibreOffice, and how does a developer fix the problem? In these series of articles, we discuss the steps needed to fix a bug. In the end, we will provide a test and make sure that the same problem does not happen in the future.

The article is presented in three parts:

  1. Understanding the Bugs and QA
  2. Developing a Bug Fix
  3. Writing the Tests and Finishing the Task

This blog post is the first part.

1. Understanding the Bugs / QA

Bugs can be found in any software and in a broader view, every technological product. There are situations that a system behaves in a way that the user does not like or expect, and then the engineers come in, take action and fix that. It is proven that no software can be completely bug-free, because there is no exact way to describe all the aspects of a software, even mathematically using formal methods.

Although we can not avoid the bugs completely, we can improve the situation. The important thing here is to document these bugs, reproduce them using sample documents, investigate the cause(s), and hopefully fix them as soon as possible while considering the priority. The whole process of dealing with the bugs and improving the quality of the software is is called: “Quality Assurance”, or simply “QA”.

You can take a look at LibreOffice Wiki QA section and ask QA questions in the IRC channel #libreoffice-qa on the Libera.Chat network connect via webchat

1.1. Bug Report

So, you have encountered a problem in the LibreOffice! In this case, first of all you should try to report the bug to Bugzilla. If a bug is not recorded in Bugzilla, there is a little chance that it will be fixed.

So, everything starts with a bug report in TDF’s Bugzilla. A detailed explanation of what a good bug report should contain is available in the TDF Wiki: https://wiki.documentfoundation.org/BugReport

In short, a good bug report should have suitable summary for the problem, appropriate description and specific components/hardware/version for the context of the problem. Steps to reproduce the bug are important parts of every report, because a developer should be able to reproduce the bug in order to fix it.

The bug reporter should carefully describe the “actual results” and why it is different from the “expected results”. This is also important because the desired software’s behaviour is not always as obvious as it seems to be for the bug reporter.

Let’s talk about a regression bug that is recently fixed. The “NISZ LibreOffice Team” reported this bug. The National Infocommunications Service Company Ltd. (NISZ) has an active team in LibreOffice development and QA.

This is the bug title and description provided by the NISZ LibreOffice Team:

Bug 123321 – FILEOPEN | DOC, missing longer line when saved in LO (shorter line remains)

https://bugs.documentfoundation.org/show_bug.cgi?id=123321
Description:
When the attached original document gets saved in LO as doc the middle line gets its length resized.

Steps to Reproduce:

  1. Open the attached doc in LO.
  2. Save it as doc.
  3. Reload.
  4. Notice the changes.

Actual Results: The middle arrow gets smaller.
Expected Results: It should stay the same size even after saving in LO.
Reproducible: Always
User Profile Reset: No

Every bug has a number associated to it, and at TDF Bugzilla, it is referred to by its number, like tdf#123321.

1.2. Bug Confirmation

After a bug is reported, it is needed that someone else check and see If it is reproducible or not. If so, the bug is then confirmed and its status will be set to “New”. In this case, a user named Timur from the QA team of volunteers has confirmed this bug. It is needed that someone else other than the original bug reporter confirms the bug report.

Here, the bug reporter has provided several examples:

Attachments

  • The original file (39.50 KB, application/msword)
  • The saved file. (24.00 KB, application/msword)
  • Screenshot of the original and exported document side by
    side in Writer. (298.50 KB, image/png)
  • Minimized test document in docx format (19.66 KB,
    application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Opening the first file, we see that it contains several shapes. 4 ellipses, 2 diagonal lines, and a vertical line. But if we look closely, we find out that the vertical line actually consists of 3 different vertical lines. This can be understood by try selecting the line, and then pressing the tab to select the other lines.

The Shapelinelength_min.docx only contains 3 overlapped vertical lines (the overlap is not important).

  • First one on the top with the length 0.17″ (Verified in Word 2007)
  • Second one in the middle with the length of 1″ (Verified in Word 2007)
  • Third one at the bottom with the length of 2.77″ (Verified in Word 2007)

When you save it in LibreOffice and reload it, the first and the third vertical lines disappear, but if you select the second one (the only visible after save and reload), you can select the two other lines by pressing “tab” button. If you look at the size of these two lines, you will see that both have the length of 0″.

By opening the examples, saving and reloading them, we can verify that the bug is present even in the latest master build.

Images showing the bug

(Good)

(Bad)

Figure 1. The visible lines in the middle become smaller after save and reload

1.3. Bisect / Bibisect

Regression bugs are special kinds of bugs. They describe a feature that was previously working well, but at some point a change in the code has caused it to stop working. They are source of disappointment for the user, but they are easier to fix for the developers compared to other bugs! Why? Because every single change to the LibreOffice code is kept in the source code management system (Git), it is possible to find that which change actually introduced the bug.

Git has a special tool for this purpose, which is call bisect. It uses a binary search to find the commit that introduced the bug. But for LibreOffice which is a huge piece of software consisting of roughly 10 million lines of code, this can take a lot of time. So, a trick is used here: bisecting with the binaries! If you have access to every built LibreOffice for the commits, you can use git bisect command to find the source for problem in a very short time: This is called bibisect!

A very detailed description is on the wiki: https://wiki.documentfoundation.org/QA/Bibisect

Aron Budea from Collabora Productivity Ltd’s core engineering team did the bibisect, and now we know the exact commit that caused the problem:

Bibisected to the following commit using repo bibisect-win32-6.0.

https://git.libreoffice.org/core/+/d72e0cadceb0b43928a9b4f18d75c9d5d30afdda

Watermark: tdf#91687 correct size in the .doc

Export:
* Watermarks saved using Writer were very small in the MSO.
  Export fUsegtextFStretch property in the Geometry Text
  Boolean Properties.
* tdf#91687: SnapRect contains size of Watermark after rotation.
  We have to export size without rotation.

Import:
* When import set height depending on used font and width.
  Text will keep the ratio. Remember the padding for export.

* added unit test
* introduced enum to avoid magic numbers for stretch and best fit
  properties.

Change-Id: 
I3427afe78488d499f13c543ca401c096161aaf34
Reviewed-on: 
https://gerrit.libreoffice.org/38979
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>

This bug is a regression. The DOCX import/export was working well before this commit, but after that, it doesn’t work: Good catch!

In the second part of this series, we talk about how we can create a fix for the bug.

Hossein Nourikhah is the Developer Community Architect at the The Document Foundation (TDF), the non-profit behind LibreOffice. If you need assistance getting started with LibreOffice development, you can get in touch with him:

E-Mail: hossein@libreoffice.org

IRC: hossein in the IRC channel #libreoffice-dev on the Libera.Chat network connect via webchat

The Draw Guide 7.1 has arrived!

Led by Peter Schofield, the LibreOffice Documentation Team is proud to announce the release of the LibreOffice Draw Guide 7.1, the ultimate guide for LibreOffice Draw.

LibreOffice Draw produces anything from a quick sketch to a complex plan, and gives the means to communicate with graphics and diagrams. With a maximum page size of 300cm by 300cm, Draw is an excellent package for producing technical drawings, brochures, posters and many other documents. Draw manipulates graphical objects, group them, crop them, use objects in 3D and much more.

“The Draw guide update is long due in the set of LibreOffice Guides and I am happy to have coordinated the effort to bring it to the community. LibreOffice Draw is a powerful vector drawing tool plenty of resources and the Guide is the most comprehensive text on the features. I hope the Draw community will thrive with this book.”

Peter Schofield
Peter Schofield

The Draw Guide is available in PDF format and is part of the LibreOffice Library, a set of advanced guides for the LibreOffice productivity suite. Download other important LibreOffice guides in our Documentation website.

Meet the documentation team page!

Happy documenting!

Press Releases

Announcement of LibreOffice 25.8.4

Berlin, 18 December 2025 – LibreOffice 25.8.4, the fourth minor update to the free office suite developed by volunteers for…

Open Document Format

The importance of ODF during the festive season

To be honest, I didn't think I would publish my usual post about ODF over the festive period, as most…