Wednesday
25 September, 2024

Official TDF Blog: The Document Foundation announces the LibreOffice and Open Source Conference 2024

@ 19:49 UTC

Berlin, 25 September 2024 – The LibreOffice and Open Source Conference 2024 will take place in Luxembourg from the 10 to the 12 October 2024. It will be hosted by the Digital Learning Hub and the local campus of 42 Luxembourg at the Terres Rouges buildings in Belval, Esch-sur-Alzette.

This is a key event that brings together the LibreOffice community – supporting the leading FOSS office suite – with a large number of stakeholders: large open source projects, international organizations and representatives from EU institutions and European government departments.

Organized in partnership with the Luxembourg Media & Digital Design Centre (LMDDC), which will host the EdTech track, the event is sponsored by allotropia and Collabora, the two companies contributing more actively to the development of LibreOffice; Passbolt, the Luxembourg made open source password manager for teams; and the Interdisciplinary Centre for Security, Reliability and Trust (SnT) of the University of Luxembourg.

In addition, local partners such as Luxembourg Convention Bureau, LIST, LU-CIX and Luxembourg House of Cybersecurity are supporting the organization of various aspects of the conference.

After the opening session in the morning of the 10 October, which includes institutional presentations from the Minister for Digitalisation, the Ministry of the Economy and the European Commission’s OSPO, there will be tracks about LibreOffice covering development, quality, security, documentation, localization, marketing and enterprise deployments, and tracks about open source covering technologies in education, OSS applications and cybersecurity. Another session will focus on OSPOs (Open Source Programme Officers).

The LibreOffice and Open Source Conference Luxembourg 2024 provides a platform to discuss the latest technical developments, community contributions, and the challenges facing open source software and communities of which TDF, LibreOffice and its community are important components. Professionals, developers, volunteers and users from various fields will share their experiences and collaborate on the future direction of the leading office suite.

Policy and decision makers will find counterparts from all over Europe with which they will be able to exchange ideas and experiences that will help them to promote and implement open source software in public, education and private sector organizations.

On 11 and 12 October, there will also be workshops focusing on different aspects of LibreOffice development, targeted to undergraduate Computer Science students or anyone who knows programming, and wants to become familiar with a large scale real world open source software project. To be able to better support the participants we limited the number of seats to 20 so register for the workshops as soon as possible to reserve your place.

Everyone is encouraged to register and participate in the conference to engage with the open source community, learn from different experts and contribute to meaningful discussions. Please note that, to avoid waste, we will plan for food, drinks and other free items for registered attendees so help us to cater for your needs by registering in time.

Thursday
19 September, 2024

Björn Michaelsen: Nothing ever happens

@ 23:30 UTC

Nothing ever happens.

And nothing ever happens, nothing happens at all The needle returns to the start of the song And we all sing along like before -- Del Amitri, Nothing Ever Happens

In my last post on Libreoffice I promised to talk about Writer changes once in a while, but then ... nothing ever happened. However, given that I had an annoying motorcycle accident in the meantime that turned out much more persistently annoying than originally thought, I think I have a bit of an excuse.

So ... what did happen? For one, I fixed quite a few regressions with my name on them, but ... is there much to talk about here? Mostly not: If you look at the fixes, they are often oneliners fixing something that seems rather obvious in retrospect. The more tricky question is: how did these get in in the first place? Its hard for me to say that, as the introducing commits are from even longer ago.

One thing is certain though: Often a unittest would have caught them, so whenever possible, I tried to create a reproducer adding such a test with the fix. To anyone writing bug reports: Creating minimal reproduction test is hugely valuable in this -- not just for finding the issue, but also as a starting point for a regression test. So if a bug bugs you and it is missing a minimal reproduction scenario, adding one is a great way to move this forward. Oh, and maybe verifying a bugfix, if someone provided a fix and the friendly bot say affected users are "encouraged to test the fix and report feedback".

While doing these fixes, I stumbled over Noel suggesting to speed up bookmarks in writer which is of course great, but I noticed that the code could be optimized a bit more as the bookmarks of a document are now sorted by their starting position (which was one of the first changes I made back on OpenOffice.org about more than a decade ago). Thus we can use bisectional search on the bookmarks here, which should be even faster. Now, it would be great if the discussion on this between Noel and me would available for others to learn from, wouldnt it? The cool thing is: it is.

All discussion happened on gerrit in the comments so if you want to learn about bookmark in Writer and how to maybe speed them up for documents that have a lot of them, that is a great starting point! Is there anything to add? Well maybe the following: Currently the bookmarks starting at the same position are currently not sorted. If one would sort them by their end position, the bisectional search could maybe cover even more? This would also remove one extra loop of logic and make the code simpler and easier to read.

The performance improvement is likely irrelevant -- esp. since there will be not that many documents with lots of bookmarks starting at the same position. The simpler code might …

Monday
09 September, 2024

LibreOffice QA Blog: QA/Dev Report: August 2024

@ 15:23 UTC

General Activities

LibreOffice 24.8.0 was released on August 22
Olivier Hallot (TDF) continued with improvements to Calc function help pages, added help pages for Sidebar settings and graphics export via command line, improved help pages for Writer Status Bar, Calc’s Similarity Search and database ranges, updated menu item paths in Help, did lots of Help cleanups, added some extended tooltips, improved the dialog for easy conditional formatting in Calc and removed a misleading Restore Default button from Sidebar Settings
Alain Romedenne improved help for BASIC’s If statement and added unit tests for IF THEN statements in BASIC and VBA
Pierre F. made two dozen improvements to help, in areas such as Calc functions, word count, change tracking, BASIC, regular expressions, AutoRecovery and backup, and freezing of rows and columns in Calc
Dione Maddern added a help page for Quick Find Sidebar deck, updated the help for Writing Aids, reworked help pages for Navigator and Navigation toolbar and updated the instructions for enabling remote control in Impress Remote user guide
Adolfo Jayme Barrientos updated help pages about digital signatures after UI changes
Laurent Balland did cleanups in Resume Writer template and Beehive, Blue Curve, DNA, Blueprint Plans, Focus, Inspiration, Light, DNA, Midnightblue, Piano, Portfolio, and Progress Impress templates
Miklós Vajna (Collabora) made it faster to open DOCX files with many shapes and sections, and headers/footers activated, fixed a layout loop in a certain DOCX file with a complex full-page group shape, fixed losing paragraph styles with many numberings in DOCX export and made Writer layouting smarter, improving performance in LOKit
Sven Göthel, Skyler Grey, Hubert Figuière, Andras Timar, Michael Meeks and Áron Budea (Collabora) worked on LOKit used by Collabora Online. Michael also optimised loading times by reducing the frequency of progress bar updates
Jaume Pujantell (Collabora) implemented handling of firstHeaderRow attibute in XLSX pivot tables and fixed a crash seen when editing text in shapes in Collabora Online

Tomaž Vajngerl (Collabora) worked on the new histogram chart type
Julien Nabet fixed an issue preventing deletion of MySQL/MariaDB tables with spaces in their names and did some code cleanups
Xisco Faulí (TDF) fixed a PDF export crash, improved the contrast accessibility check and did many dependency updates
Michael Stahl (allotropia) improved some automated tests, fixed issues with hidden sections, made HTML pasting more robust when dealing with placeholder fields in Writer, fixed a wrapping issue with long index entries, simplified the code for JPEG quality levels in PDF export and made UA PDFs compatible with Adobe Acrobat Pro’s accessibility checker
Mike Kaganski (Collabora) worked around a bug in MS Access ODBC 64-bit driver preventing database table editing, fixed an issue in Insert Special Character dialog related to changing the font selection and made it possible to filter characters in the dialog by Unicode value, fixed an issue with Calc’s EXACT function when working in array context, improved stability by preventing the closing of a document while it is being layouted …

Tuesday
03 September, 2024

Miklos Vajna: Improved interactivity for LOK clients in Writer's layout

@ 06:08 UTC

Writer now has support for doing partial layout passes when LOK clients have pending events, which sometimes improves interactivity a lot.

This work is primarily for Collabora Online, but the feature is useful for any LOK clients.

Motivation¶

I recently worked with a document that has relatively simple structure, but it has 300 pages, and most of the content is part of a numbered list. Pasting a simple string (like an URL) into the end of a paragraph resulted in a short, but annoying hang. It turns out we updated Writer's layout for all the 300 pages before the content was repainted on the single visible page. In theory, you could reorder events, so you first calculate the first page, you paint the first page, then you calculate the remaining 299 pages. Is this possible in practice? Let's try!

Results so far¶

The relevant part of the test document is simple: just an empty numbered paragraph, so we can paste somewhere:

This is a good sample, because pasting into a numbered list requires invalidating all list items in that list, since possibly the paste operation created a new list item, and then the number portion has to be updated for all items in the rest of the list. So if you paste into a numbered list, you need to re-calculate the entire document if all the document is just a numbered list.

The first problem was that Writer tracks its visible area, but LOK needs two kinds of visible areas. The first kind decides if invalidations are interesting for part of the document area. LOK wants to get all invalidations, so in case we cache some document content in the client that is near the visible area, we need to know when to throw away that cache. On the other hand, we want to still track the actually visible viewport of the client, so we can prioritize visible vs hidden parts of the document. Writer in LOK mode thought that all parts of the document are a priority, but this could improved by taking the client's viewport into account.

The second problem was that even if Writer had two layout passes (first is synchronous, for the visible area; second is async, for the rest of the document), both passes were performed before allowing a LOK client to request tiles for the issued invalidations.

This is now solved by a new registerAnyInputCallback() API, which allows the LOK client to signal if it has pending events (e.g. unprocessed callbacks, tiles to be painted) or it's OK for Writer layout to finish its idle job first.

The end result for pasting a URL into this 300 pages document, when measuring end-to-end (from sending the paste command to getting the first updated tile) is a decrease in response time, from 963 ms to 14 ms.

How is this implemented?¶

If you would like to know …

Monday
26 August, 2024

= Roman Kuznetsov: The best LibreOffice extensions. Code Highlighter 2

@ 11:18 UTC

When I translated one book about Python to Russian which contained many examples of Python code I though quite long how to highlight them in the normal text. For book writing I used LibreOffice Writer (of course) but Writer has no a standard tool for code highlighting.

So after some searching I found the LibreOffice extension - Code Highlighter 2. It is also available on our extension site. This extension makes code highlighting using Pygments Python library. There is support for many programming languages and many color styles for highlighting there.

The extension worked fine, but I didn't like that for highlighting I should manually select every code example in the text, then press some shortcut, then select another code example, etc...

I wrote an issue on the extension github page and after some discussions the extension author Jean-Marc Zambon implemented a new feature that allows to highlight all code example in the book in only one action using Paragraph style!

So my workflow in this case will be as follows:

Create a snippet for the AutoText with code example that has a special paragraph style (for example, with font name Consolas and font size 12pt) with name, for example too - 'Python_code'.
Use this snippet to insert code examples
In the end of book writing just use the new feature in the extension and highlight all code examples in only one action!

Above you can see examples of the Code Highlighter work with some light and some dark styles.

Friday
23 August, 2024

Caolán McNamara: Linux Namespaces and Collabora Online

@ 11:17 UTC

In Collabora Online (for the normal mode of operation) we have a single server process (coolwsd) that spawns a separate process (kit) to load and manage each individual document. Each of those per-document kit processes runs in its own isolated environment. See architecture for details.

Each environment contains a minimal file system (ideally bind mounted from a template dir for speed, but linked/copied if not possible) that each kit chroots into, limiting its access to that subtree.

That chroot requires the CAP_SYS_CHROOT capability (and the desirable mount requires the CAP_SYS_ADMIN capability), and granting those capabilities to the coolforkit and coolmount binaries is a root privilege that, for typical deb/rpm packages, is done automatically at install time.

But it would be far more convenient not to require these capabilities to be set to do this isolation. They grant online more ability to affect its host system than it uses, we only want to mount dirs and chroot into dirs that belong to online and have no need or desire to make them available to any other process or user, and it's awkward, especially during development. to require root privileges to set these capabilities.

This scenario is not unique, and Linux provides namespaces, typically used by container implementations, to support achieving this. So recent work in Collabora Online leverages these namespaces to do its own layer of per-document kit isolation. (There's a good series of articles by Steve Ovens on the various namespaces, with the mount namespaces the most relevant one here.)

In essence, a user level process can create its own namespace in which it is apparently root from its own perspective, but as the original uid from the outside perspective and limited to operating on resources that the original uid is limited to accessing. So for each forkit, instead of requiring initial system capabilities and creating a system level bind mount we instead have no specific initial capabilities, enter a new namespace, unique to each forkit, in which that forkit becomes king of its own castle with apparent full capabilities, and can create bind mounts and chroot into its minimal file system.

Which is pretty magical to me as the whole existence of namespaces passed me by entirely without notice despite debuting over a decade ago.

Nothing is ever simple however, so some hurdles along the way.

Entering the namespace "requires that the calling process is not threaded" (man 2 unshare) which is not a problem for the normal use case in each kit, but did pose a problem for the test coolwsd does in advance to probe if there are working namespaces on the system in determine if it should operate kits in namespace mode or not. There it turned out that the Poco::Logger we use backups existing logs when it creates a new one, and then by default spawns a thread to compress the old log.

I initially had the vague notion that I could treat a namespace as a sort pseudo-sudo and …

Wednesday
21 August, 2024

LibreOffice QA Blog: QA/Dev Report: July 2024

@ 17:18 UTC

General Activities

LibreOffice 24.2.5 was released on July, 25
Olivier Hallot (TDF) did many improvements to Calc function help pages and added documentation for wildcards in the Find & Replace help content
Alain Romedenne added a help page for supported MS Office VBA object features and improved the help for IF Basic statement
Pierre F. did many improvements to Calc function help pages and clarified the help text on crash reporter
Dione Maddern reworked the help pages concerning Styles Sidebar deck and added a help page for Page Sidebar deck
Stanislav Horáček updated help for Calc’s XMATCH function
Gábor Kelemen (allotropia) did code cleanups in the area of warnings
Laurent Balland did cleanups in Yellow Idea, Candy, Freshes and Growing Liberty Impress templates
Miklós Vajna (Collabora) continued polishing support for content controls, improved the performance of working with documents having an unusually large number of bulleted lists, disabled export of form fields as PDF forms by default to match user expectations better and improved font fallback in DOCX import
Szymon Kłos, Jaume Pujantell, Attila Szűcs, Michael Meeks, Pranam Lashkari, Marco Cecchetti, Áron Budea and Henry Castro (Collabora) worked on LOKit used by Collabora Online
Tomaž Vajngerl (Collabora) continued refactoring and improving the code for Impress annotations
Julien Nabet fixed crashes and did code cleanups especially in Python code
Xisco Faulí (TDF) fixed an issue with deleting empty columns in Calc removing formatting from adjacent column, fixed a table copying crash, did simplifications in automated tests, added a dozen new tests, converted some tests from Java to Cppunit and upgraded Python to 3.10 alongside other dependency updates
Michael Stahl (allotropia) made document repairing code more robust and made it possible to remove autoformatting from a Writer table while adding a configuration option to disable automatic updates of autoformatting when editing a table
Mike Kaganski (Collabora) fixed rendering issues with GDI and EMF metafiles, made clipboard handling more robust on Windows, made UI tests more stable on Windows, fixed many issues related to database functionality, also making the Firebird integration better, made HTML/ReqIF export more robust and improved the performance of Calc autoformatting when applying to whole rows. He also did many code cleanups and optimisations
Caolán McNamara (Collabora) fixed incorrect font emphasis in Expert Configuration dialog, fixed an issue with a certain type of imported PDF appearing as blank after exporting, improved font fallback automated tests and fixed crashes. He also fixed many issues found by static analysers and fuzzers
Stephan Bergmann (allotropia) worked on WASM build, finishing the UNO bridge for it and enabling Start Center
Noel Grandin (Collabora) greatly improved the export time of complex XLS/X spreadsheets to ODS, made UI tests more stable by making them use a generic clipboard rather than the system one, improved the performance of rendering animated GIFs in Impress and improved the saving time of ODS files with lots of comments
Justin Luth (Collabora) implemented an option to the page number wizard …

Thursday
15 August, 2024

LibreOffice Dev Blog: Extending the UNO API

@ 13:59 UTC

Various functionalities of the LibreOffice are available through its programming interface, the UNO API. Here I discuss how to extend it.

What is UNO API?

Many functionalities of the LibreOffice is available through UNO API. You can write extensions and external programs that use LibreOffice functionality without the need to change the LibreOffice core source code.

Extensions work seamlessly with the software, and external applications can connect to the LibreOffice process and use it. The ability to do that depends on the UNO API.

On the other hand, some functionalities may not be available through this API. For example, newer features of the decent versions of LibreOffice, or functionalities that are not useful and/or important for external applications. Sometimes, you may want to use such functionalities elsewhere. Then you have to modify the LibreOffice core source code, and expose those functionalities through the API make them available to the external applications.

Let’s refer to the LibreOffice Developer’s Guide, which is mostly around the LibreOffice UNO API. There, you can read:

“The goal of UNO (Universal Network Objects) is to provide an environment for network objects across programming language and platform boundaries. UNO objects run and communicate everywhere.”

As UNO objects should be usable across different languages and platforms, they are described in an abstract meta language called UNOIDL (UNO interface definition language). This is similar to the IDL definitions in many other technologies like CORBA.

Example UNO API: FullScreen

The API that I discuss here, provides functionality to control full screen functionality for top level windows. Stephan, experienced LibreOffice developer, added that API in this commit:

commit af5c4092052c98853b88cf886adb11b4a1532fff

Expose WorkWindow fullscreen mode via new XTopWindow3

...deriving from the existing XTopWindow2. (Exposing this functionality via UNO
is useful e.g. for some embedded LOWA example application.)

The changes in this commit are over these files:

offapi/UnoApi_offapi.mk
offapi/com/sun/star/awt/XTopWindow3.idl
toolkit/inc/awt/vclxtopwindow.hxx
toolkit/source/awt/vclxtopwindow.cxx

First one, offapi/UnoApi_offapi.mk is needed to introduce the IDL file, according to its module, in a proper location. XTopWindow3.idl is added in com/sun/star/awt, which corresponds to com.sun.star.awt module. The other two, vclxtopwindow.hxx and vclxtopwindow.cxx are the implementation of the API in C++.

Let’s look into XTopWindow3.idl:

module com { module sun { module star { module awt {

/** extends XTopWindow with additional functionality

@since LibreOffice 25.2
*/
interface XTopWindow3: XTopWindow2 {
/** controls whether the window is currently shown full screen */
    [attribute] boolean FullScreen;
};

}; }; }; };

As you may see, it contains these important information:

1. It is an interface, called XTopWindow3.

2.It has a boolean attribute, FullScreen.

3. This functionality will be available in LibreOffice 25.2 and later.

4. This interface extends XTopWindow interface. You may find the documentation for XTopWindow in api.libreoffice.org.

More information about XTopWindow interface can be found in XWindow section of the LibreOffice Developer’s Guide, chapter 2.

C++ Implementation

C++ implementation basically consists of two functions to set …

Wednesday
07 August, 2024

Miklos Vajna: Improved font fallback in the DOCX import of Writer

@ 07:05 UTC

Writer now has improved support for font fallback when you open a DOCX file that refers to fonts which are not available currently.

This work is primarily for Collabora Online, but the feature is fully available in desktop Writer as well.

Motivation¶

Font embedding is meant to solve the problems around missing fonts, but you can also find documents with stub embedded fonts that are to be ignored and our code didn't have any sanity check on such fonts, leading to unexpected glyph-level fallbacks. Additionally, once font-level fallback happened, we didn't take the font style (e.g. sans vs serif) into account, which is expected to work when finding a good replacement for the missing font.

Results so far¶

Here is how to the original rendering looked like:

Once the handler for the embedded fonts in ODT/DOCX was improved to ignore stub fonts where even basic glyphs were not available, the result was a bit more consistent, but still bad. Here is a different document to show the problem:

Note how now we used the same font, but the glyphs are always sans, not serif. So the final step was to import the font type from DOCX and consider that while deciding font fallback:

With this, we ignore stub embedded fonts from DOCX, we import the font type and in general font fallback on Linux takes the font type into account while deciding font fallback.

How is this implemented?¶

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

As usual, the high-level problem was addressed by a series of small changes:

Want to start using this?¶

You can get a development edition of Collabora Online 24.04 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).

Tuesday
30 July, 2024

LibreOffice QA Blog: LibreOffice 24.8 RC2 is available for testing

@ 16:34 UTC

LibreOffice 24.8 will be released as final at the end of August, 2024 ( Check the Release Plan ) being LibreOffice 24.8 Release Candidate 2 (RC2) the forth and last pre-release since the development of version 24.8 started at the beginning of December, 2023. Since the previous release, LibreOffice 24.8 RC1, 138 commits have been submitted to the code repository and 87 issues got fixed. Check the release notes to find the new features included in this version of LibreOffice.

LibreOffice 24.8 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!!

IMPORTANT INFORMATION FOR WINDOWS 7 USERS
Internal python version has been upgraded to python 3.9 which no longer supports Windows 7. Be aware some LibreOffice functionalities written in Python may not work, like the wizards in File – Wizards. Please, do test this version and give us feedback.

…

Monday
29 July, 2024

LibreOffice Dev Blog: Fuzz testing to maintain LibreOffice code quality

@ 12:12 UTC

Here I discuss what fuzz testing is, and how LibreOffice developers use it incrementally to maintain LibreOffice code quality.

Maintaining Code Quality

LibreOffice developers use various different methods and tools to maintain LibreOffice code quality. These are some of them:

1. Code review: Every patch from contributors should pass code review on Gerrit, and after conforming to coding standards and conventions, it can become part of the LibreOffice source code.

2. Static code checking: “Coverity Scan” continuously scans LibreOffice source code to find the possible defects. An automated script reports these issues to the LibreOffice developers mailing list so that developers can fix them.

3. Continuous Testing: There are various C++ unit test and Python UI tests in LibreOffice core source code to make sure that the functionalities of the software remain working during the later changes. They are also helpful for making sure that the fixed regressions do not happen again. These test run continuously for each and every Gerrit submission on CI machines via Jenkins.

4. Crash testing: A good way to make sure that LibreOffice works fine is to batch open and convert a huge set of documents. This task is done regularly, and if some failure occurs developers are informed to fix the issue.

5. Crash reporting: LibreOffice uses crash testing to find out about the recurrent crashes, and fix them.

6. Tinderbox Platforms: Using dedicated machines with various different architectures, LibreOffice developers make sure that LibreOffice source code builds and runs without problem on different platforms. Here is the description of tinderbox (TB) from TDF Wiki:

Tinderbox is a script to run un-attended build on multiple repos, for multiple branches and for gerrit patch review system.

LibreOffice tinderboxes status

You can see the build status here:

https://tinderbox.libreoffice.org/

7. Fuzz testing: LibreOffice software is checked continuously using Fuzz testing. This is essentially giving various automated inputs to the program to find the possible places in the code where problem occurs. Then, developers will become aware of the those problematic places in the code, and can fix them.

Fuzz Testing LibreOffice

Fuzz testing on LibreOffice source code is active since 2017, and since then there has been various bug fixes for the problems that the fuzz tester reported. You can see more than 1500 of such fixes in the git log until now:

$ git shortlog -s -n --grep=ofz#

Issues Found with Fuzz Testing

This tool can find various different problems. These issues are then filed in a section of Chromium bug tracker, and after ~30 days, they are made public. When developers fix bugs of this kind, they refer to the issue number (for example 321) as ofz#321. A comprehensive list of all issues found is visible here:

Chromium Bug Tracker – LibreOffice Issues

Fixing the Issues

Let’s look at one of the fixes. You can find commits related to fuzzing with:

$ git log --grep=ofz

This is a recent fix from Caolán, an experienced LibreOffice developer that provided most of …

Thursday
25 July, 2024

LibreOffice Dev Blog: LibreOfficeKit for document conversion

@ 14:04 UTC

In the previous blog post, I provided a brief introduction to LibreOfficeKit API which one can use for accessing LibreOffice functionalities in an external application. Here I discuss in detail how to use LibreOfficeKit for converting an ODT to PDF, or from/to virtually any other format that LibreOffice supports.

LibreOfficeKit C++ Headers

For this example, you only need one header: LibreOfficeKit/LibreOfficeKit.hxx. Include it, and that is enough. This header will be available in the future versions of LibreOffice community. But for now, you may need to download LibreOfficeKit headers folder from LibreOffice core source code, and put it alongside your source code.

C++ Example

The example is relatively short. Here it is:

#include <iostream>
#include <LibreOfficeKit/LibreOfficeKit.hxx>
int main(int argc, char *argv[])
{
    if(argc < 2)
    {
        std::cout << "Usage: lokconvert  \n";
        return 1;
    }
    const char *input = argv[1];
    const char *output = argv[2];

    lok::Office * llo = NULL;
    try
    {
        const char lo_path[] = LOROOT "/program/";
        llo = lok::lok_cpp_init(lo_path);
        if (!llo) {
            std::cerr << "Error: could not initialize LibreOfficeKit\n";
            return 1;
        }

        lok::Document * lodoc = llo->documentLoad(input, NULL /* options */);
        if (!lodoc) {
            std::cerr << "Error: could not load document: " << llo->getError() << "\n";
            return 1;
        }

        if (!lodoc->saveAs(output, "pdf", NULL /* options */))
        {
            std::cerr << "Error: could not export document: " << llo->getError() << "\n";
            return 1;
        }
    }
    catch (const std::exception & e)
    {
        std::cerr << "Error: LibreOfficeKit exception: " << e.what() << "\n";
        return 1;
    }

    std::cerr << "Success!\n";
    return 0;
}

The example is simple. Input and output file names are passed via command line arguments, and are received via argv[1] and argv[2], if argument count, argc, is at least 3. First one is the program name itself, which we don’t use here.

LibreOffice binary folder is needed here, so you should set OO_SDK_URE_BIN_DIR environment variable, or you may even set that in your program itself.

This part of the code is for LibreOfficeKit initialization:

llo = lok::lok_cpp_init(lo_bin_dir);

And after that, it is the time to load the document:

lok::Document* lodoc = llo->documentLoad(input, NULL /* options */);

Having the lodoc pointer is necessary for converting the document using saveAs function:

lodoc->saveAs(output, "pdf", NULL /* options */)

As you can see, relevant code is inside a try/catch block. In case some exception occur, you will see relevant error information on the console. Also, in each step, from initializing LibreOfficeKit, to loading and in the end generating the output, there are error handling mechanisms to make sure that the work goes forward smoothly.

In the end, if everything is successful, you will see this message on the screen:

Success!

Build with cmake

You can use cmake to build this example. Here is an example CMakeLists.txt which also provides LO_ROOT and LO_SDK_ROOT to be used inside C++ file, as an alternative to setting it via an environment variable, or putting it manually in the code.

cmake_minimum_required(VERSION 3.5)

project(lokconv LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_executable(lokconv main.cpp)

include(GNUInstallDirs)

set(LOVERSION 24.2)

if(WIN32)
    set(LOROOT …

Wednesday
17 July, 2024

LibreOffice Design Blog: Peer-to-peer collaboration with LibreOffice

@ 08:22 UTC

A while ago, Simon Phipps, member of the Board of Directors at The Document Foundation, shared the idea to introduce a peer-to-peer collaboration built in to desktop LibreOffice without the requirement for a cloud provider. This idea has received a lot of attention inside the organization and the design team has started to outline the project now.…

Tuesday
16 July, 2024

LibreOffice QA Blog: LibreOffice 24.8 RC1 is available for testing

@ 11:37 UTC

LibreOffice 24.8 will be released as final at the end of August, 2024 ( Check the Release Plan ) being LibreOffice 24.8 Release Candidate 1 (RC1) the third pre-release since the development of version 24.8 started at the beginning of December, 2023. Since the previous release, LibreOffice 24.8 Beta1, 243 commits have been submitted to the code repository and 120 issues got fixed. Check the release notes to find the new features included in this version of LibreOffice.

LibreOffice 24.8 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!!

IMPORTANT INFORMATION FOR WINDOWS 7 USERS
Internal python version has been upgraded to python 3.9 which no longer supports Windows 7. Be aware some LibreOffice functionalities written in Python may not work, like the wizards in File – Wizards. Please, do test this version and give us feedback.

…

Tuesday
09 July, 2024

Miklos Vajna: Fixing handling of line object transformations in the DOCX import of Writer

@ 12:46 UTC

Writer now has improved support for toplevel line shapes when you import those from DOCX.

This work is primarily for Collabora Online, but the feature is fully available in desktop Writer as well.

Motivation¶

As described in a post from 2014, Writer reads the drawingML markup for shapes in DOCX files, including line shapes. While investigating a simple-looking problem around a horizontal vs vertical line, it turns out that there is a deeper issue here, and it looks like now have proper fix for this bug.

Results so far¶

Imagine that your company template has a nice footer in two columns, and the content in the columns are separated by a vertical line shape, but when you open your DOCX in Writer, it crosses the text of that footer instead:

While researching how line shapes are represented in our document model and how ODT import works, it turned out that the proper way to create a line shape is to only consider size / scaling when it comes to the individual points of the line, everything else (e.g. position / translation) should go to the transform matrix of the shape, then the render result will be as expected:

It was also interesting to see that this also improved other, existing test documents, e.g. core.git sw/qa/extras/ooxmlimport/data/line-rotation.docx looked like this before:

And the same fix makes it perfect:

Just stick to the rule: scaling goes to the points -- translation, rotation and horizontal shear goes to the shape.

For now, this is only there for toplevel Writer lines, but in-groupshape and Calc/Impress lines could also follow this technique if there is a practical need.

The "after" screenshots show ~no red, which means there is ~no reference output, where the Writer output would be missing.

How is this implemented?¶

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

The bugfix commit was tdf#161779 DOCX import, drawingML: fix handling of translation for lines.

The tracking bug was tdf#161779.

Want to start using this?¶

You can get a development edition of Collabora Online 24.04 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).

Monday
08 July, 2024

LibreOffice QA Blog: QA/Dev Report: June 2024

@ 11:15 UTC

General Activities

LibreOffice 24.2.4.2 was announced on June 6
Olivier Hallot (TDF) added help pages for LET Calc function, improved the help for other new Calc functions, made it so help pages show a link to LibreOffice guide books, updated help pages for Save and Calc View options and updated help pages after UI string changes
Alain Romedenne updated some Basic and Python help pages
Pierre F. updated the help for regular expressions, pointing to ICU Regular Expressions documentation
Dione Maddern updated help for Bullets and Numbering Image tab, Clone Formatting and Insert Table command in Impress
Bogdan Buzea did code cleanups in the area of includes and UI files
Gábor Kelemen (allotropia) fixed an issue with hiding drawing shapes from printing
Laurent Balland did cleanups in Impress Yellow Idea template, replaced built-in binary template for HTML files with an OTH file generated from XML sources and fixed a special Calc number formatting case involving misplaced minus signs

Miklós Vajna (Collabora) continued polishing the implementation of continuous endnotes for Microsoft Word compatibility, added a helper script to diff reference rendering vs. LibreOffice rendering via PDF, fixed a DOCX import glitch involving paragraph borders getting mixed up with table cell borders, fixed lost numbering in paragraph style with DOCX import, fixed a shape text padding issue with DOCX import, made it so pasting rich text from other LibreOffice applications into Writer no longer brings in lots of unnecessary styles, fixed some issues when exporting content controls to PDF forms and fixed handling of line object transformations with DOCX import
Szymon Kłos, Jaume Pujantell, Darshan Upadhyay and Henry Castro (Collabora) worked on LOKit used by Collabora Online
Tomaž Vajngerl (Collabora) continued refactoring and improving the code for Impress annotations, for example expanding the support for types and properties when exporting annotations to PDF and also when importing PDF files
Julien Nabet fixed some crashes and debug assertions
Xisco Faulí (TDF) fixed an issue with paragraph classifications getting deleted after Print Preview or when opening file, made SVG fill handling more robust, upgraded many dependencies and fonts, continued applying SAL_RET_MAYBENULL for enforcing null checking and added over a dozen automated tests
Michael Stahl (allotropia) continued polishing recognition of localised paragraph style names in DOCX files, fixed DOCX file opening crashes, changed Writer tab handling to take some very strange behaviour of Microsoft Word into account and made many improvements to libcmis library (for Content Management Interoperability Services standard)
Mike Kaganski (Collabora) improved loading of broken documents, fixed an issue with Writer text wrapping in very wide pages, made spell check red lining more robust, fixed a Writer layout loop involving tables within tables, improved interoperability of styles with DOCX export, fixed a goal seek macro crash and some other goal seek issues and made it so QuickStarter setting is remembered after upgrade on Windows
Caolán McNamara (Collabora) polished the small caps support in Impress and optimised the code for displaying extended tooltips. He also fixed many …

Thursday
27 June, 2024

LibreOffice Dev Blog: LibreOfficeKit API in action

@ 14:07 UTC

If you want to use LibreOffice functionality in your applications, LibreOfficeKit API is one of the good ways to do that. Here I describe how, with some examples. If you want to add the capability of loading, displaying, editing, saving and/or converting LibreOffice/MS Office files to your application, you have come to a good place.

What is LibreOfficeKit?

LibreOfficeKit is the (relatively) new API to access LibreOffice functionalities in C/C++ without the need of older UNO API and its dependencies. It is the underlying technology for LibreOffice Online, and also LibreOffice Viewer for Android.

LibreOffice functionality is usable via the older UNO API, which is several years old and provides many functionalities of LibreOffice through network or sockets. But UNO API is not helpful if you want to have the LibreOffice UI in your application. In comparison, LibreOfficeKit is capable of doing that.

LibreOfficeKit can create tiles from the LibreOffice, as a static library. It lets the user interact with LibreOffice from somewhere else, either different application, or a web browser.

In this way, it becomes much easier to create applications that incorporate the actual functionalities of LibreOffice in them, while having the LibreOffice UI in themselves.

Example: GTK Tiled Viewer

As an example, gtktiledviewer provides a small editor that can load the LibreOffice/MS Office files, display them and the user can actually edit those files.

LibreOffice GTK Tiled Viewer

If you have a working build of LibreOffice, you can run thegtktiledviewer application this way:

bin/run gtktiledviewer --lo-path=$PWD/instdir/program path/to/test.odt

Building such an application will be much easier compared to building and running LibreOffice UNO API applications which require many dependencies.

In order to compile LibreOfficeKit applications, you need LibreOfficeKit headers. These headers will be shipped with the next version of LibreOffice community distribution, LibreOffice 24.8.

Example Usage: Document conversion

Another interesting example is document conversion. For example, if you want to convert an ODT file to PDF or other formats with LibreOffice, you can use LibreOfficeKit API to do that.

One example code that does that is the lloconv project. You may find it on gitlab:

https://gitlab.com/ojwb/lloconv

The conversion code happens inside convert.cc source file, and it is pretty straightforward, although there are some extra code which handles finding LibreOffice binary path, and parsing command line arguments.

The important functions that are used in loading and converting documents can be found in these lines:

Office * llo = lok_cpp_init(lo_path);

And also:

Document * lodoc = llo->documentLoad(input_url.c_str(), options);

And at last:

lodoc->saveAs(output_url.c_str(), format, options)

It essentially initializes the document vialok_cpp_init, then loads the document using documentLoad function, and at last convert it to the final file format using saveAs() function.

The API for conversion is pretty straightforward, and it is enough to to know the path to the LibreOffice installation path to be able to compile and run the C++ example.

More interesting things are possible with LibreOfficeKit API, and I will write more about them.

Wednesday
19 June, 2024

Collabora Community: Hacking LibreOffice in Budapest

@ 11:00 UTC

Earlier this month, we were pleased to sponsor the Libreoffice Technology Hackfest in Budapest, Hungary, and enjoyed meeting up with some of our fellow LibreOffice Technology hackers. Over two days, a dozen developers from Collabora Productivity and the wider community met up in the Eco Community Space to work on the LibreOffice codebase, and reap the benefits of spending time together.

A hackfest is an event where developers from multiple organisations meet each other, work on what they want and also more freely exchange ideas while being together in person. While having an international community working remotely on the codebase is excellent, there are still many benefits to more directly seeing what problems are being tackled by other developer sitting next to you; and this friendly environment allows building relationships that can then help even more in the future (even remotely).

As one attendee Miklos Vajna shared with us after the event, “It was really great to spend a couple of days with the other developers. I found it very helpful seeing what other people are working on, sharing ideas about the future feature possibilities, and especially enjoyed going out for a dinner with everyone in Budapest after a hard day’s work!”

For this reason, we were very pleased to sponsor this most recent meet up. Many thanks to all who joined us in Budapest, we look forward to seeing you soon at the next meeting!

If you would like to find out more about joining the Collabora Online or LibreOffice community, we would encourage you to join the Collabora Online Community Forum or have a look at the Collabora Online Github to learn about how to get started.

For more information about our upcoming events, and to learn where you could meet us next, do have a look at our events page.

Friday
14 June, 2024

LibreOffice QA Blog: LibreOffice 24.8 Beta1 is available for testing

@ 14:23 UTC

LibreOffice 24.8 will be released as final at the end of August, 2024 ( Check the Release Plan ) being LibreOffice 24.8 Beta1 the second pre-release since the development of version 24.8 started at the beginning of December, 2023. Since the previous release, LibreOffice 24.8 Alpha1, 672 commits have been submitted to the code repository and 191 issues got fixed. Check the release notes to find the new features included in this version of LibreOffice.

IMPORTANT INFORMATION FOR WINDOWS 7 USERS
Internal python version has been upgraded to python 3.9 which no longer supports Windows 7. It’s very important to us to know whether LibreOffice 24.8 still works on Windows 7 or not, as well as its python functionalities. Please, do test this version and give us feedback.

LibreOffice 24.8 Beta1 can be downloaded for Linux, macOS and Windows, and it can be installed alongside the standard version.

In case you find any problem in this pre-release, please report it in Bugzilla ( You just need a legit email account in order to create a new account ).

For help, you can contact the QA Team directly in the QA IRC channel or via Matrix.

LibreOffice is a volunteer-driven community project, so please help us to test – we appreciate it!

Happy testing!!

…

Thursday
06 June, 2024

LibreOffice QA Blog: QA/Dev Report: May 2024

@ 10:41 UTC

General Activities

LibreOffice 24.2.3 was released on May 2
LibreOffice 7.6.7 was released on May 10
Olivier Hallot (TDF) added help pages for SEQUENCE and UNIQUE Calc functions and finalised help for RANDARRAY, XLOOKUP, XMATCH, FILTER, RANDARRAY, SORT and SORTBY functions. He also improved the help for Calc’s Advanced Filter, added extended tips to Sparklines dialog and improved the descriptions seen in the UI for Calc’s RANDARRAY and UNIQUE functions
Adolfo Jayme Barrientos improved the readability and grammar of Help pages
Stéphane Guillou (TDF) added help content for the new ability to start a presentation from the command line at an arbitrary slide number
Alain Romedenne added unit tests for officehelper.py
Dione Maddern added help content for new bar-of-pie and pie-of-pie chart types, updated help for File Properties, Slide Show Settings, Calc View Options, Summary and Expand Slides, Edit Points Bar, Calc change tracking, Shapes menu, Bullets and Numbering Image tab alongside various fixes and cleanups
Stanislav Horacek did corrections to Calc help content
Bogdan Buzea improved help about object positioning in Writer
Gábor Kelemen (allotropia) did code cleanups in the area of measurement units and snap lines, code simplification and includes
Laurent Balland did cleanups in Impress templates and added handling of xlink:type attributes for embedded charts, so they don’t produce a warning in the console
Miklós Vajna (Collabora) created a better implementation of continuous endnotes for Microsoft Word compatibility, implemented support for DOCX/DOC mirrored object positioning and adapted DOCX paragraph handling for files created with Word 2013 or newer, so the top margin of paragraphs on other pages than the first are collapsed
Áron Budea (Collabora) made it faster to open PPTX files with custom shapes
Gökay Şatır, Pranam Lashkari, Szymon Kłos, Méven Car, Hubert Figuière, Jaume Pujantell, Henry Castro and Michael Meeks (Collabora) worked on LOKit used by Collabora Online
Tomaž Vajngerl (Collabora) refactored the code for Impress annotations and cleaned up the accessibility checker code
Julien Nabet continued polishing gssapi authentication support for the MariaDB/MySQL connector and fixed a crash when exporting spreadsheet as PDF with “whole sheet export” option
Xisco Faulí (TDF) added support for SVG 2 attribute values context-stroke and context-fill, optimised the code for getting selected points and objects, added a couple of unit tests, upgraded many dependencies and started applying the newly-added SAL_RET_MAYBENULL for enforcing null checking
Michael Stahl (allotropia) implemented support for recognising localized paragraph style names in DOCX files, fixed the visibility of shapes in header/footer in DOCX files and fixed an issue with AutoText insertion or pasting overriding Writer paragraph style indentation
Mike Kaganski (Collabora) continued polishing HTML map export for text hyperlinks in frames, made LibreOffice’s own OLE objects obey AddReplacementImages setting, made it so the newly-added Windows version detection also handles architectures other than x86_64 and fixed a Writer undo issue affecting list levels
Caolán McNamara (Collabora) introduced SAL_RET_MAYBENULL which for debug builds and MSVC …

Wednesday
05 June, 2024

LibreOffice Design Blog: Convenient handling of shortcuts

@ 13:35 UTC

Shortcuts are a major topic for user experience. Novices are advised to learn basic shortcuts beyond the famous Ctrl+C/X/V like Ctrl+1/2/3.. to quickly change the paragraph style to heading 1/2/3… in Writer. Once you have learned those combinations you never want to unlearn and to change the muscle memory.…

Monday
03 June, 2024

Miklos Vajna: Section-based continuous endnotes in Writer

@ 14:26 UTC

Writer now has much better support for continuous / inline endnotes (not on a separate page) in Writer, enabled by default for DOCX files.

This work is primarily for Collabora Online, but the feature is fully available in desktop Writer as well.

Motivation¶

As described in a previous post, Writer already had minimal support for not rendering endnotes on a separate endnote page, but it was not mature enough to enable is by default for DOCX files.

Results so far¶

What changed from the previous "continuous endnotes" approach is that instead of trying to map endnotes to footnotes, we now create a special endnotes section, which only exists at a layout level (no section node is backing this one), and this hosts all endnotes at the end of the document. It turns out this is a much more scalable technique, for example a stress-test with 72 endnotes over several pages is now handled just fine.

Here are some screenshots:

As you can see, there were various differences for this document, but the most problematic one was that the entire endnote was missing from the (originally) last page, as it was rendered on a separate page.

Now it's not only on the correct page, but also its position is correct: the endnote is after the body text, while the footnote is at the bottom of the page, as expected. The second screenshot shows ~no red, which means there is ~no reference output, where the Writer output would be missing.

How is this implemented?¶

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

As usual, the high-level problem was addressed by a series of small changes:

The tracking bug was tdf#160984.

Want to start using this?¶

You can get a development edition of Collabora Online 24.04 and try it out yourself right now …

Thursday
30 May, 2024

LibreOffice Dev Blog: Porting Java tests to C++

@ 14:08 UTC

In this blog post, I discuss porting Java tests from Java to C++. We have many Java tests, and porting them to C++ is beneficial for LibreOffice. Here I discuss why, and how.

Why Porting Java Tests?

In the past, Java was used extensively in LibreOffice, and many tests where written in Java. They consist of various tests, including JUnit.

Searching for junit in LibreOffice source code gives many results: (Note that this is not the number of tests)

$ git grep -i junit | wc -l

901

Although these tests are useful, they have drawbacks:

1. They are slower than C++ CppUnitTests

2. They are outside process, which is creates them even more slower, and harder to debug

Porting these tests to C++ can make them faster, more reliable, and easier to debug. Let’s see how we can do it.

Start from Examples

The best way to find out how to do porting is to look into the previous examples. This issue is around porting Java API tests to C++:

tdf#45904 – Move Java based API tests to C++

There are many commits in the above page, which can be an interesting way to learn how to do that. For example, consider this commit:

tdf#45904 Move Java _XSheetCellRanges tests to C++

In the above commit, Jens has ported qadevOOo/tests/java/ifc/sheet/_XSheetCellRanges.java test to C++ test test/source/sheet/xsheetcellranges.cxx.

I can summarize the changes in this way:

1. An equivalent C++ file, in test/ folder

2. Removal of Java file from qadevOOo/.

3. The Makefiles in test/ and qadevOOo/ folders should reflect the removal of Java test, and addition of C++ test.

4. Some Java tests are adjusted to reflect the deletion of the old Java test.

5. Some C++ tests are adjusted to reflect the addition of new C++ test.

Final Words

To be able to port a test, one should be able to understand the old test. Reading the code is the best way that one can achieve this purpose. By looking into similar ports, you can gain a better understanding of what to do. In Bugzilla page for tdf#45904, you may find similar ports.

Monday
27 May, 2024

Björn Michaelsen: Writer Again!

@ 12:14 UTC

Writer Again!

After resigning from the Board of Directors of TDF over the weekend, I hope I will again find more time to look into the technical details of LibreOffice Writer. I will also try to do my best to write some good article here about the depth of that application. While a text processor in itself is not that interesting anymore these days, the challenges of migrating that big old legacy code might be fascinating quite often. Hope to have you as a reader for that soon!

Comments? Feedback? Additions? Most welcome here on the fediverse !

Tuesday
21 May, 2024

LibreOffice QA Blog: LibreOffice 24.8 Alpha1 is available for testing

@ 11:12 UTC

LibreOffice 24.8 will be released as final at the end of August, 2024 ( Check the Release Plan ) being LibreOffice 24.8 Alpha1 the first pre-release since the development of version 24.8 started at the beginning of December, 2023. Since then, 4448 commits have been submitted to the code repository and more than 667 bugs were set to FIXED in Bugzilla. Check the release notes to find the new features included in this version of LibreOffice.

LibreOffice 24.8 Alpha1 can be downloaded for Linux, macOS and Windows, and it can be installed alongside the standard version.

In case you find any problem in this pre-release, please report it in Bugzilla ( You just need a legit email account in order to create a new account ).

For help, you can contact the QA Team directly in the QA IRC channel or via Matrix.

LibreOffice is a volunteer-driven community project, so please help us to test – we appreciate it!

Happy testing!!

…

Tuesday
14 May, 2024

LibreOffice Dev Blog: Crash fixes, part 4: assertion failure

@ 11:46 UTC

In the previous parts of the blog posts series on fixing software crashes, I have written about some crash fixes in LibreOffice around segfaults, aborts, and I discussed how test them. Here I write about fixing assertion failure.

What is Assertion Failure?

Assertion is a mechanism provided to the developers to make sure that things are good in runtime, conforming to what they were assuming. For example, making sure that some pointer is valid, some data elements match expectation, or some similar assumptions that need to be valid in order to get the correct results.

As an example, consider the C++ function basegfx::utils::createAreaGeometryForLineStartEnd(), which creates a geometric representation of an arrow. The code resides here:

basegfx/source/polygon/b2dlinegeometry.cxx:84

This is the line of code which contains assertion:

assert((rCandidate.count() > 1) && "createAreaGeometryForLineStartEnd: Line polygon has too few points");

On top of the actual function implementation, the C++ code asserts many conditions to make sure that they are met. In the above assertion, it checks to make sure that the number of points in the given data structure is more than 1. Otherwise, it leads to an assertion failure.

For various reasons, sometimes these sort of assumption may not be valid. To avoid reaching to incorrect results, it is important to have such assertions in place, to find such issues as soon as possible. If you are developing LibreOffice, you may have already built the code from sources in debug mode. Therefore, you may see software stops working, or simply crashes.

This crash may not happen for the end users, which use the release version of software. Therefore, these type of crashes have lower impact for the end users, and they are usually considered of lower importance compared to the crashes that happen for the end users.

Backtrace

One of the things that can help diagnose the problem is the stack trace, or simply backtrace. The way to obtain a backtrace depends on the platform and/or IDE that you use. If you use an IDE like Qt Creator, Visual Studio, etc., getting a backtrace would be as easy as debugging LibreOffice, making the assert fail, and then copy the backtrace from the UI. To learn more about IDEs, see this Wiki page:

TDF Wiki: Development/IDE

If you want to use gdb on Linux, you may run LibreOffice with this command line:

$ instdir/program/soffice –backtrace

and then make the assert fail, and you will have the backtrace in gdbtrace.log file. You can learn more int this QA Wiki article:

TDF Wiki: QA/BugReport/Debug_Information

One thing to mention is that if you work on a reported bug regarding to assertion failure, then the actual way to reproduce the issue and make the assertion fail is usually described in the relevant TDF Bugzilla issue. In the meta bug related to assertion failure, you may find some of these issues in the last part of this blog post.

Fixing the Problem

To fix the problem …

Thursday
09 May, 2024

LibreOffice QA Blog: QA/Dev Report: April 2024

@ 08:19 UTC

General Activities

Olivier Hallot (TDF) added Help content for user interface selection dialog, Calc row recalculation at load time, automatic labeled ranges in Calc and font embedding. He also updated menu item paths in Help
Rafael Lima added support for hidden named expressions in Calc, added Reload command to Notebookbar UIs and made named ranges created by the Solver in Calc hidden by default
Stéphane Guillou (TDF) updated Help content for Navigator’s Navigate By
Alain Romedenne continued improving the officehelper Python script for connecting to LibreOffice processes
Dione Maddern improved Help content for inserting objects from the Gallery and did cleanups in Help
Colton Garrett improved Help content for OpenCL and added a Help page for digital signing of paragraphs
Laurent Balland did style cleanups in Impress templates
Miklós Vajna (Collabora) fixed an issue with shape positioning in DOCX import and did many code cleanups
Áron Budea (Collabora) fixed an issue with unwanted spacing in printed text
Marco Cecchetti, Gökay Şatır, Pranam Lashkari, Szymon Kłos and Michael Meeks (Collabora) worked on LOKit used by Collabora Online
Attila Szűcs (Collabora) continued improving the performance of handling transparent animated GIFs
Tomaž Vajngerl (Collabora) improved the text scaling in Impress text boxes, implemented support for custom cell format of pivot table output found in OOXML and did many code cleanups and restructurings
Julien Nabet added gssapi authentication support for the MariaDB/MySQL connector, fixed UI issues in Writer’s Paragraph dialog related to the “Allow to split paragraph” option, fixed crashes and did code cleanups
Xisco Faulí (TDF) continued the implementation of SVG filters
Michael Stahl (allotropia) changed the handling of paragraph and text attributes in empty lines at the end of paragraphs to match the behaviour seen in Microsoft Word
Mike Kaganski (Collabora) fixed issues with rotated text being partially cut off, made it possible to create DDE links to files with special characters in their names on Windows, made the Basic LIKE operator more robust, fixed an issue preventing Windows users with special characters in their names from importing PDF files into Draw, made the position shifting behaviour more robust for objects anchored As Character in Writer, fixed an issue with chapter titles in headers/footers getting mixed up due to headings in endnote content, fixed handling of em and ex units in the properties of imported SVG files, improved the stability of text part positioning in SVG files, fixed handling of whitespace in SVG text, fixed a Draw issue causing font colour to not be retained in certain situations and restored HTML map export for text hyperlinks in frames. He also did many code cleanups and optimisations
Caolán McNamara (Collabora) continued improving performance of threaded calculation in Calc. He also fixed crashes and many issues found by static analysers and fuzzers
Stephan Bergmann (allotropia) worked on WASM build, added a new Expert Configuration setting to not offer Safe Mode in the UI, fixed the msvc_win32_arm64 UNO bridge and worked on Windows Subsystem …

Tuesday
30 April, 2024

= allotropia: LibreOffice, JavaScript’ed

@ 11:32 UTC

LOWA is LibreOffice built with Emscripten as a Wasm executable that runs in the browser. Controlling that LibreOffice through UNO with JavaScript looks like a natural fit. Enter Embind, a mechanism to generate the binding glue between JavaScript and Wasm/C++.

As we will see, the Embind vs. UNO match is not perfect, but it kind-of gets the job done, at least for a first iteration.

Mappings

To dive straight into technical matters, the UNO type system is mapped to JavaScript as follows. (If you would like to see some example code first, jump ahead to the Starting Points and come back here later for reference.)

UNO BOOLEAN, depending on context and somewhat inconsistently maps to JavaScript Boolean and to JavaScript Number values 0 and 1. (The C/C++ representation of UNO BOOLEAN is sal_Bool, which is an alias for unsigned char, which Embind maps to JavaScript Number. So in places where we directly rely on Embind, like for the return value of a UNO interface method invocation, we get the Embind mapping to Number. But in places where we have more control, like for the JavaScript get method for a UNO ANY, we can be a bit more fancy and use a mapping to Boolean.)
UNO BYTE, SHORT, UNSIGNED SHORT, LONG, UNSIGNED LONG, FLOAT, and DOUBLE all map to JavaScript Number (with restricted value ranges for everything but UNO DOUBLE).
UNO HYPER and UNSIGNED HYPER both map to JavaScript BigInt (with restricted value ranges).
UNO CHAR and STRING both map to JavaScript String (with single UTF-16 code unit strings for UNO CHAR).
UNO TYPE maps to JavaScript Module.uno_Type objects. There are construction functions Module.uno_Type.Void, Module.uno_Type.Boolean, Module.uno_Type.Byte, Module.uno_Type.Short, Module.uno_Type.UnsignedShort, Module.uno_Type.Long, Module.uno_Type.UnsignedLong, Module.uno_Type.Hyper, Module.uno_Type.UnsignedHyper, Module.uno_Type.Float, Module.uno_Type.Double, Module.uno_Type.Char, Module.uno_Type.String, Module.uno_Type.Type, Module.uno_Type.Any, Module.uno_Type.Sequence, Module.uno_Type.Enum, Module.uno_Type.Struct, Module.uno_Type.Exception, and Module.uno_Type.Interface for representations of all the UNO TYPE values. The Module.uno_Type.Sequence construction function recursively takes a UNO TYPE argument for the component type, while the Module.uno_Type.Enum, Module.uno_Type.Struct, Module.uno_Type.Exception, and Module.uno_Type.Interface construction functions each take a string argument denoting the given type’s name in dotted notation (e.g., Module.uno_Type.Interface('com.sun.star.uno.XInterface')). Those JavaScript objects implement toString, which is also used for equality checks (e.g., type === 'com.sun.star.uno.XInterface').
UNO ANY maps to JavaScript Module.uno_Any objects. There is a constructor taking a UNO TYPE argument and a corresponding value (using an undefined value for UNO type VOID). Those JavaScript objects implement a method get that returns the JavaScript representation of the contained UNO value.
UNO sequence types map to a pre-canned variety of JavaScript Module.uno_Sequence_... objects. The problem is that Embind does not let us have a generic mapping to the C++ com::sun::star::uno …

Thursday
18 April, 2024

LibreOffice Dev Blog: Crash fixes part 3 – Testing crashes

@ 13:40 UTC

I have previously discussed fixing crashes in 2 parts (segfaults, aborts). Here I discuss testing crashes to avoid creating re-creating regressions.

Why testing crashes?

When you fix a crash, you have to make sure that it does not happen again in the future. The key to achieve such a goal is to write a suitable test. The test should do the exact steps to reproduce the problem on the program in order to detect the known crash before the new code is merged.

This can be done using either UITests, or CppUnitTests. UITests are written in Python. They are easier to write, but they do not run on each and every platform, and they are usually slower. CppUnitTests, on the other hand, are written in C++. They are much faster, and they run on every platform that CI runs to make sure that everything is built and can be run correctly.

An Example Crash Testing

Consider the below issue around footnotes:

tdf#150457 Fix crash on hovering removed footnote reference

This problem was happening when someone created a footnote, deleted the reference, and then hovered the mouse on the removed footnote reference. To reproduce that, one could use keyboard to generate a key sequence that repeats the required steps:

Write something, add footnote, select all the footnotes and remove them, then go back to the text, and hover the footnote reference.

Using keyboard-only is not always enough, but here it was possible. To implement the UITest, you should first find the appropriate place to put the test file, and then write a Python script for that. Here, the test was written in sw/qa/uitest/writer_tests2/deleteFootnotes.py. The UITest test can be found alongside the bug fix, in the class class tdf150457(UITestCase):

tdf#150457 Fix crash on hovering removed footnote reference

If you look into the code, the test_delete_footnotes() function consists of many invocations of postKeyEvent calls, that emulate key input events:

pTextDoc->postKeyEvent(LOK_KEYEVENT_KEYINPUT, 'a', 0);

To insert footnotes, UNO commands are used.

dispatchCommand(mxComponent, ".uno:InsertFootnote", {});

Just doing the same steps would be enough, as if the crash happens with the fix in place, or in a bad commit in the future, the test would fail. This test failure will prevent the same problem in the future.

The nice thing is that it turned out the same test could have been written using C++ and CppUnitTest, which is considered superior.

The new CppUnitTest can be found in the below change:

tdf#150457 Port UITest to CppunitTest

The new test resides in sw/qa/extras/uiwriter/uiwriter3.cxx, and essentially uses postKeyEvent and dispatchCommand as similar functions.

If you look at the current version of the test, you can see that it was simplified in later commits, but the idea is the same: “repeat the same steps that lead to crash in the code”.

Final Words

It is expected that every bug fix is accompanied with a test, to avoid seeing the same problem in the future …

Thursday
04 April, 2024

Miklos Vajna: Improve copy&paste in Calc and elsewhere

@ 07:50 UTC

Calc now supports much better copy&paste when you transfer data between Google Sheets and Calc.

This work is primarily for Collabora Online, but the feature is fully available in desktop Calc as well.

Motivation¶

First, Collabora Online was using the deprecated document.execCommand() API to paste text, which is problematic, as the "paste" button on the toolbar can't behave the same way as pressing Ctrl-V on the keyboard.

Second, it turns out Google Sheets came up with some additional HTML attributes to represent spreadsheet data in HTML in a much better way, and Calc HTML import/export had no support for this, while this is all fixable.

Results so far¶

In short, Collabora Online now uses the Clipboard API to read from the system clipboard -- this has to be supported by the integration, and Calc's HTML filter now support the subset of the Google Sheets markup I figured out so far. This subset is also documented.

Note that the default behavior is that the new Clipboard API is available in Chrome/Safari, but not in Firefox.

For the longer version, here are some screenshots:

How is this implemented?¶

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

As usual, the high-level problem was addressed by a series of small changes:

Overview

Welcome to The Document Foundation Planet

Languages:

Actions:

Metadata:

Keyboard shortcuts:

Wednesday25 September, 2024

Official TDF Blog: The Document Foundation announces the LibreOffice and Open Source Conference 2024

@ 19:49 UTC

Thursday19 September, 2024

Björn Michaelsen: Nothing ever happens

@ 23:30 UTC

Nothing ever happens.

Monday09 September, 2024

LibreOffice QA Blog: QA/Dev Report: August 2024

@ 15:23 UTC

General Activities

Tuesday03 September, 2024

Miklos Vajna: Improved interactivity for LOK clients in Writer's layout

@ 06:08 UTC

Motivation¶

Results so far¶

How is this implemented?¶

Monday26 August, 2024

= Roman Kuznetsov: The best LibreOffice extensions. Code Highlighter 2

@ 11:18 UTC

Friday23 August, 2024

Caolán McNamara: Linux Namespaces and Collabora Online

@ 11:17 UTC

Wednesday21 August, 2024

LibreOffice QA Blog: QA/Dev Report: July 2024

@ 17:18 UTC

General Activities

Thursday15 August, 2024

LibreOffice Dev Blog: Extending the UNO API

@ 13:59 UTC

What is UNO API?

Example UNO API: FullScreen

C++ Implementation

Wednesday07 August, 2024

Miklos Vajna: Improved font fallback in the DOCX import of Writer

@ 07:05 UTC

Motivation¶

Results so far¶

How is this implemented?¶

Want to start using this?¶

Tuesday30 July, 2024

LibreOffice QA Blog: LibreOffice 24.8 RC2 is available for testing

@ 16:34 UTC

Monday29 July, 2024

LibreOffice Dev Blog: Fuzz testing to maintain LibreOffice code quality

@ 12:12 UTC

Maintaining Code Quality

Fuzz Testing LibreOffice

Issues Found with Fuzz Testing

Fixing the Issues

Thursday25 July, 2024

LibreOffice Dev Blog: LibreOfficeKit for document conversion

@ 14:04 UTC

LibreOfficeKit C++ Headers

C++ Example

Build with cmake

Wednesday17 July, 2024

LibreOffice Design Blog: Peer-to-peer collaboration with LibreOffice

@ 08:22 UTC

Tuesday16 July, 2024

LibreOffice QA Blog: LibreOffice 24.8 RC1 is available for testing

@ 11:37 UTC

Tuesday09 July, 2024

Miklos Vajna: Fixing handling of line object transformations in the DOCX import of Writer

@ 12:46 UTC

Motivation¶

Results so far¶

How is this implemented?¶

Want to start using this?¶

Monday08 July, 2024

LibreOffice QA Blog: QA/Dev Report: June 2024

@ 11:15 UTC

General Activities

Thursday27 June, 2024

Wednesday
25 September, 2024

Thursday
19 September, 2024

Monday
09 September, 2024

Tuesday
03 September, 2024

Monday
26 August, 2024

Friday
23 August, 2024

Wednesday
21 August, 2024

Thursday
15 August, 2024

Wednesday
07 August, 2024

Tuesday
30 July, 2024

Monday
29 July, 2024

Thursday
25 July, 2024

Wednesday
17 July, 2024

Tuesday
16 July, 2024

Tuesday
09 July, 2024

Monday
08 July, 2024

Thursday
27 June, 2024

Wednesday
19 June, 2024

Friday
14 June, 2024

Thursday
06 June, 2024

Wednesday
05 June, 2024

Monday
03 June, 2024

Thursday
30 May, 2024

Monday
27 May, 2024

Tuesday
21 May, 2024

Tuesday
14 May, 2024

Thursday
09 May, 2024

Tuesday
30 April, 2024

Thursday
18 April, 2024

Thursday
04 April, 2024