The Document Foundation Planet


July 20, 2024

Official TDF Blog

Native Language Projects – TDF’s Annual Report 2023

TDF Annual Report banner

By helping to translate and market LibreOffice around the world, native language projects bring enthusiasm and passion to the global community. Here’s what they did in 2023…

(This is part of The Document Foundation’s Annual Report for 2023 – we’ll post the full version here soon.)


During the year, Tigran Zargaryan worked on a translation of LibreOffice into Armenian, and in January 2024 he announced the results of his work:

“With great pleasure, I’m informing that the Armenian localisation of LibreOffice is complete, and this is an especially significant event for Armenian community members worldwide, who are using various office suites in their daily work and – due to lack of Armenian user interface translations – are facing language difficulties.”

He added:

“I hope that the presence of the Armenian language interface translation will be of great support especially in schools, educational institutions and state organisations. In general, many state-based entities are financed by tax payers, and the presence of such a suite will ease their life, as they will legally be able to use office products without copyright infringement, and for them a totally new world of Free/Open Source Software (FOSS) philosophy will be introduced.”

LibreOffice user interface in Armenian


There were two events in Bangladesh: the Open Tech Talk at UITS in Dhaka, and Software Freedom Day 2023 Bangladesh event in MBSTU, Tangail. Meanwhile, community members assisted users in their native language Telegram groups.


Bulgarian speakers continued to maintain their translation of LibreOffice’s user interface at 100%, and the Help content at 95%.


Throughout 2023, the Czech community maintained its translation of LibreOffice’s user interface, keeping it at 100% complete, and the Help content at around 95%. They presented LibreOffice at a booth at the LinuxDays event in Prague in October, and published user guides in the Czech language in the LibreOffice Bookshelf (including their migration to HTML format). These included the Draw Guide 7.4, Base Guide 7.3, Calc Guide 7.4 and Impress Guide 7.5.

In addition, community members added support for Czech decimals to the Numbertext library, supported end users on the Czech “Ask LibreOffice” site, and maintained social media accounts on X (Twitter), Facebook and Instagram.

LinuxDays event in Prague


Throughout 2023, the Dutch-speaking community helped to support LibreOffice users by answering questions on the “Ask LibreOffice” website and mailing lists.

They set up a stand at the NLLGG in November – a conference of the Dutch Linux community. There, LibreOffice users could obtain information and ask questions about the software, whether or not in conjunction with a Linux-based operating system.

Community members also worked on maintaining the Dutch LibreOffice website, and translated and published handbooks: the Writer Guide for LibreOffice 7.5 (translated and published in February); the Math Guide for LibreOffice 7.5 (translated and published in June) the Draw Guide for LibreOffice 7.5 (translated and published in August); and he Impress Guide for LibreOffice 7.6 (translated and published in November).

Translators, using TDF’s Weblate instance, managed to keep up with changes in LibreOffice’s user interface, maintaining the 100% translated status. They added:

“Translating the Help content is a lot of work for a small group of volunteers. Although the Help keeps growing, we were able to maintain it at 100% translated.”


By the end of the year, the Esperanto translators had achieved the following levels of completion: user interface 99%, LibreOffice Online 100%, Impress Remote 100%, LibreOffice Help 37%, and the website 100%.


The Finnish-speaking community worked primarily on translating LibreOffice’s user interface, and to a lesser extent, the Help content.


In 2023, French contributors maintained translations on Weblate at almost 100% for all versions of LibreOffice, and progressed with translations of Calc functions on TDF’s wiki. They took part in two events, Capitole du Libre (Toulouse) and Open Source Experience (Paris), and held several online meetings with other community members. Finally, they made contributions to code, QA, marketing, documentation and Ask LibreOffice.


In Weblate, the translation of LibreOffice’s user interface reached 99% completeness, and the Help content 96%. There was user support by answering questions via Ask LibreOffice and mailing lists, while community members worked on translating release notes for new major LibreOffice releases, publishing videos, and working on translations of handbooks.


The Indonesian community organised a two-day “LibreOffice Conference Asia 2023” event in Surakarta, and posted a summary on this blog.

Regarding community activities, members worked on engaging and encouraging new contributors to work on videos showcasing the new features in LibreOffice.

LibreOffice Conference Asia 2023


Thanks to the efforts of the Italian community, the translation of LibreOffice’s user interface and online Help content reached 100%. Together with other communities, they started a pilot project to translate the Getting Started Guide via Weblate. In addition, they organised several activities and events during Linux Day 2023.


In terms of events, the Japanese community organised its local annual conference, LibreOffice Kaigi 2023 Online. There were three online study parties in which users shared knowledge and interacted with one another, along with 49 online hackfests, where participants worked together to make progress on tasks and transfer skills. There were also 10 “LibreOffice day” events – in-person events in Awaji, Osaka City. They were held jointly with Open Awaji, a group themed around open data and a movement towards open cities.

Japanese community members attended five open source conferences and had booths (in Tokyo, Nagoya, Hiroshima, Fukuoka and again in Tokyo). There was the Kansai Open Forum 2023, an event for open source and IT communities in the Kansai region that has been held annually since 2002. Additionally, Japanese community members participated in the LibreOffice Conference Asia 2023 and COSCUP (a comprehensive open source event in Taiwan).

Apart from events, community members worked on “how-to” videos and uploaded them to YouTube, and worked on translations of LibreOffice’s user interface into Japanese (93% complete) and the Help content (49% complete). They translated complete handbooks (the Writer Guide 7.5 and Calc Guide 7.5) and one community member, Meguro-san, translated using TexTra, a machine translation service provided by NICT, a Japanese government research institute.

There was also work on Ask LibreOffice, with 85 questions or comments added, and on the blog (19 articles posted). In terms of social media activity, the Japanese X (Twitter) account had 2,941 followers, 63 posts, 58,000 impressions and an engagement rate of 5.9%. The Facebook page had 22 posts and 625 followers.


In 2023, work continued on the Kazakh translation of LibreOffice’s user interface.


Work continued on translation of LibreOffice’s user interface, and the community promoted LibreOffice at the Ubuntu Korea 2023 event.


Locale data was added for Morisyen, the creole language used in the Republic of Mauritius (Islands of Mauritius, Rodrigues, Agalega and Archipelago of Chagos including Diego Garcia). The document language in LibreOffice can therefore be defined as such. There was input by Jean-Yves Dick and Ragini Kistnasamy from Ledikasyon pu Travayer (LPT) association, and Eike Rathke from the LibreOffice community.

Then there was work on an extension: the implementation of a unified spell-checker for use when writing in Morisyen. The extension includes 26,000 words and an AFF file, both works-in-progress.


Suraj Bhattarai, LibreOffice’s liaison in the Nepali community, mentored around 60 students from different universities and he connected a few more open-source communities in Nepal. They were able to localize around 10,000 strings in two weeks.

Suraj, along with the Kathmandu University Open Source club, organised a localisation camp during Software Freedom Day, and more than 53 students joined. They also organised an online course on called “localisation 101”, in which 11 students joined for two months, every Sunday from 21:00 – 22:00 Nepal time. Suraj shared with participants the concepts of localisation, internationalisation and the importance of style guides, terminologies, glossary, tools used, computer-aided translation and Weblate.

LibreOffice Nepali localisation sprint

Persian (Farsi)

Community members reported various issues with RTL/CTL (right-to-left and complex text layout languages) on TDF’s Bugzilla instance, and worked with TDF’s RTL/CTL developer to test and verify fixes. They considered many fixed issues with justified Persian text, and received very good feedback.

Fixing rendering issues remain the most important goal. In terms of localization, most of the work on translating LibreOffice’s user interface was from three contributors. Another worked on an AI assistant extension that works with ChatGPT. Finally, there were various posts on local websites and the Persian Telegram group, along with supports to end users.


The highlight of 2023 was the Latin America LibreOffice Conference, held in the Ciudad de México, Mexico. Community members also participated in the esLibre 2023 conference (an annual free software and hardware event), with two talks and three workshops.

Work continued on the translation of LibreOffice’s user interface (99%) and Help content (87%), while 20 articles were published on the Spanish blog. Then the Spanish version of Getting Started Guide 7.3 was published in Open Document and PDF formats, while two previous guides were published as HTML.

Community members provided user support in the Telegram channel (bridged with Mastodon), which has over 1,400 subscribers, while support for users writing Python macros continued on Mastodon. There was also a new iteration of the university program “Servicio Social para la Documentación de LibreOffice en español”. Participants published three magazines and collaborated on LibreOffice’s user interface translations.

LibreOffice Latin America Conference 2023


Work continued on translation of LibreOffice’s user interface, which was maintained at 99% complete.


Throughout the year, the Ukrainian team translated over 1,600 strings in LibreOffice’s “UI-Master” project, reaching overall 99% completeness. They also reached 51% completeness in the “Help-Master” project.

Thank you to everyone

We at The Document Foundation would like to say a huge thank you to everyone who in the native language communities. Your work makes LibreOffice accessible to hundreds of millions of people around the world, and your passion is wonderful. Thank you!

Like what we do? Support the LibreOffice project and The Document Foundation – get involved and help our volunteers, or make a donation. Thank you!

by Mike Saunders at July 20, 2024 05:59 AM

July 17, 2024

LibreOffice Design Blog

Peer-to-peer collaboration with LibreOffice

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.…

by Heiko Tietze at July 17, 2024 08:22 AM

July 16, 2024

LibreOffice QA Blog

LibreOffice 24.8 RC1 is available for testing

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

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.

Download it now!

by x1sc0 at July 16, 2024 11:37 AM

July 15, 2024

Michael Meeks

2024-07-15 Monday

  • Up early, mail chew, catch up with Miklos, then Lily - back from vacation.
  • Niels from OpenProject over to catch up - great to talk in the garden; had lunch & drove him back to Cambridge; good.
  • Suffered a terrible case of range-anxiety: having got used to the electric car being 100% fully charged whenever I leave to go out; I was amazed to notice the hybrid car having only 15 miles of range, and have to nurse it to an ugly smelling petrol station; hey ho.
  • Back to admin, caught up with Andras; build bits, finished mali chew, and more.

July 15, 2024 09:00 PM

July 14, 2024

Michael Meeks

2024-07-14 Sunday

  • Up earlyish; played at All Saints, home - most people gone - except for Sade. Bits of left-overs for lunch, slugged enthusiastically - watched some Travellers, babes seem to have got into football somehow. Bed early.

July 14, 2024 09:00 PM

July 13, 2024

Michael Meeks

2024-07-13 Saturday

  • Up late; talked with H's assembled friends, breakfast, helped E. blow up balloons & prepare for H's 21st birthday party.
  • Quick mail & task check. Lots of party-goers arrived; dropped them down in relays to the race-course.
  • Relaxed with J. for a bit - with Silva & David. Fetched babes back from racing, party until late at night celebrating a once small girl grown big & lovely - a blessing to her family & friends: fun. Lots of interesting people to talk to.

July 13, 2024 09:00 PM

July 12, 2024

Michael Meeks

2024-07-12 Friday

  • Up early; hacked at this & that, plugged away at Docusigning things; reviewed patches - queue seems to be shortening with a more regularly green tinderbox - which is good.
  • Got a few patches merged.

July 12, 2024 09:00 PM

Official TDF Blog

LibreOffice design, UX and UI updates – TDF’s Annual Report 2023

TDF Annual Report banner

Design has been one of the major focus points of LibreOffice in the last few years, and the Design community has produced new icon sets, new MIME type icons, a hugely improved dark mode, and improvements to the NotebookBar

(This is part of The Document Foundation’s Annual Report for 2023 – we’ll post the full version here soon.)

Based on LibreOffice’s Human Interface Guidelines (HIG), during 2023 there were various improvements to LibreOffice’s user interface.

Improvements in LibreOffice 7.5

Support for dark and high contrast operating system themes on Windows, macOS and Linux were greatly improved. More than 40 bugs were fixed by contributors including Caolán McNamara (Red Hat), Rafael Lima, Michael Weghorn (TDF) and Rizal Muttaqin.

LibreOffice on macOS in dark mode

In addition, Maxim Monastirsky implemented an improved version of the single toolbar user interface, supporting context-aware controls and their customization. It can be activated via View > User Interface > Single Toolbar. Finally, Heiko Tietze (TDF) updated the Start Center so that it can filter recent documents by type.

Improvements in LibreOffice 7.6

Andreas Heinisch worked on the recent documents picklist under File > Recent Documents; it now shows the five most recent module-specific items first. The list can be configured using the “ShowCurrentModuleOnly” expert option to show only files that can be handled by the current LibreOffice module.

Andreas also made it possible for documents in the Start Center to be pinned, to show them at the beginning of the recently opened document list. To pin a document, users can hover the corresponding document and click on the pin icon in the top-left corner. The selected document is then shown in a separate line at the beginning of the list, along with already pinned documents.

LibreOffice pinned documents in the Start Center

Heiko Tietze (TDF) did further work on the colour schemes: sets of “Automatic” application colours can now be chosen independently from the Application Color scheme in Tools > Options > LibreOffice > Application Colors.

Lastly, Michael Weghorn (TDF) improved keyboard navigation for the Special Characters dialog box.

Like what we do? Support the LibreOffice project and The Document Foundation – get involved and help our volunteers, or make a donation. Thank you!

by Mike Saunders at July 12, 2024 01:55 PM

July 11, 2024

Michael Meeks

2024-07-11 Thursday

  • Up early; poked at some web serving fun; tech. planning call. COOL community meeting. Lunch with H. TDF design call with Heiko, catch up with Kendy.
  • Sync with Olivier & Tracie on C'bra infra questing, partner sync call.
  • Joe over for a Piano lesson; house group dinner, with a number of N&H's friends around too; good to see the kitchen full.

July 11, 2024 09:00 PM

Official TDF Blog

Announcement of LibreOffice 24.2.5 Community, optimized for the privacy-conscious user

Berlin, 11 July 2024 – LibreOffice 24.2.5 Community, the fifth minor release of the free, volunteer-supported office productivity suite for office environments and individuals, the best choice for privacy-conscious users and digital sovereignty, is available at for Windows, macOS and Linux.

The release includes more than 70 bug and regression fixes over LibreOffice 24.2.4 [1] to improve the stability and robustness of the software, as well as interoperability with legacy and proprietary document formats. LibreOffice 24.2.5 Community is the most advanced version of the office suite and is aimed at power users but can be used safely in other environments.

LibreOffice is the only office suite with a feature set comparable to the market leader. It also offers a range of interface options to suit all users, from traditional to modern Microsoft Office-style, and makes the most of different screen form factors by optimising the space available on the desktop to put the maximum number of features just a click or two away.

LibreOffice for Enterprises

For enterprise-class deployments, TDF strongly recommends the LibreOffice Enterprise family of applications from ecosystem partners – for desktop, mobile and cloud – with a range of dedicated value-added features, long term support and other benefits such as SLAs:

Every line of code developed by ecosystem companies for enterprise customers is shared with the community on the master code repository and contributes to the improvement of the LibreOffice Technology platform. All products based on that platform share the same approach, optimised for the privacy-conscious user.

Availability of LibreOffice 24.2.5 Community

LibreOffice 24.2.5 Community is available at Minimum requirements for proprietary operating systems are Microsoft Windows 7 SP1 and Apple macOS 10.15. Products based on LibreOffice Technology for Android and iOS are listed here:

For users who don’t need the latest features and prefer a version that has undergone more testing and bug fixing, The Document Foundation maintains a version with some months of back-ported fixes. The current release has reached the end of life, so users should update to LibreOffice 24.2.5 when the new major release LibreOffice 24.8 becomes available in August.

The Document Foundation does not provide technical support for users, although they can get it from volunteers on user mailing lists and the Ask LibreOffice website:

LibreOffice users, free software advocates and community members can support the Document Foundation by making a donation at

[1] Fixes in RC1: Fixes in RC2:

by Italo Vignoli at July 11, 2024 11:04 AM

July 09, 2024

Miklos Vajna

Fixing handling of line object transformations in the DOCX import of Writer

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.


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:

Bugdoc, before: reference is red, Writer result is painted on top of it

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:

Bugdoc, after: reference is red, Writer result is painted on top of it

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:

3 rotated lines, before: reference is red, Writer result is painted on top of it

And the same fix makes it perfect:

3 rotated lines, after: reference is red, Writer result is painted on top of it

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).

by Miklos Vajna at July 09, 2024 12:46 PM

July 08, 2024

Official TDF Blog

Websites and Blogs – TDF’s Annual Report 2023

TDF Annual Report banner

Our two main websites are vital sources of information for The Document Foundation and the LibreOffice software. In 2023 we posted regular updates on our blog, including press releases and community interviews

(This is part of The Document Foundation’s Annual Report for 2023 – we’ll post the full version here soon.)

TDF website (

The Document Foundation website provides general information about the foundation (overview, statutes, code of conduct, financials and reports) and its governance (board of directors, membership committee, members, advisory board, and engineering steering committee), and about LibreOffice certification, including a list of certified developers, and professionals for migrations and trainings.

In 2022, we launched a new version of, using the Hugo website building framework. In 2023 we worked on updates to this site, refining the design and keeping content about the foundation’s various bodies up-to-date.

During 2023, the foundation’s website was visited 107,558 times, with 143,731 page views, a slight reduction in both statistics from 2022. Continent-wise, the largest chunk of visits were from Europe (49%), followed by North America (30-%) and Asia (15%). And for operating systems: the most visits were from PCs using the Windows (61%) operating system, followed by GNU/Linux (13%, a 3% gain from 2022) and macOS (8%), while for browsers: Chrome had 41%, followed by Firefox (16%) and Microsoft Edge (14%).

This image shows weekly visits to, throughout 2023:

Weekly visits to

LibreOffice website (

The LibreOffice website provides information about the office suite and the document format, the various download options, how to get help, how to contribute to the project, events where users can get to know the LibreOffice community, and how to make a donation to support the project and the community.

In 2023, we continued to make improvements and tweaks to the website, updating the timeline that shows events, activities and new releases of LibreOffice. We also worked on updates to the “Discover” and “New features” sections of the site, to reflect new versions of the software.

During 2023, the English-language LibreOffice website was visited 19,176,691 times (a 0.8% gain over 2022), with 46,011,840 page views (a -1.1% drop). Most visits were from Europe (52%), followed by Asia (18%), North America (15%) and South America (10%), from PCs using the Windows operating system (82%), followed by macOS (5%) and Linux (2.5%). Regarding web browsers, Chrome was the most popular (43%), followed by Microsoft Edge (28%) and Firefox (13%).

This image shows weekly visits to, throughout 2023:

Weekly visits to


TDF’s blogs are essential for communicating activities inside and around the project, including new releases of LibreOffice, community events and support for other free and open source initiatives. In 2023, we used them to post regular interviews with community members and provide updates from team members about documentation, marketing, QA, design and more.

Blogs were also maintained by various native language communities including Japanese, French, Spanish, German and others. Thanks to the hard work of community members, we had press releases, tips and other articles translated into many languages, and picked up by local media organisations.

These native language blogs complement the information provided by the main blog in English, and by the two blogs managed by members of the design and the quality assurance projects, which provide updates about activities for the upcoming major releases.

In 2023, the English-language blog had 151,352 visits and 196,287 page views. The press releases for LibreOffice 7.5 and 7.6 were the most popular posts, followed by posts for minor bugfix releases.

Like what we do? Support the LibreOffice project and The Document Foundation – get involved and help our volunteers, or make a donation. Thank you!

by Mike Saunders at July 08, 2024 12:37 PM

LibreOffice QA Blog

QA/Dev Report: June 2024

General Activities

  1. LibreOffice was announced on June 6
  2. 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
  3. Alain Romedenne updated some Basic and Python help pages
  4. Pierre F. updated the help for regular expressions, pointing to ICU Regular Expressions documentation
  5. Dione Maddern updated help for Bullets and Numbering Image tab, Clone Formatting and Insert Table command in Impress
  6. Bogdan Buzea did code cleanups in the area of includes and UI files
  7. Gábor Kelemen (allotropia) fixed an issue with hiding drawing shapes from printing
  8. 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
  9. 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
  10. Szymon Kłos, Jaume Pujantell, Darshan Upadhyay and Henry Castro (Collabora) worked on LOKit used by Collabora Online
  11. 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
  12. Julien Nabet fixed some crashes and debug assertions
  13. 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
  14. 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)
  15. 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
  16. Caolán McNamara (Collabora) polished the small caps support in Impress and optimised the code for displaying extended tooltips. He also fixed many issues found by static analysers and fuzzers
  17. Stephan Bergmann (allotropia) worked on WASM build and made form controls safer when dealing with remote linked images
  18. Noel Grandin (Collabora) made documents with lots of tracked changes open faster, continued optimising Calc performance when getting the text script type, continued speeding up the loading of large XLS files, made complex DOCX files with lots of footers or headers open faster, greatly improved the rendering performance of certain types of filled polygons imported from PDF files and improved the performance of EditEngine text. He also did many code cleanups
  19. Justin Luth (Collabora) expanded text wrapping support for shapes in DOCX files, fixed a z-order issue related to VML shapes in DOCX files and made it so small caps are not applied to numbering in Microsoft Office formats
  20. Michael Weghorn (TDF) made qt6 UI backend handle audio-only media objects, fixed OpenGL Impress transitions with Qt-based UI backends and worked on the accessibility features of Windows, GTK4 and Qt UIs in areas such as menu bar focusing, Calc cells and Sidebar buttons
  21. Balázs Varga (allotropia) continued tweaking the XMATCH and XLOOKUP Calc function implementations, added a new LET function to Calc which assigns names to calculation results, improved the display of direct formatting warnings in the accessibility Sidebar deck and added accessibility checks for missing hyperlink names and directly formatted top and bottom margins in paragraphs
  22. Patrick Luby fixed several macOS memory leaks and crashes, fixed a macOS performance issue related to documents with embedded fonts, fixed an issue with colour picker showing the wrong colours when using Skia raster rendering on macOS and fixed an issue with contour text wrapping against images with transparency
  23. Jim Raykowski made many improvements to the newly-added Quick Find Sidebar deck and fixed an issue with Format setting in Find and Replace dialog affecting Quick Find
  24. Sarper Akdemir (allotropia) removed the ability to trust unvalidated macro signatures in high security mode, made Additions dialog show connection errors, improved LanguageTool connection error reporting and continued polishing the new pane display of Presenter Notes in Impress
  25. Samuel Mehrbrodt (allotropia) continued working on vertical tabs for certain dialogs and bulleted/numbered list improvements and made it so author/date data is not exported to documents when in privacy mode
  26. Armin Le Grand (allotropia) worked on advanced diagram support and continued the rework of handling attributes and properties
  27. Oliver Specht (CIB) made it so simple HTML is preferred over RTF when pasting into Draw, fixed an issue with wrong inner margin in mirrored page in DOCX/RTF import and added a warning and a progress indicator to AutoFormat in case of applying to large selections
  28. Heiko Tietze (TDF) made it so Select All in Calc selects only the closest range of cells filled with data, added a command to cut a Calc cell without removing its formatting and made Calc column headers stand out
  29. László Németh fixed several issues related to images and objects in Writer tables, fixed resizing the rows and columns of Writer tables inside frames, continued polishing the No Break hyphenation feature, fixed spellchecking issues related to apostrophes, improved DOCX interoperability regarding hyphenation, made it so ASCII double quote matches typographic quote when searching, fixed a recent regression causing narrow no-break spaces to mess with spellchecking and fixed several AutoCorrect issues
  30. Ilmari Lauhakangas (TDF) fixed moving focus to document from Calc Functions Sidebar deck with Esc and made SVG images behave better in Help
  31. Christian Lohmaier (TDF) worked on Windows autoupdater and made large-scale simplifications to makefiles
  32. Thorsten Behrens (allotropia) worked on WASM build
  33. Eike Rathke (Red Hat) made it so certain range functions such as SUMIF and SUBTOTAL now accept inline arrays as arguments
  34. Jonathan Clark (TDF) fixed an issue causing incorrect glyphs to be displayed in RTL font fallback, fixes issues causing Writer to clip paragraphs at the ascent of the top line and descent of the last line, fixed overlapping RTL and LTR text when used together along with footnotes and fixed an issue causing Writer to corrupt layout for vertical text following a frame overflowing to the next page
  35. Regina Henschel made the handling of rotation angles conform to ODF spec
  36. Printf Debugging made it so there is feedback in the UI when resizing a frame or graphical objects would not be accepted
  37. Tibor Nagy (allotropia) fixed an issue with broken hyperlinks with ScreenTip set in imported DOCX files, made it so Name attributes of hyperlinks are exported to PDF as tooltips and fixed PPTX issues in the areas of colourmapping in master slides, placeholders, glue points and transparency
  38. Adam Seskunas worked on the GSoC project to port Java tests to C++
  39. Rafael Lima fixed an issue with Goal Seek macro corrupting the data in Calc cells, made Goal Seek settings be remember during a session and improved the visibility of outline in the selection overlay in Calc
  40. Leonard Sasse did cleanups in Python code
  41. Ritobroto Mukherjee ported some Java SDK examples to Python and worked on the GSoC project to implement cross platform .NET bindings for UNO API
  42. Attila Szűcs (Collabora) fixed images in PPTX files appearing horizontally compressed and fixed chart issues related to leader lines and pie chart label positions
  43. Andreas Heinisch made it so a jump statement is not executed in BASIC, if the expression is out of range, made case changing commands be correctly added by the macro recorder and aligned the implementation of the NOW function in BASIC with the one in Calc to include nanoseconds
  44. Hossein Nourikhah (TDF) made it so LibreOfficeKit headers are shipped in packages, allowing to create C++ applications that can access LibreOffice functionality without building LibreOffice, only by installing SDK and build tools
  45. Sujatro Bhadra replaced Show All and Hide All in the Comments category context menu of Writer Navigator with togglable commands Show Comments and Show Resolved Comments
  46. Kira Tubo added a unit test
  47. Theppitak Karoonboonyanan added a Thai thesaurus and Thai AutoCorrect Support

Kudos to Ilmari Lauhakangas for helping to elaborate this list.

Reported Bugs

432 bugs, 43 of which are enhancements, have been reported by 275 people.

Top 10 Reporters

  1. Eyal Rozenberg ( 16 )
  2. Gabor Kelemen (allotropia) ( 14 )
  3. Mike Kaganski ( 13 )
  4. Rafael Lima ( 11 )
  5. nobu ( 8 )
  6. Telesto ( 8 )
  7. Miklos Vajna ( 7 )
  8. Óvári ( 7 )
  9. Regina Henschel ( 7 )
  10. Olivier Hallot ( 6 )

Triaged Bugs

421 bugs have been triaged by 52 people.

Top 10 Triagers

  1. Stéphane Guillou (stragu) ( 107 )
  2. m_a_riosv ( 36 )
  3. Heiko Tietze ( 27 )
  4. ady ( 24 )
  5. Buovjaga ( 23 )
  6. Julien Nabet ( 22 )
  7. Mike Kaganski ( 18 )
  8. V Stuart Foote ( 18 )
  9. Xisco Faulí ( 14 )
  10. Dieter ( 11 )

Resolution of resolved bugs

436 bugs have been set to RESOLVED.

Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.

Fixed Bugs

177 bugs have been fixed by 36 people.

Top 10 Fixers

  1. László Németh ( 19 )
  2. Mike Kaganski ( 13 )
  3. Michael Stahl ( 10 )
  4. Patrick Luby ( 8 )
  5. Miklos Vajna ( 8 )
  6. Tibor Nagy ( 7 )
  7. Balazs Varga ( 6 )
  8. Michael Weghorn ( 6 )
  9. Xisco Fauli ( 6 )
  10. Caolán McNamara ( 6 )

List of critical bugs fixed

  1. tdf#161461 Crash on second copy after pasting using Enter in Calc on macOS ( Thanks to Patrick Luby )

List of high severity bugs fixed

  1. tdf#141773 Autocorrection for all languages doesn’t work anymore ( Thanks to László Németh )
  2. tdf#160877 Paragraph classification deleted after Print Preview or when opening file ( Thanks to Xisco Fauli )
  3. tdf#161030 Vertical Tab dialogs–width available for Tab name is too narrow with jumping view of Tab names ( Thanks to Xisco Fauli )
  4. tdf#161198 Negative / inverted highlight when hovering Navigator elements (or Draw tabs) no longer shown ( Thanks to Noel Grandin )
  5. tdf#161498 autocontour function is broken (does not take into account PNG transparency) ( Thanks to Patrick Luby )
  6. tdf#161511 [CRASH] Macro using seekGoal crashes on a brand new document ( Thanks to Mike Kaganski )
  7. tdf#161653 The numbering toolbar dropdown no longer can select from the 8-block of options ( Thanks to Samuel Mehrbrodt )

List of crashes fixed

  1. tdf#160769 LibreOffice 24.2 Document recovery (from timed autoSave) doesn’t restore all open files after crash ( Thanks to Justin Luth )
  2. tdf#160801 Writer crash when use clear formatting after insert page break (macOS only) ( Thanks to Patrick Luby )
  3. tdf#161217 FILEOPEN DOCX Crash when opening specific file ( Thanks to Michael Stahl )
  4. tdf#161346 CRASH: exporting to PDF ( Thanks to Michael Stahl )
  5. tdf#161461 Crash on second copy after pasting using Enter in Calc on macOS ( Thanks to Patrick Luby )
  6. tdf#161511 [CRASH] Macro using seekGoal crashes on a brand new document ( Thanks to Mike Kaganski )
  7. tdf#161786 Manually entering “oper” in the formula editor will cause a crash ( Thanks to Julien Nabet )

List of performance issues fixed

  1. tdf#155212 Writer is very slow when

by x1sc0 at July 08, 2024 11:15 AM

July 04, 2024

Official TDF Blog

LibreOffice Documentation Updates in 2023 – TDF’s Annual Report

LibreOffice Bookshelf

In 2023, the documentation community continued to update LibreOffice guidebooks, and the Help application

(This is part of The Document Foundation’s Annual Report for 2023 – we’ll post the full version here soon.)

New and translated guides

Throughout the year, the documentation project closed the gap between LibreOffice’s major releases, and the updates of the corresponding user guides. By the year end, all of the version 7.x guides were updated to match the release of LibreOffice 7.6, and ready to continue for the forthcoming release – 24.2 – which arrived in February 2024. The goal of tracking the software release closely was achieved, and the documentation team is now in a steady state of small updates between releases.

The updates and enhancements of the guides were an effort of all the team, coordinated by Jean Weber (Writer and Getting Started Guide), Olivier Hallot (Calc) Steve Fanning (Calc and Base guides), Peter Schofield (Impress and Draw guides), Vítor Ferreira (Math guide). A number of volunteers also worked in each guide by writing and reviewing contents and suggesting improvements. Special thanks to Jean Weber for making the guides available for sale in printed format via Lulu Inc.

LibreOffice Help updates

The documentation community also had a team of Help page bug fixes, closing Help documentation bugs, bridging gaps, fixing typos and improving quality, a must-have update to keep LibreOffice in-shape for its user base and documented reference of the application features. A total of 650 Help patches were merged in 2023. The Help pages, which are part of the LibreOffice codebase, were also refactored continuously for better maintenance and code readability. The localisation and translation team of volunteers was quick in flagging typos and English mistakes – while translating the Help content and the user interface.

LibreOffice Help

LibreOffice Developer Guide

Thanks to Ilmari Lauhakangas and Hossein Nourikah, the LibreOffice Developer Guide is now available on TDF’s infrastructure and under LibreOffice developers’ control, allowing update and improvements of the guide for the specifics of the LibreOffice application.

ScriptForge libraries, and Wiki updates

The documentation community also had a nice contribution from Jean Pierre Ledure, Alain Romedenne and Rafael Lima, for the development of the ScriptForge macro library, in synchronization with the much-needed Help pages on the subject, a practice rarely followed by junior developers of LibreOffice. As we know, undocumented software is software that’s lacking; features that are unknown to the user can be a cause of costly calls to a help desk in corporate deployments. ScriptForge developments came together with their documentation, demonstrating the ScriptForge team’s professional maturity.

LibreOffice Bookshelf

In 2023, the documentation community also updated the LibreOffice Bookshelf, another download page for LibreOffice guides that is different from the current server page. The Bookshelf can be cloned and installed in organizations, libraries, colleges and schools, for immediate availability in controlled environments, as well as online reading of the guides. The Open Document Format chapters were transformed into static HTML pages, and are ready to display on computers, tablets and cell phones, bringing LibreOffice user guides closer to its public, anywhere, anytime.

Like what we do? Support the LibreOffice project and The Document Foundation – get involved and help our volunteers, or make a donation. Thank you!

by Mike Saunders at July 04, 2024 08:27 AM

June 27, 2024

LibreOffice Dev Blog

LibreOfficeKit API in action

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 used in LibreOffice Online, and also LibreOffice Viewer for Android.

LibreOffice functionality can also be used through 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 application, which can be compiled as a static library, and then lets the user interact with the application 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

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:

The conversion code happens inside 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.

by Hossein Nourikhah at June 27, 2024 02:07 PM

June 19, 2024

Collabora Community

Hacking LibreOffice in Budapest

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.

by Richard Brock at June 19, 2024 11:00 AM

June 14, 2024

LibreOffice QA Blog

LibreOffice 24.8 Beta1 is available for testing

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.

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

Download it now!

by x1sc0 at June 14, 2024 02:23 PM

June 06, 2024

LibreOffice QA Blog

QA/Dev Report: May 2024

General Activities

  1. LibreOffice 24.2.3 was released on May 2
  2. LibreOffice 7.6.7 was released on May 10
  3. 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
  4. Adolfo Jayme Barrientos improved the readability and grammar of Help pages
  5. Stéphane Guillou (TDF) added help content for the new ability to start a presentation from the command line at an arbitrary slide number
  6. Alain Romedenne added unit tests for
  7. 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
  8. Stanislav Horacek did corrections to Calc help content
  9. Bogdan Buzea improved help about object positioning in Writer
  10. Gábor Kelemen (allotropia) did code cleanups in the area of measurement units and snap lines, code simplification and includes
  11. 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
  12. 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
  13. Áron Budea (Collabora) made it faster to open PPTX files with custom shapes
  14. 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
  15. Tomaž Vajngerl (Collabora) refactored the code for Impress annotations and cleaned up the accessibility checker code
  16. 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
  17. 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
  18. 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
  19. 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
  20. Caolán McNamara (Collabora) introduced SAL_RET_MAYBENULL which for debug builds and MSVC uses _Ret_maybenull_ and -analyze to enforce null checking. He also fixed many issues found by static analysers and fuzzers
  21. Stephan Bergmann (allotropia) worked on WASM build, creating a UNO bridge for it, worked on MAR autoupdater and did many code cleanups and adapted the code to compiler changes
  22. Noel Grandin (Collabora) optimised the speed of Calc column height calculation and getting the text script type and made loading large XLS files faster. He also did many code cleanups mainly in the area of strings
  23. Justin Luth (Collabora) added a button to Notebookbar UIs to toggle dark mode, fixed an issue with comment replies in DOCX appearing in the wrong order, made it possible to start presentations at a specific slide using command line parameters, fixed percents misbehaving when used as list level prefixes/suffixes in Writer, made image fills work in imported DOCX files, fixed an issue with paragraphs in textboxes losing their left and right paragraph indents in imported DOC files and made it so separators for lists with None numbering level are not exported to DOCX
  24. Michael Weghorn (TDF) worked on the accessibility features of Windows, GTK3 and Qt UIs in areas such as comboboxes, made it so the Number of copies field in the Print dialog only responds to mousewheel when the mouse is over it, fixed a Qt6 freeze, made Qt6 support video playback in Impress presentations on Wayland and did cleanups in the Android code
  25. Balázs Varga (allotropia) added Excel2021 array functions RANDARRAY and UNIQUE to Calc, polished the XLOOKUP and XMATCH implementations, made it possible to format characters in text boxes and shapes inside charts, added an option to make data validity case-sensitive in Calc and made the Open Remote button in the Start Center respect disabling via a config file
  26. Patrick Luby did many macOS stability improvements
  27. Jim Raykowski made Navigator Headings display flat when alphabetically sorted and improved context menus related to Navigator
  28. Sarper Akdemir (allotropia) continued polishing the new pane display of Presenter Notes in Impress
  29. Samuel Mehrbrodt (allotropia) made it so dialog tabs that would have spanned multiple horizontal lines are displayed vertically and made bullets used in the current document be displayed in the bullets dropdown
  30. Armin Le Grand (allotropia) continued the rework of handling attributes and properties
  31. Oliver Specht (CIB) made case cycling more robust, continued improving the dialog for managing user fields, fixed an issue with calculation in Writer tables with merged cells, improved OOXML compatibility with wrapped through shapes and images and made it so Data Validation in the context menu is disabled in protected Calc sheets
  32. Arnaud Versini did some code cleanups
  33. Heiko Tietze (TDF) improved some dialogs, made the focus rectangle more prominent for toolbar widgets, made Calc comment authorship optional, increased the mouse hit area for Calc column/row resizing actions and made the visibility of formatting marks more intuitive
  34. Vasily Melenchuk (CIB) expanded the use of Windows attention-grabbing FlashWindow API to dialogs opening, documents loading and LibreOffice starting
  35. László Németh continued polishing new hyphenation options, fixed ordinal indicators for Portuguese and Catalan when using AutoCorrect and made resizing images work in fixed-height Writer table cells in all cases
  36. Ilmari Lauhakangas (TDF) synchronised the Developer Guide hosted in TDF wiki with ODK examples and updated the PyUNO code for setting Python home directory to use PyConfig with newer Python versions
  37. Christian Lohmaier (TDF) made the makefiles easier to read by getting rid of overly complicated leftover conventions from a time when there was a need to deal with split repositories and two different build systems. He also worked on build support under Windows Subsystem for Linux
  38. Thorsten Behrens (allotropia) helped Samuel with the vertical dialog tabs work and fixed build issues
  39. Eike Rathke (Red Hat) fixed a rounding issue when saving to XLSX, fixed an issue with array separators changing when using the fill handle, made Excel intersect operator (space) be correctly detected in XLSX import and made Japanese calendar format import from XLSX more robust
  40. Jonathan Clark (TDF) finalised making BreakIterator (for breaking words or lines) use ICU, made Writer text layout across formatting changes more robust, avoiding incorrect kerning, fixed Writer text shaping across formatting changes and improved CJK fallback font rendering performance
  41. Jakub Kościelak made 64-bit Windows be correctly detected and made the MSI installer code more conformant
  42. Regina Henschel fixed an issue with object positioning after row sort in Calc AutoFilter and made text fit to contour in rotated polygons or bézier curves
  43. Shail Gautum made both Calc’s rolumn/row highlighting and edit mode highlighting more robust and fixed a build issue
  44. Pierre Vacher made zoned time type handling correct in Base table design and made it possible to manage relationships outside the default catalog/schema in Base
  45. Tibor Nagy (allotropia) made it possible to change default bullet symbols via the UI and made Writer hyperlink names show as tooltips
  46. Bayram Çiçek (Collabora) improved the speed of opening Tools – Options by deferring the indexing of dialog strings for the search feature and made it so AutoFill in Calc can now be called via .uno commands without needing to use the mouse
  47. Kurt Nordback continued polishing the of-pie chart type
  48. Rafał Dobrakowski made zoom in/out smoother in Calc preview
  49. Adam Seskunas made it so Writer tables get copied as a matrix to plain text editors
  50. Venetia Furtado added support for measuring the start up time between each splash screen update
  51. Rafael Lima reworked the new cell outline to work nice with different zoom levels and made it so AutoFill handle updates the cursor right after merging cells
  52. Leonard Sasse did cleanups in Python code
  53. Rizal Muttaqin added new icons for of-pie chart types

Kudos to Ilmari Lauhakangas for helping to elaborate this list.

Reported Bugs

438 bugs, 55 of which are enhancements, have been reported by 272 people.

Top 10 Reporters

  1. Eyal Rozenberg ( 19 )
  2. Stéphane Guillou (stragu) ( 18 )
  3. Gabor Kelemen (allotropia) ( 15 )
  4. Mike Kaganski ( 11 )
  5. johnks ( 9 )
  6. Mihai Vasiliu ( 9 )
  7. Regina Henschel ( 8 )
  8. Heiko Tietze ( 7 )
  9. Hossein ( 7 )
  10. Xisco Faulí ( 7 )

Triaged Bugs

484 bugs have been triaged by 62 people.

Top 10 Triagers

  1. Stéphane Guillou (stragu) ( 177 )
  2. Heiko Tietze ( 52 )
  3. m_a_riosv ( 47 )
  4. Dieter ( 21 )
  5. Buovjaga ( 17 )
  6. V Stuart Foote ( 17 )
  7. Julien Nabet ( 16 )
  8. Mike Kaganski ( 16 )
  9. ady ( 12 )
  10. Robert Großkopf ( 11 )

Resolution of resolved bugs

472 bugs have been set to RESOLVED.

Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.

Fixed Bugs

178 bugs have been fixed by 39 people.

Top 10 Fixers

  1. Mike Kaganski ( 15 )
  2. Dione Maddern ( 11 )
  3. Heiko Tietze ( 9 )
  4. Justin Luth ( 8 )
  5. Caolán McNamara ( 8 )
  6. Balazs Varga ( 6 )
  7. Miklos Vajna ( 6 )
  8. Jonathan Clark ( 4 )
  9. Patrick Luby ( 4 )
  10. Michael Stahl ( 4 )

List of critical bugs fixed

List of high severity bugs fixed

  1. tdf#126573 Add array functions in Calc: FILTER, SORT, SORTBY, UNIQUE, SEQUENCE, RANDARRAY ( Thanks to Balazs Varga )
  2. tdf#144576 Copy a table from Writer to plain text editor or as unformatted text pastes a list instead of matrix (like Calc does) ( Thanks to Adam Seskunas )
  3. tdf#159027 Writer table formulas calculated incorrectly in merged cells when table splits over pages ( Thanks to Oliver Specht )
  4. tdf#160937 Document Properties pages in all modules do not fit screen and cannot be resized (gtk3/gtk4) ( Thanks to Heiko Tietze )
  5. tdf#161020 Vertical Tab dialogs–initial size of the style dialog is too small ( Thanks to Thorsten Behrens )
  6. tdf#161047 Vertical Tab dialogs–Page style dialog is too small and not resizeable ( Thanks to Thorsten Behrens )
  7. tdf#161049 Vertical Tab dialogs–Format Cells dialog in recent 24.8 alpha is too small ( Thanks to Thorsten Behrens )
  8. tdf#161190 LibreOffice Calc crashes if you export a spreadsheet as PDF with “whole sheet export” option enabled. ( Thanks to Julien Nabet )
  9. tdf#61444 Text layout broken across formatting changes (color, underline, etc.) ( Thanks to Jonathan Clark )

List of crashes fixed

  1. tdf#160855 LibreOffice crashes when Calc cells are selected/copied ( Thanks to Patrick Luby )
  2. tdf#160898 Crash selecting all (Ctrl+A) in a temporarily visible paragraph under a table inside a table ( Thanks to Mike Kaganski )
  3. tdf#160906 Crash when changing formatting (e.g. font) inside Text Box Form Control ( Thanks to Armin Le Grand (allotropia) )
  4. tdf#161083 CRASH: closing the document ( Thanks to Miklos Vajna )
  5. tdf#161190 LibreOffice Calc crashes if you export a spreadsheet as PDF with “whole sheet export” option enabled. ( Thanks to Julien Nabet )

List of performance issues fixed

  1. tdf#148616 FILEOPEN PPTX A certain POTX template is slow to open ( Thanks to Aron Budea )
  2. tdf#160056 calc threaded calculation performance issue ( Thanks to Caolán McNamara )
  3. tdf#160897 FILEOPEN: layout loop, freeze in master document linked to subdocument ( Thanks to Michael Stahl )
  4. tdf#81272 Libreoffice Is Very Slow Rendering Chinese Characters (because of font fallback?) ( Thanks to

by x1sc0 at June 06, 2024 10:41 AM

June 05, 2024

LibreOffice Design Blog

Convenient handling of shortcuts

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.…

by Heiko Tietze at June 05, 2024 01:35 PM

June 03, 2024

Miklos Vajna

Section-based continuous endnotes in Writer

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.


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:

Before: reference is red, Writer result is painted on top of it

After: reference is red, Writer result is rendered on top of it

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: 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).

by Miklos Vajna at June 03, 2024 02:26 PM

May 30, 2024

LibreOffice Dev Blog

Porting Java tests to C++

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


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++:

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:

In the above commit, Jens has ported qadevOOo/tests/java/ifc/sheet/ 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.

by Hossein Nourikhah at May 30, 2024 02:08 PM

May 27, 2024

Björn Michaelsen

Writer Again!

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 !

May 27, 2024 12:14 PM

May 21, 2024

LibreOffice QA Blog

LibreOffice 24.8 Alpha1 is available for testing

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

Download it now!

by x1sc0 at May 21, 2024 11:12 AM

May 14, 2024

LibreOffice Dev Blog

Crash fixes, part 4: assertion failure

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:


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.


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:

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, first you should gain understanding of the assumption, and why it fails. You should be able to answer these questions by reading the code and debugging it:

  • What does some assumption mean?
  • Why it fails?
  • How to fix that, so that it does not fail?

To gain this understanding, you have to look into the places where backtrace points. Backtrace can be complex, containing the whole stack of the function calls across the software, linking to places in the code, but let’s discuss a simplified form.

Consider this bug fix:

tdf#152012 Fix assert fail on opening date picker

The problem was that an assertion failure was happening when opening date picker field in a DOCX file. This is the simplified form of the stack trace:

1  __pthread_kill_implementation           pthread_kill.c:44
2  __pthread_kill_internal                 pthread_kill.c:78
3  __GI___pthread_kill                     pthread_kill.c:89
4  __GI_raise                              raise.c:26
5  __GI_abort                              abort.c:79
6  __assert_fail_base                      assert.c:92
7  __GI___assert_fail                      assert.c:101
8  o3tl::span::operator[]                  span.hxx:83
9  OutputDevice::ImplLayout                text.cxx:1396
10 OutputDevice::DrawTextArray             text.cxx:948
11 Calendar::ImplDraw                      calendar.cxx:71
12 Calendar::Paint                         calendar.cxx:1133

The problem was caused by an out of bound access to a vector of integers, and to fix that, you had to see why this happens, and fix that.

This is the description from the commit title:

Previously, for the 7 days of the week, a 7 letter string smtwtfs (depending on the week start day this can be different, but length is always 7) was sent to this method without providing the length, thus the string length: 7 was used. In this case, positions of the letters were calculated and used from other array named mnDayOfWeekAry[7]. mnDayOfWeekAry[k+1] was used as the position of letter k (k=0..5). In this case, there was 7 letters for 7 days, and only 6 positions provided by the array. This caused assertion failure in span.hxx:83 when trying to access mnDayOfWeekAry[7] via o3tl::span<T>::operator[].

As you can see, a false assumption was creating assertion failure, and the fix was essentially changing the code based on the corrected assumption.

Sometimes, the fix can be easier. As an example, by only checking a pointer to make sure that it is valid, the assertion failure does not happen. Therefore, to fix the problem, you have to carefully study the code and its behavior.

Final Notes

Many of the assertion failure bugs are fixed in daily works of the developers, before causing problems for the end users, which use the “release” version of the software, that do not crash because of the assertion failure. But there are some of these issues remaining.

Do you want to help fix some of the remaining issues? Then, please refer to the list here, read some bug report, and pick one:

by Hossein Nourikhah at May 14, 2024 11:46 AM

April 30, 2024


LibreOffice, JavaScript’ed

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.


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('')). Those JavaScript objects implement toString, which is also used for equality checks (e.g., type === '').
  • 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::Sequence<T> class template; we can only have individual Embind mappings to specific class template instantiations. As a hack, for every UNO sequence type that appears somewhere in the LibreOffice UNO API, we generate a specific JavaScript Module.uno_Sequence_.... The naming is Module.uno_Sequence_boolean, Module.uno_Sequence_byte, Module.uno_Sequence_short, Module.uno_Sequence_unsigned_short, Module.uno_Sequence_long, Module.uno_Sequence_unsigned_long, Module.uno_Sequence_hyper, Module.uno_Sequence_unsigned_hyper, Module.uno_Sequence_float, Module.uno_Sequence_double, Module.uno_Sequence_char, Module.uno_Sequence_string, Module.uno_Sequence_type, and Module.uno_Sequence_any for the simple UNO component types; Module.uno_Sequence_... followed by the UNO type name in dollar-separated notation (e.g., Module.uno_Sequence_com$sun$star$uno$XInterface) for enum, struct, and interface component types; and Module.uno_SequenceN_..., with N greater than 1, for sequence component types (e.g., Module.uno_Sequence2_long for the UNO type “sequence of sequence of LONG“). That means that there currently is just no way to come up with e.g. a JavaScript representation of the UNO type “sequence of interface“, as that sequence type happens to not be mentioned anywhere in the LibreOffice UNO API. (But for those sequence types that are used as interface method parameter or return types, corresponding JavaScript representations are provided. That should hopefully cover all relevant use cases for now; a future overhaul of this part of the mapping is likely.) These JavaScript sequence objects have two constructors, one taking a JavaScript array of member values (e.g., new Module.uno_Sequence_long([1, 2, 3])) and one taking a size and a Module.FromSize marker (as Emind does not allow to have multiple constructors with the same number of arguments) whose members will have default values (e.g., new Module.uno_Sequence_long(3, Module.FromSize)). Additional methods are resize (taking the new length as argument), size (returning the current length), get (taking an index as argument and returning the member at that index), and set (taking an index and a new member value as arguments). (The naming of those resize, size, get, and set methods is modelled after Embind’s emscripten::register_vector.)
  • UNO enum types are mapped to Embind-provided enums named Module.uno_Type_... followed by the UNO type name in dollar-separated notation (e.g., Module.uno_Type_com$sun$star$uno$TypeClass).
  • Plain UNO struct types and UNO exception types are mapped to Embind-provided value objects named Module.uno_Type_... followed by the UNO type name in dollar-separated notation (e.g., Module.uno_Type_com$sun$star$beans$NamedValue, Module.uno_Type_com$sun$star$uno$Exception). Polymorphic UNO struct types face a similar issue to sequence types, in that Embind does not allow to directly map their corresponding C++ class templates. It would be possible to do a similar hack and add specific mappings for all instantiated polymorphic struct types that are mentioned anywhere in the LibreOffice UNO API, but that has not been implemented so far. (And, similar to sequence types, a future overhaul of this part of the mapping is likely.)
  • UNO interface types are mapped to Embind-provided classes named Module.uno_Type_... followed by the UNO type name in dollar-separated notation (e.g., Module.uno_Type_com$sun$star$uno$XInterface). Null references are mapped to JavaScript null. The special UNO interface methods queryInterface, acquire, and release are not exposed to JavaScript client code.
  • UNOIDL single-interface–based service constructors are mapped to JavaScript functions named Module.uno_Function_...$$... followed by the service’s name in dollar-separated notation, followed by the constructor’s name set of by two dollar signs (e.g., Module.uno_Function_com$sun$star$beans$Introspection$$create). Like with other UNO language bindings, those functions take the as an additional first argument.
  • UNOIDL service-based singletons are mapped to JavaScript functions named Module.uno_Function_... followed by the singleton’s name in dollar-separated notation (e.g., Module.uno_Function_com$sun$star$frame$theDesktop). Like with other UNO language bindings, those functions take the as their (sole) argument.

Starting Points

To make all this work, the Embind mapping of the LibreOffice UNO API needs to be set up first. This is done by a call to

const uno = init_unoembind_uno(Module);

which also returns a wrapper object uno that allows for more natural access to all the UNOIDL entities whose mappings use that dollar-separated notation: Instead of Module.uno_Type_com$sun$star$uno$XInterface one can write, and a call to uno_Function_com$sun$star$beans$Introspection$$create(context) can be written as If you want to cut down on the common prefix even further,

const css =;

lets you reduce that to just and css.beans.Introspection.create(context).

The starting points to access the LibreOffice UNO API from JavaScript are Module.getUnoComponentContext() (returning the central, through which all the services and singletons are reachable) and a Module.getCurrentModelFromViewSh() convenience function (returning the css.frame.XModel of the currently showing document). The repository is a growing site of example code showing all of this in action.

Summing this up, here is some example code that iterates over all the paragraphs of a Writer document and gives each of them a random foreground text color:

const uno = init_unoembind_uno(Module);
const css =;
const model = Module.getCurrentModelFromViewSh();
const document = css.text.XTextDocument.query(model);
const text = document.getText();
const access = css.container.XEnumerationAccess.query(text);
const paragraphs = access.createEnumeration();
while (paragraphs.hasMoreElements()) {
  const paragraph = css.text.XTextRange.query(
  const props = css.beans.XPropertySet.query(paragraph);
  const color = new Module.uno_Any(
    Math.floor(Math.random() * 0xFFFFFF));
  props.setPropertyValue("CharColor", color);


Embind is built on the concept that whatever C++ objects you reference from JavaScript, you manually and explicitly need to declare those references as no longer needed once you are done, by calling delete() methods on the corresponding JavaScript objects. (Or else, you risk memory leaks.) This can be quite cumbersome and would pollute the code with tons of such delete() calls. Luckily, JavaScript grew a FinalizationRegistry mechanism that allows code to be executed when the JavaScript garbage collector finds an objet to be unused and reclaims it. (And that code can thus transparently do the delete() call for us.) Embind implements such FinalizationRegistry-support for some types (those that are modelled based on some “smart poiner”) but not for others.

That means that (besides all the primitive types) JavaScript mappings of UNO string, type, enums, sequences, exceptions, and interfaces all do not need explicit delete() calls, while the mappings of UNO any and UNO sequences, and the various Module.uno_InOutParam_... all need explicit delete() calls.

Even though we expect that the JavaScript engines that we target do support the FinalizationRegistry mechanism, Embind is prepared to work with older engines that do not support it. Therefore, whenever an object is transparently cleaned up, Embind logs a somewhat unhelpful warning to the JavaScript console, stating that it “found a leaked C++ instance” (and that it will “free it automatically”).


For each UNO interface type there is a JavaScript class method query taking any JavaScript UNO object reference (in the form of the common base interface) as argument (and internally using UNO’s queryInterface to obtain either a correspondingly-typed reference to that object, or a null reference). There is also a JavaScript helper function Module.sameUnoObject, taking two interface references as arguments and returning whether both are references to the same UNO object.

UNO interface methods taking out or in-out parameters need special treatment. There are Module.uno_InOutParam_... wrappers (with a val property carrying the actual value) that need to be set up and passed into the UNO method. Such wrappers have a constructor taking no arguments (creating a dummy object, suitable for pure out parameters) and another constructor taking one argument of the wrapped type (suitable for in-out parameters). For example, to read data from a

const stream = ...;
const input =;
if (input) {
  const data = new Module.uno_InOutParam_sequence_byte;
  input.readBytes(data, 100);
  for (let i = 0; i != data.val.size(); ++i) {
    console.log('read byte ' + data.val.get(i));

Exception Handling

Support for throwing and catching exceptions between JavaScript and C++ is rather rough: JavaScript code can use try ... catch (e) ... to catch a UNO exception thrown from C++, but all the information it can get about that exception is stating the exception’s type. Also, for technical reasons, the catch block needs some increment– and decrementExceptionRefcount boilerplate,

try {
} catch (e) {
    //TODO, needed when building with JS-based -fexceptions,
    // see
    // <>
    // "[EH] Fix inconsistency of refcounting in Emscripten
    // EH vs. Wasm EH"
  if ( === 'com::sun::star::uno::RuntimeException') {

To throw UNO exceptions from JavaScript code, there is a helper function Module.throwUnoException that takes a UNO (exception) type and an instance of that type:

  {Message: 'bad argument', Context: null,
   ArgumentPosition: 0});

UNO Objects

The JavaSript-to-UNO binding is a full mapping, so you can even implement new UNO objects in JavaScript. This requires quite some boilerplate, though. For example, the below obj implements and

const obj = {
  // Implementation details:
  implRefcount: 0,
  implTypes: new Module.uno_Sequence_type([
  implImplementationId: new Module.uno_Sequence_byte([]),

  // The methods of XInterface:
  queryInterface(type) {
    if (type == '') {
      return new Module.uno_Any(
    } else if (type == '') {
      return new Module.uno_Any(
    } else if (type == '') {
      return new Module.uno_Any(
    } else {
      return new Module.uno_Any(
        Module.uno_Type.Void(), undefined);
  acquire() { ++this.implRefcount; },
  release() {
    if (--this.implRefcount === 0) {

  // The methods of XTypeProvider:
  getTypes() { return this.implTypes; },
  getImplementationId() {
    return this.implImplementationId;

  // The methods of XJob:
  execute(args) {
    if (args.size() !== 1 || args.get(0).Name !== 'name') {
        {Message: 'bad args', Context: null,
         ArgumentPosition: 0});
      'Hello, my name is ' + args.get(0).Value.get());
    return new Module.uno_Any(
      Module.uno_Type.Void(), undefined);
  = css.lang.XTypeProvider.implement(obj);
  = css.task.XJob.implement(obj);

// ... pass obj to UNO here ...

by stbergmann at April 30, 2024 11:32 AM

April 18, 2024

LibreOffice Dev Blog

Crash fixes part 3 – Testing crashes

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:

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/ The UITest test can be found alongside the bug fix, in the class class tdf150457(UITestCase):

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:

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. If you want to know more about UITests and CppUnitTests, please take a look at this TDF Wiki pages:

Also, keep in mind that looking into the existing tests is the best way to understand how to write a new test. Therefore, make sure that you look into qa/ folders of the modules when you want to add a new test.

by Hossein Nourikhah at April 18, 2024 01:40 PM

April 04, 2024

Miklos Vajna

Improve copy&paste in Calc and elsewhere

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.


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:

We used to show a popup when you clicked on the paste button on the notebookbar

The new paste code in action, handling an image

Import from Google Sheets to Calc: text is auto-converted to a number, bad

Import from Google Sheets to Calc: text is no longer auto-converted to a number, good

HTML import into an active cell edit, only RTF was working there previously

Paste from Google Sheets to Calc: text is no longer auto-converted to a number, good

Paste from Google Sheets to Calc: booleans are now also preserved

Paste from Google Sheets to Calc: number formats are now also preserved

Paste from Google Sheets to Calc: formulas are now also preserved

Paste from Google Sheets to Calc: also handling a single cell

Copy from Calc to Google Sheets: text is now handled, no longer auto-converted to a number

Copy from Calc to Google Sheets: booleans are now handled

Cross-origin iframes also block clipboard access, now fixed

Copy from Calc to Google Sheets: number formats are now also preserved

Copy from Calc to Google Sheets: formulas are now also preserved

Copy from COOL Writer to a text editor: much better result, new one on the right hand side

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 issue on the Online side was cool#8023.

Want to start using this?

You can get a snapshot / demo of Collabora Office 24.04 and try it out yourself right now: try the unstable snapshot. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF's next release too (24.8).

by Miklos Vajna at April 04, 2024 07:50 AM

March 18, 2024

LibreOffice Dev Blog

Test improvement – More and better tests for LibreOffice

One of the areas that can help LibreOffice, but may not directly be visible to the users even though it has a big impact is the quality assurance, is automated testing.  Here, I discuss some areas and notes around improving tests for LibreOffice. First, I start with regressions and bug fixes without a test.

Missing Unit Tests

This is the description from the GSoC ideas page:

While there are some automated tests for LibreOffice, there are not nearly enough. Adding more and better tests helps developers who work on the code to be more productive by allowing them to find regressions as early as possible.

To elaborate more, I should say there are many regressions and bugs in general that are fixed, but lack testing. It is important to have tests for those bug fixes, to avoid such problems in the future. You can see a list of those fixed issues that lack tests here:

If you want to add some new tests for the bug fixes, first you should read the bug report very carefully to understand what is it about, and try to test the fix yourself. You can either use git revert command to revert the fix, and see the problem in action, or try changing back the fix in the code, if it is not too big.

That is important, because you have to see that the test fails without the fix in place, but succeeds when it is applied. This is an essential step when writing the test.

To know more about unit tests, you may look into these Wiki pages:

Porting Existing Test to C++ or Python

Some tests are written in the past, but now have issues because of the way they are written. In this case, porting them can provide improvement.

Tests can be written in multiple languages. At least, C++, Python, Java and BASIC are currently in use for different tests across the LibreOffice code base. Again in the GSoC ideas page, you can read:

There is some support in LibreOffice for automated tests, both at the level of unit tests, and at the level of system tests that drive a full LibreOffice instance. Currently tests can be written in C++, Java, or Python. Various new automated tests should be developed to improve the test coverage.

Tests written exclusively for Java (e.g. the JUnit framework) should be ported to C++ so that they can execute much more rapidly. Similarly, tests that do remote control of an existing LibreOffice instance, should be re-factored to run inside that instance to make debugging much easier.

Almost all JUnitTests and UITests, and also some smoke tests, run as an outside process. To verify, the trick is to remove the soffice(.exe) binary, or to remove its execute permission (on Linux). In this way, out-of-process tests should fail, as they need to run the soffice binary. After a successful build, you can see if this works. For example, try this:

make -d JunitTest_framework_complex

As an example, we have this issue around complex tests that should be ported to Python:

You may find many examples of the previously ported test in the issue page. Keep in mind that usually old Java tests should be removed in the same patch that provides the CppUnitTest port.

Also, you may find examples of UITests ported to C++ from Python. For example, see this patch:

It ports a previously implemented UITest from Python to C++. The result is a faster test, which is more robust.

Focusing on a Specific Area

If you want to add or port some tests, please focus on a specific area of the code. The LibreOffice code base is huge, and consists of more than 200 modules. It is not easy, and in fact not suggested, to work across different applications and modules. It is much better that you pick a specific application, and even inside that application, like Writer, Calc, Impress, etc., focus on a specific module. In this way, it would be much easier to understand the ideas and the way tests are implemented.

How Hard is it to Write / Port a Test?

One important question is around the complexity of writing or porting tests. The answer is not straightforward, as it depends on the area that the test is written. But one can take a look at what others did in the past. By looking into Gerrit or git log, you can find what other people, including GSoC applicants, were able to achieve during their work.

After writing a few tests, or porting a few tests, it may become easier for you to write more tests. Another thing is that you don’t have to write tests from scratch. There are many tests available in the LibreOffice code base, and you can create your new test based on existing tests and customize it to match the purpose of the issue you are working on.

by Hossein Nourikhah at March 18, 2024 06:45 AM

March 01, 2024

Miklos Vajna

February 11, 2024

Caolán McNamara

coverity 2022.6.0 and LibreOffice

After a long slog since November when the previous version of coverity was EOLed and we had to start using 2022.6.0 with its new suggestions for std::move etc, LibreOffice is now finally back to a 0 warnings coverity state

by caolan ( at February 11, 2024 06:02 PM

February 06, 2024

Miklos Vajna

Fixing multi-view programming challenges in Calc and elsewhere

This post describes some challenges around having multiple views of one opened document in LibreOffice core, when those views belong to LOK views, representing different users, with their own language, locale and other view settings.

This work is primarily for Collabora Online, but is useful for all clients of the LOK API.


LOK views are meant to represent separate users, so we need to make sure that when a user sets their preferences and trigger an action, then the response to that action goes to the correct view, with the correct view settings.

This is different from the desktop LibreOffice use-case, where multiple windows are still meant to share the same user name, language, undo stack and so on.

Results so far

In this post, I would like to present 4 small improvements that recently happened to the LOK API to provide this wanted separation of views.

The first was an issue where two users were editing the same document, one busily typing and the other clicked on a link in Calc. What could happen sometimes is the link popup appeared for the user who typed, not for the user who clicked on the link:

Link popup is actually on the left, should be on the right, now fixed

This specific problem can be fixed by making sure that link click callbacks are invoked synchronously (while the clicking view is still active) and not later, when the current view may or may not be the correct one.

It turns out the same problem (async command dispatch) affects not only hyperlinks, but many other cases as well, where we want to stay async, for example, when one dialog would invoke another dialog, like the Calc conditional format -> add dialog:

Calc conditional format add dialog appearing on the left, should be on the right, now fixed

There you don't want to change async commands into sync commands, because that may mean spinning the main loop inside a dialog, resulting in nested main loops. This can be fixed by making sure that async commands to be dispatched (sfx2 hints in general) are processed in a way that the current view at dispatch & processing is the same, which is now the case.

The third problem was around wrong language & locale in the status bar:

Unexpected English strings in localized statubar UI, now fixed

This is not simply a problem of missing translation, the trouble was that the status bar update is also async and by the time the update happened, the locale of the view on the left was used, for a string that appears on the right.

The way to fix this is to perform the update of toolbars/statusbar/etc (in general: SfxBindings) in a way that the language at job schedule time and at UI string creation time is the same.

The last problem was quite similar, still about bad language on the UI, but this time on the sidebar:

Unexpected English strings in localized sidebar UI, now fixed

This is similar to the statusbar case, but the sidebar has its own executor for its async jobs, so that needed a fix similar to what the statusbar already had, now done.

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 the latest Collabora Online Development Edition 23.05 and try it out yourself right now: try the development edition. Collabora intends to continue supporting and contributing to LibreOffice, the code is merged so we expect all of this work will be available in TDF's next release too (24.8).

by Miklos Vajna at February 06, 2024 08:49 AM

January 25, 2024

Marius Popa Adrian

Firebird 5.0 Is Released

Firebird Project is happy to announce general availability of Firebird 5.0 — the latest major release of the Firebird relational database for Windows, Linux, MacOS and Android platforms.This release introduces improvements in areas of performance, multithreaded processing (including backup, restore, sweep), SQL queries profiling, with better scalability and numerous enhancements in SQL

by Popa Adrian Marius ( at January 25, 2024 10:29 AM

January 12, 2024

LibreOffice Design Blog

Comments in Sidebar

Using comments is a key feature in text processing. A typical workflow might be to review a document where notes are made by different colleagues. LibreOffice Writer currently shows these comments in the document margin, which is limited to the page height, ending up in the need to scroll long text (even while editing [1]) and eventually in paging-like interactions if the number of comments exceed the total size.…

by Heiko Tietze at January 12, 2024 01:22 PM

December 18, 2023

Marius Popa Adrian

Call For Testing Firebird ODBC Driver for Firebird 3.x

The new version of Firebird ODBC driver is in Beta stage now. Version 3.0.0 Beta is available for testing on Windows. It works only with Firebird 3+ , and requires fbclient.dll from Firebird 3 or above. download, test, and report any issues!Issues can be reported here:

by Popa Adrian Marius ( at December 18, 2023 07:20 PM

November 19, 2023

Stephan Bergmann

I like it here. Can I stay?

(And do you have a vacancy for a back-scrubber?)

Thank you, Red Hat, for generously letting me work for so long on stuff that is near and dear to my heart. At the intersection of theory and practice, of compiler technology and the LibreOffice code base. But, to keep doing what I love, I need to move on.

So, thank you, allotropia, for having me. I’m excited.

And, above all, thank you, LibreOffice, family of friends. Lets make sure to keep this a happy family, one that Tolstoy would have nothing to write home about. With quarrels and arguments, for sure; feud even. But happy at heart. I wish to keep meeting you all for years to come, virtually, and for a feast at FOSDEM or LOCon. And booze.

To paraphrase Hamburger Tafel (donations needed, btw), “Wir haben LibreOffice noch lange nicht satt.”

Have fun, stay safe, peace,

by stbergmann at November 19, 2023 10:58 AM

November 12, 2023

Robert Riemann

Is developing word processing software hard?

Hello LibreOffice Planet!

This is my first blog post on the topic of LibreOffice. Let me quickly explain my link to LibreOffice. I work for a data protection authority in the EU and help navigate the digital transformation of our office with about 100 staff members. While many of our partner organisations adopt Microsoft 365, our office decided to pilot Nextcloud with Collabora Office Online.

In the future, I want to blog (in my personal capacity) about my thoughts related to the use of alternative word processing software in the public sector in general and in our specific case.

As there are no dedicated resources for training, preparation of templates etc., during the pilot of LibreOffice, the experience so far covers a large spectrum of user satisfaction. Generally, our staff has been spent years of their life using Microsoft Office and has the expectation that any other software works the same way. If it does not, they send an email to me (best case) or switch back to Microsoft Office.

During the week, I discussed again some smaller LibreOffice bugs. Then, I showed this weekend some FOSS Blender animated short videos to family members. It seems that Blender is more successful in its domain than LibreOffice. Is that possible? Or are animated short videos just more capturing due to their special effects? 😅

You can watch the 1min Blender animated short movie “CREST� on Youtube or the making-off. The latter you find here below.

I find it very inspiring to see what talented artists can do with Blender. For my part, I have once installed Blender and deinstalled it. Back then it was not easy to use for people not familiar with video animation software. Blender competes with proprietary software such as Maya or Cinema 4D. The latter is about 60 USD per month in the annual subscription plan. Not exactly cheap.

Then, I read in the fediverse about people working with LibreOffice:

I just tried to use #LibreOffice #Draw to draw some arrows and boxes onto JPEG images for emphasizing stuff.

The UX is really bad for somebody not working with Draw all the time.

Whatever I do, instead of drawing onto the image, the image gets selected instead.

Could not find any layer-sidebar.

Could not scale text without starting the “Character …� menu, modifying font size blindly + confirming > just to see its effect and then start all over.

Dear #FOSS, we really should do better.

— Author Karl Voit (12 November 2023 at 14:51)

In my past, I have worked on online voting systems. They are not very good yet despite years of efforts. xkcd dedicated a comic to voting software

Elections seem simple—aren’t they just counting? But they have a unique, challenging combination of security and privacy requirements. The stakes are high; the context is adversarial; the electorate needs to be convinced that the results are correct; and the secrecy of the ballot must be ensured. And they have practical constraints: time is of the essence, and voting systems need to be affordable and maintainable, and usable by voters, election officials, and pollworkers.

— Author Matthew Bernhard et al. in their paper Public Evidence from Secret Ballots from 2017

What is the unique challenge of developing word processing software? Happy to hear back from you in the blog comments or on the companion fediverse post!

by Robert Riemann ( at November 12, 2023 10:20 PM

November 01, 2023

Marius Popa Adrian

Valgrind 3.22 is available

News via reddit : "We are pleased to announce a new release of Valgrind, version 3.22.0,available from the release notes below for details of changes.Our thanks to all those who contribute to Valgrind's development. Thisrelease represents a great deal of time, energy and effort on the partof many people.Happy and productive debugging and

by Popa Adrian Marius ( at November 01, 2023 02:01 PM

October 27, 2023

Naruhiko Ogasawara

LOUCA23 (LibreOffice Conference Asia x UbuCon Asia 2023)

Long time no see, readers!  Very sorry for my laziness.

I attended LibreOffice Conference Asia x UbuCon Asia 2023 (LOUCA23) in Surakarta, Indonesia, on October 7~8.

This was the second time LibreOffice Conference Asia has been held in Tokyo in 2019, as it could not occur due to the COVID-19 pandemic.  UbuCon Asia was first held online in 2021, and the first in-person event was held in Seoul, Korea in 2022, and this still was the second in-person event.

I was burnt out by the pandemic and had stopped most of my OSS activities, but I still had many friends in the OSS world, so I went to Indonesia to meet with them.  

Therefore, I had initially intended to be a general participant.  Still, a friend of the speaker was suddenly unable to attend due to illness, so I gave a presentation in his place.  Here is my slide:

As mentioned, I am halfway out of OSS activities, but I know what my friends are doing, so it was not so difficult to talk about this subject.

Although I cannot say that the presentation itself was a great success (due to my English language skills), I was pleased because the audience was very responsive and easy to talk to, and many people approached me after the presentation was over.

Other than my presentation, I was naturally interested in the two keynote speeches by The Document Foundation and was surprised and grateful when Franklin Weng mentioned my name as an "Asian activist to be featured at the LibreOffice Latin America Conference. "

I listened to Muhammad Syazwan Md Khusaini's "Hands-On on Translating in Ubuntu" with great interest; however, I was a bit surprised to hear from a friend that many Indonesians use English for desktop environments and applications like LibreOffice.  I recognized that this was quite different from Japan.

The event itself was just as enthusiastic. Unlike OSS events in Japan (laugh), the participants were young, and there were many women. I was also surprised to see junior high school students among the speakers.

Both lunch and dinner were complimentary, and the one-day Surakaruta city tour the day after the event was delightful.  I appreciated the hospitality of the local staff.

This was my first time in Indonesia, and although short, I enjoyed many things, including the train trip. In Yogyakarta, I visited a museum and learned a lot about the history of Indonesia. However, I was overcharged by the tuk-tuk in Yogya.

I know it was a lot of work for the organizers, but as I have many friends in LibreOffice and am also an Ubuntu user, I was very grateful that the two events were co-hosted. Thanks to all the sponsors, global/local organizers, and everyone who talked to me there.  See you soon!

by Naruhiko Ogasawara ( at October 27, 2023 01:13 PM

October 11, 2023

Marius Popa Adrian

Firebird 5.0 Release Candidate 1 is available for testing

Firebird Project announces the first Release Candidate of Firebird 5.0, the next major version of the Firebird relational database, which is now available for testing on all supported platforms (Windows, Linux, MacOS, Android).This Release Candidate demonstrates the complete set of features and improvements developed for the new release. Release Candidates are generally considered stable enough

by Popa Adrian Marius ( at October 11, 2023 02:47 PM

Flamerobin 0.9.9 Snapshot released with a few fixes

Flamerobin 0.9.9 Snapshot released with a few fixesWhat’s Changed :Fix Mac OS compilation by @rlakis in #328Fix saving style error and code scanning alert by @arvanus in #330Improve SQL statistics by @arvanus in #331New Contributors :@rlakis made their first contribution in #328

by Popa Adrian Marius ( at October 11, 2023 02:46 PM