- Sync with Dave, catch up with Thorsten, slides, lunch.
-
Published the next strip: The joy of elections:
- Monthly all-hands call, admin.
This is a feed aggregator that collects what LibreOffice and Document Foundation contributors are writing in their respective blogs.
To have your blog added to this aggregator, please mail the website@global.libreoffice.org mailinglist or file a ticket in Redmine.
LibreOffice is made by hundreds of people around the world. In many countries, we have active communities that organise events, do local marketing, and help users in their local language.
But while we have many users and contributors in the United States of America, so far we haven’t built up an active local community. Of course, part of this is due to the size of the country – the US is huge, so getting people together isn’t easy.
Nonetheless, we want to try! There are many things we’d like to do in the US with LibreOffice, such as:
To get things going, we’ve created some communication groups and a social media channel. Our Discord server has a few channels which are also bridged to Matrix, so join one of those and let’s start discussing ideas. We also have the LibreOfficeUS Mastodon account where we’ll be posting updates.
We look forward to seeing you there 
We’re just over half-way through the Month of LibreOffice, November 2025. And already, 219 contributors have won cool LibreOffice sticker packs! Details on how to claim them will be provided at the end of the month, but if you don’t see your name (or username) on that page, it’s not too late to join…
There are many ways you can help out – and you don’t need to be a developer. For instance, you can be a:
Digital sovereignty, or the ability of nations, organisations and individuals to control their own digital destiny, is a fundamental issue of the 21st century. At the heart of this challenge lies a seemingly trivial question: who controls the format of the documents that contain our intellectual property or personal information?
In this context, the standard and open Open Document Format (ODF) – the native format of LibreOffice documents, also supported by other suites – is the fundamental technology for those seeking true digital independence.
Digital sovereignty includes the ability to control access to one’s own information without depending on third parties, to make independent technological choices based on one’s own needs, to ensure independent access to strategic data without depending on the commercial interests of Big Tech, and to maintain this technological self-determination in the face of market consolidation.
When government agencies, businesses, or citizens store their documents in proprietary formats controlled by Big Tech, they surrender part of their sovereignty and depend on these external entities to access their own information.
Why document formats are important for sovereignty
Document formats are infrastructure, which—like roads, power grids, or telecommunications networks—are fundamental to the functioning of modern societies. Consider what happens when strategic documents exist only in formats controlled by a single vendor:
Why ODF is the only tool for digital sovereignty
ODF is governed by OASIS, an international standardisation organisation that protects its transparent development, and is published as ISO/IEC 26300-2015 (and soon ISO/IEC 26300-2025). Unlike proprietary formats, ODF specifications are public and can be freely implemented, are developed through a transparent, multi-stakeholder process, are not controlled by a single government or company, and are subject to international standardisation bodies.
This means that governments and companies can participate in defining the format specifications, rather than being forced to passively accept changes imposed by a single vendor based on its commercial strategies.
Thus, ODF specifications allow anyone to create an office suite that natively supports the format and promotes digital sovereignty, without any authorisation, licence fees or fear of legal action, while supporting the local software industry.
ODF enables true interoperability, not only between different software packages, but also between countries, languages and political systems. A document created in Brazil can be opened and edited in India, Germany or Japan using locally developed software. This breaks …
Berlin, 13 November 2025 – LibreOffice 25.8.3, the third minor release of the free, volunteer-supported office suite for personal productivity in office environments, for Windows, MacOS and Linux, is now available at www.libreoffice.org/download. The new version fixes 70 issues compared to the previous release, which came out in October [1].
LibreOffice 25.8.3 is based on the LibreOffice Technology, which enables the development of desktop, mobile and cloud versions – either from TDF or from the ecosystem – that fully supports the two document format standards: the open ODF or Open Document Format (ODT, ODS and ODP), and the closed and proprietary Microsoft OOXML (DOCX, XLSX and PPTX). Products based on the LibreOffice Technology are available for all major desktop operating systems (Windows, macOS, Linux and ChromeOS), mobile platforms (Android and iOS) and the cloud.
For enterprise-class deployments, TDF recommends the LibreOffice Enterprise optimized versions from ecosystem companies, with dedicated value-added features and other benefits such as SLAs and security patch backports for three to five years (www.libreoffice.org/download/libreoffice-in-business/).
English manuals for the LibreOffice 25.8 family are available for download at https://books.libreoffice.org/en/. End users can get first-level technical support from volunteers on user mailing lists and Ask LibreOffice website: ask.libreoffice.org.
Downloading LibreOffice
All available versions of LibreOffice for the desktop can be downloaded from the same website: www.libreoffice.org/download/. To improve the interoperability with Microsoft 365, we suggest installing the Microsoft Aptos font from this web page: learn.microsoft.com/en-us/typography/font-list/aptos.
LibreOffice enterprise and individual users can support The Document Foundation and the LibreOffice project by making a donation: www.libreoffice.org/donate.
[1] Fixes in RC1: wiki.documentfoundation.org/Releases/25.8.3/RC1. Fixes in RC2: wiki.documentfoundation.org/Releases/25.8.3/RC2.
Last Saturday, November 8, I have managed a workshop at SFScon on Font management for document interoperability in LibreOffice. The workshop aimed to demonstrate how to configure and manage the LibreOffice font replacement feature, one of the key elements of document interoperability. Although font replacement on the fly is a long-standing LibreOffice feature, it is rather unknown and must be configured and managed properly in order to substitute proprietary fonts, which are standard on Windows and macOS and have been used as a lock-in tool for years, with metrically compatible free fonts.
In September 2020, I wrote the blog post LibreOffice Tips & Tricks: Replacing Microsoft Fonts, which explained how to create a Font Replacement Table (available in Tools > Options > LibreOffice > Fonts) to instantly replace Microsoft’s proprietary fonts with metrically equivalent free fonts, available from Google Fonts and other websites. However, I recommend using Google Fonts for legal compliance, as they provide the font, licence and all other documents from the font designer. This post prompted several responses and inspired Jean-François Nifenecker, a volunteer contributor, to develop the FontsSubstTableExporter extension, which creates an extension embedding the font’s replacement table for easy duplication or backup, as well as the resulting FontSubstTable, which sets the font’s substitution table values.
During the webinar, I used a short LibreOffice Impress presentation to help the audience follow my talk more easily:
SFScon Font Management 2025 Download the Slide Deck
I opened the webinar by showing the 2020 blog post and its associated font replacement table. I then presented the updated table, as Spartan — one of the free fonts — has evolved into League Spartan. I also explained how the situation has changed radically since 2020, as Microsoft has deprecated ClearType fonts (Calibri, Candida, Candara, Consolas, Constantia, Corbel and Segoe for Western languages) and now uses Aptos as the default font for Western languages. Although Aptos is Microsoft proprietary, it has a weaker licence which only prohibits redistribution. As such, it can be downloaded and installed by all users (including Linux users) provided the download is from the official Microsoft Aptos Page.
I also announced that, ideally before the release of LibreOffice 26.2 in February 2026, I will update the FontSubstTable extension to include all Microsoft proprietary fonts with restrictive licences. These are fonts that require replacement as they cannot be installed by Linux users or those without a Microsoft Windows or Microsoft 365 licence. I will also try to generate additional FontSubstTable extensions for the most commonly used fonts in DOCX, XLSX and PPTX files. Thanks to AI, I now have access to a list of these fonts in just a few seconds, which would have taken me weeks to compile manually. These extensions will be available for general use and for specific verticals, such as visual design.
Digital documents in proprietary formats often become inaccessible within a few years due to undocumented changes to the XML schema that are intentionally employed for lock-in purposes. To avoid this problem, it is advisable to use the Open Document Format (ODF) not only for everyday tasks, but also for long-term storage. This ensures that documents remain accessible for years or even generations.
Without this approach, government documents, academic research, legal documents and corporate archives risk becoming true digital orphans — files that exist, but cannot be read. This is not so much because the software that created them is obsolete, but because the XML schema has been modified to make the files readable by a specific version of a single software program. However, the layering of changes makes them unreadable by any software in the long term.
Why is ODF suitable for archiving?
ODF (ISO/IEC 26300 and subsequent versions) is an open standard, managed transparently by OASIS. Its development process and specifications are documented and publicly accessible, unlike proprietary formats, where the process is undocumented and the ISO/IEC specifications do not reflect the reality of the format. This means that even if the current software disappeared, developers could create new programmes compatible with the standard to handle the files and access their content.
Furthermore, ODF files are compressed archives (ZIP) containing XML files based on a schema that can be easily read by non-technical users, enabling anyone to extract and interpret the content. This transparency of format is a fundamental element of its archival value. In contrast, the XML schema of proprietary files is intentionally designed to be unreadable. In this sense, it is a perfect example of how a language created for simplification, such as XML, can become a subtle lock-in tool if used contrary to its nature.
Finally, ODF maintains strong backwards compatibility between versions. This means that all files created with ODF 1.0 in 2005 — immediately after standardisation by OASIS — can be opened without issue by applications released in 2025. This stability is intentional; the format was designed with long-term preservation in mind.
Best practices for archiving in the ODF format
Although newer versions add functionality, the best option for long-term archiving is to use a version recognised by ISO/IEC, such as ODF 1.2 (ISO/IEC 26300-1:2015) or, in the near future, ODF 1.3 (ISO/IEC 26300:2025). This is because it is mature and well documented, and will remain compatible for decades, offering an excellent balance between functionality and breadth of support.
For documents where faithful visual reproduction is important, it is advisable to embed fonts in ODF files to avoid font substitution issues when files are opened years later in a different environment to the one used to create them.
Additionally, all resources related to the documents (images, graphics, etc.) should be embedded in the ODF file rather than linked externally because external links are at risk of breaking over time if the original file is moved, which could …
Writer has some support for interdependent (or hierarchical) tracked changes: e.g. the case when you have a delete on top of an insert. See the third post for background.
This work is primarily for Collabora Online, but the feature is available in desktop Writer as well.
Interdependent changes mean that the UI shows one type of change on top of another change, e.g. formatting on top of insert. Writer knows the priority of each type, so in case you have an insert or delete change and on top of that you have a formatting, then the UI will look "through" the formatting and work on the underlying insert or delete when you navigate with your cursor to a position with multiple changes and you press Accept on the Review tab of the notebookbar.
Usually this is what you mean, but what if you want to work on the formatting at the top, directly? You can now open the Manage Changes dialog using the Manage button on the Review tab of the notebookbar and if you go to the formatting change row of the dialog, then pressing Accept there will accept the formatting change, not the insert or delete change. This is possible, because the dialog gives you a way to precisely select which tracked change you want to work with, even if a specific cursor position has multiple tracked changes.
Here is a sample ins-then-format.docx document from the core.git testcases, the baseline has an
insertion, and part of that is covered by an additional formatting change on top:
Interdependent tracked change: baseline
If you just go in the middle of the document and press Accept, that will work with the more important insert change, so the result looks like this:
Interdependent tracked change: default accept result
But now you can also open the Manage Changes dialog, to be more specific by directly selecting the formatting change:
Interdependent tracked change: direct accept via the dialog
And when you accept the formatting change directly, the result will be just the insert change:
Interdependent tracked change: direct accept result
You can save and load the results in both DOCX and ODT, as usual.
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. Core side:
You can get a development edition of Collabora Online 25.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 (26.2).
Love LibreOffice? Join the project and help to make it even better – get involved in the Month of LibreOffice, November 2025! Over the next four weeks, hundreds of people around the world will collaborate to improve the software – and you can help them. There are many ways to get involved, as you’ll see in a second.
And best of all: everyone who contributes to LibreOffice in November can claim a cool sticker pack, and has the chance to win extra LibreOffice merchandise such as mugs, hoodies, T-shirts, rucksacks and more (we’ll choose 10 participants at random at the end):
There are many ways you can help out – and you don’t need to be a developer. For instance, you can be a…
We’ll be updating this page every few days with usernames across our various services, as people contribute. So dive in, get involved and help make LibreOffice better for millions of people around the world – and enjoy your sticker pack at the end as thanks from us! And who knows, maybe you’ll be lucky enough to win bonus merch as well…
Open Document Format (ODF) is an open standard for office documents – texts, spreadsheets, presentations and more – that is flexible and interoperable. As with any other digital format, its security is a key concern, as ODF files often contain sensitive information that, without adequate protection measures, can be exposed, tampered with or tracked.
This post analyses how ODF handles security, focusing on encryption, digital signatures and metadata management: three features that protect documents from prying eyes and tampering.
Encryption: content locking
ODF supports file-level encryption using standard algorithms. When you save an ODF document with a password, the content is compressed and then encrypted using AES (Advanced Encryption Standard), typically with a 256-bit key.
Here’s what happens behind the scenes:
This is encryption based on open and verified algorithms, sufficiently strong when implemented correctly, whose security depends largely on the strength of the password. Users should therefore always use long, unique passwords, preferably created by a password generator.
Unfortunately, not all applications that support the ODF format implement encryption in the same way, with possible repercussions on interoperability.
Digital signatures: who modified the document?
Digital signatures guarantee authenticity and integrity, and show who created or modified the ODF file, and whether it has been modified by another user since its creation.
How it works:
This makes it possible to verify the origin of the document, but verifying signatures requires access to the signer’s public key or certificate. If the workflow involves multiple people, multiple signatures are supported. Any changes to the file after signing invalidate the signature.
Unfortunately, not all office suites that support ODF consistently display or validate signatures.
Metadata management: a potential information leak
Metadata can unintentionally disclose various information, including sensitive information such as usernames, file paths, software versions, timestamps (creation and save dates), and even content revision history.
What does metadata contain?
Malicious actors can extract metadata for social engineering, document tracking, or profiling purposes. To …
Here’s our summary of updates, events and activities in the LibreOffice project in the last four weeks – click the links to learn more…
Please confirm that you want to play a YouTube video. By accepting, you will be accessing content from YouTube, a service provided by an external third party.
If you accept this notice, your choice will be saved and the page will refresh.
Berlin, 30 October 2025 – The Document Foundation announces the release of LibreOffice 25.2.7, the final maintenance release of the LibreOffice 25.2 family, available for download at www.libreoffice.org/download [1]. Users of LibreOffice 25.2.x should update to LibreOffice 25.8.x, as LibreOffice 25.2.x is approaching the end of its support period.
LibreOffice 25.2.7 is based on the LibreOffice Technology, which enables the development of desktop, mobile and cloud versions – either from TDF or from the ecosystem – that fully supports the two document format standards: the open ODF or Open Document Format (ODT, ODS and ODP), and the closed and proprietary Microsoft OOXML (DOCX, XLSX and PPTX).
Products based on the LibreOffice Technology are available for all major desktop operating systems (Windows, macOS, Linux and ChromeOS), mobile platforms (Android and iOS) and the cloud.
For enterprise-class deployments, TDF recommends a LibreOffice Enterprise optimized version from one of the ecosystem companies, with dedicated value-added features and other benefits such as SLAs and security patch backports for three to five years (www.libreoffice.org/download/libreoffice-in-business/).
English manuals for the LibreOffice 25.2 family are available for download at books.libreoffice.org/en/. End users can get first-level technical support from volunteers on the user mailing lists and the Ask LibreOffice website: ask.libreoffice.org.
Downloading LibreOffice
All available versions of LibreOffice for the desktop can be downloaded from the same website: www.libreoffice.org/download/.
LibreOffice users, free software advocates and community members can support The Document Foundation and the LibreOffice project by making a donation: www.libreoffice.org/donate.
[1] Fixes in RC1: wiki.documentfoundation.org/Releases/25.2.7/RC1. Fixes in RC2: wiki.documentfoundation.org/Releases/25.2.7/RC2.
A modern C++ wrapper for the Firebird database API.Documentation | Repositoryfb-cpp provides a clean, modern C++ interface to the Firebird database engine. It wraps the Firebird C++ API with RAII principles, smart pointers, and modern C++ features.Features Modern C++: Uses C++20 features for type safety and performanceRAII: Automatic resource management with smart pointersType Safety:
In LibreOffice C++ code, there are many cases where developers have string literals that should be used in the code. If these are messages in the graphical user interface (GUI), they should be added to the translatable messages. But, there are many cases where the string literals has nothing to do with other languages, and they should be used as they are. In this case, enumarrays are helpful. Although they are not limited to string literals, and can be used for any data.
In old C code, using #define was the preferred way one could give a name to a string literal or other kinds of data. For example, consider this code:
const char[] FRAME_PROPNAME_ASCII_DISPATCHRECORDERSUPPLIER = "DispatchRecorderSupplier"; const char[] FRAME_PROPNAME_ASCII_ISHIDDEN = "IsHidden"; inline constexpr OUString FRAME_PROPNAME_ASCII_LAYOUTMANAGER = "LayoutManager"; const char[] FRAME_PROPNAME_ASCII_TITLE = "Title"_ustr; const char[] FRAME_PROPNAME_ASCII_INDICATORINTERCEPTION = "IndicatorInterception"; const char[] FRAME_PROPNAME_ASCII_URL = "URL";
And also, the relevant states:
#define FRAME_PROPHANDLE_DISPATCHRECORDERSUPPLIER 0 #define FRAME_PROPHANDLE_ISHIDDEN 1 #define FRAME_PROPHANDLE_LAYOUTMANAGER 2 #define FRAME_PROPHANDLE_TITLE 3 #define FRAME_PROPHANDLE_INDICATORINTERCEPTION 4 #define FRAME_PROPHANDLE_URL 5
Although this C code still works in C++, it is not the desired approach in modern C++.
In modern C++ code, you can use enumarry, which is defined in o3tl in LibreOffice. The above code becomes:
enum class FramePropNameASCII
{
DispatcherRecorderSupplier,
IsHidden,
LayoutManager,
Title,
IndicatorInterception,
URL,
LAST=URL
};
And also, the string literal definitions:
constexpr o3tl::enumarray<FramePropNameASCII, OUString> FramePropName = {
u"DispatchRecorderSupplier"_ustr,
u"IsHidden"_ustr,
u"LayoutManager"_ustr,
u"Title"_ustr,
u"IndicatorInterception"_ustr,
u"URL"_ustr
};
The names are much more readable, as they do not have to be ALL_CAPPS, as per convention for symbolic constants in C. Their usage is also quite easy. For example, one can use [] to access the relevant string literal:
- xPropSet->getPropertyValue( FRAME_PROPNAME_ASCII_LAYOUTMANAGER ) >>= xLayoutManager; + xPropSet->getPropertyValue( FramePropName[FramePropNameASCII::LayoutManager] ) >>= xLayoutManager;
In LibreOffice, enumarrays are not limited to string literals, and they can be used with other data. This task is filed as tdf#169155, and if you like, you may try finding some instances in the code and modernize it using enumarrays.
| Imprint Privacy Policy | |
|
The Document Foundation is not responsible for the content on planet.documentfoundation.org. However - if you have any concerns about content please contact act Uwe Altmann for moderation. Copyright information: Unless otherwise specified in the author's blog, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the "Mozilla Public License v2.0". "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy. |
 |
| this site runs a modified version of planet.opensuse (https://github.com/openSUSE/planet.opensuse.org) © 2010 Pascal Bleser and the openSUSE Community. | |