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.
por Italo Vignoli
El formato Open Document (ODF) es un estándar abierto para documentos de oficina (textos, hojas de cálculo, presentaciones y más) que es flexible e interoperable. Al igual que con cualquier otro formato digital, su seguridad es una …
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:
On October 4 and 5, the LinuxDays 2025 event took place at the Faculty of Information Technology (Czech Technical University). It combined stands for free and open source software projects with workshops and talks, and the LibreOffice community was there, represented by Zdeněk Crhonek, Petr Valach, Stanislav Horáček and Mike Saunders.
At the stand, we had flyers explaining what LibreOffice is and how it can be used in various contexts (homes, businesses etc.) along with stickers, beer/coffee mats, and printed versions of the handbooks, to show how extensive the documentation for LibreOffice really is. We also had a fun quiz for participants to try.
During the two days, many visitors came to our stand, gave feedback and asked questions. Of course, at an event focused on Linux, most visitors already knew what LibreOffice is (and many used it regularly). But they gave us some useful feedback and asked about new features, including:
Anyone who wants these features or improvements in LibreOffice is welcome to join our project and help to make it happen, or fund a developer. And we plan to be at more events in the coming months – stay tuned to this blog and our Mastodon account for news!
Love LibreOffice development? Want to turn your passion into a paid job? We are The Document Foundation (TDF), the non-profit entity behind LibreOffice. We’re passionate about free software, the open source culture and about bringing new companies and people with fresh ideas into our community.
To improve the scripting support of LibreOffice, the office productivity suite for over 200 million users around the globe, we’re searching for a developer (m/f/d) to start work (from home) as soon as possible. This is what you’ll do:
Examples of tasks:
What we want from you:
Previous contributions to FOSS projects (show us your repos!) are a plus. A previously established relationship within the developer community, as well as with other teams such as QA is a plus, but it is not mandatory at the start and can be achieved during the work itself.
As always, TDF will give some preference to individuals who have previously shown a commitment to TDF, including but not limited to members of TDF. Not being a member does not exclude any applicants from consideration.
All jobs at The Document Foundation are remote jobs, where you can work from your home office or a co-working space. The work time during the day is flexible, apart from a few fixed meetings. The role is offered as full-time (ideally 40 hours per week). While we prefer full-time for the role, part-time applications, or proposals to grow the hours over time, will be considered. Candidates that are resident in (or willing to relocate to) Germany will be employed directly by TDF. Otherwise, external payroll services will be used if available in the candidate’s country of residence.
Are you interested? Get in touch!
TDF welcomes applications from all suitably qualified persons regardless of their race, sex, gender, disability, religion/belief, sexual orientation or age. Don’t be afraid to be different, and stay true to yourself. We like you that way! 
We’re looking forward to receiving your application, including information about you (your resume), when you are available for the job, and of course your financial expectations. We expect you to provide details about your C++ experience. Pointing to public repositories with your code is very helpful. Please send us an e-mail to developers …
Libreitalia Conference 2025 was organized by Marco Marega – a LibreItalia and TDF Member – in Gradisca d’Isonzo, near the border with Slovenia, in Gorizia’s province. Gradisca is a very nice fortified city surrounded be beautiful parks. The conference venue was the historical Monte di Pietà palace, that the municipality administration kindly allowed to use.
Gorizia, the administrative center, is a city divided in two parts, half in Italy (Gorizia itself), and half in Slovenia (Nova Gorica). Together, they are the 2025 European’s Capital of Culture.
The conference was very interesting, with members coming from many different cities. Furio Honsell – a councilman of Friuli Venezia Giulia region and also a former mayor of the city of Udine and rector of Udine University – was the special guest, introducing his regional law proposal to promote free software adoption in local administrations.
Italo Vignoli had two talks, one about the end of Windows 10 support and the other about the 20th anniversary of the ODF format. Marco Gaiarin had a brief talk about good practices for free software adoption. Giulia Bimbi spoke about Italian laws regulating free software adoption in public administrations.
Blerta Mecani and Moreno Cervesato of PNLUG, Pordenone Linux Users’ group, talked about their activities, with a special focus on their project leveraging Italian rules which permit to legally recover used PCs, install Linux on them and then donate them to schools.
Sonia Zorba and Andrej Sossi presented Trieste Linux Users group activities, and their game to learn command line.
Marco Marega opened the day introducing free software and LibreOffice to newbies.
In the afternoon, he explained – together with Gabriele Ponzo – how to contribute to the LibreOffice project, focusing on the tools used to localize the software’s UI and the documentation.
Marco did a very good job in organizing the event, and was very happy to see many community members meeting in his hometown. The conference was a great occasion to strengthen our community.
On November 22/23, some of the conference attendees will meet again in Pordenone, another administrative center of Friuli Venezia Giulia, at the Linux Arena within the Radioamatore2 fair.
por Italo Vignoli
Las personas sin discapacidades no tienen ningún problema para ver documentos en la pantalla de una computadora, pero hay personas con discapacidad visual o ciegas que utilizan lectores de pantalla y navegación por teclado. Los archivos ODF …
People without disabilities have no problem viewing documents on a computer screen, but there are people with visual impairments or who are blind who use screen readers and keyboard navigation. ODF files have everything they need to be accessible to these people too, and this is a short guide to creating documents that they can use without any problems.
In the context of digital document management, accessible means that a document can be consulted without any constraints related to the ability to see or move one’s hands with dexterity. This means that people can quickly find what they are looking for (headings, lists, indexes), understand the meaning of graphs and images thanks to descriptions, tables are simple and clear, and they can read the text because the contrast is good and the links make sense even out of context.
To achieve this result, which does not discriminate against people based on their physical characteristics, it is necessary to follow a few simple rules when creating a document. Obviously, we are talking about LibreOffice, although the rules also apply to other office suites (although in this case the document format will be proprietary and not standard).
1. Use styles for headings (not just bold text)
2. Create lists using the appropriate buttons
3. Add alternative text to every image, graph or icon
4. Create simple tables
5. Create self-explanatory links
6. Set the language
Gustavo Pacheco send us this report on the activities of the sixth edition of the Latin American LibreOffice Congress, held in Habana, Cuba, from October 6 to 9, 2025:
Official photo Cibersociedad 2025 + Latin American LibreOffice Congress
With a completely different organizational model than in previous years, our conference was held as a prominent section within another broader event: the Cibersociedad 2025 congress.
Held every two years by the Union of Computer Scientists of Cuba, Cibersociedad aims to be a space for innovation and proposals for the construction of a more sustainable and equitable digital future.
For the events in 2019 in Asunción, 2022 in Brasília and 2023 in Mexico City, we had the support of universities, and in 2024 in Montevide, support local communities. But 2025 marked a new moment for the Latin American organizing committee. On this occasion, our relationship was established with an organization of professionals, the UIC, which contributed all its knowledge and structure to the planning of a joint event.
The idea arose from the proposal of the president of the UIC in 2023, Ailyn Febles, who, in contact with Gustavo Pacheco, presented the invitation to hold the conference in Cuba, motivated by the legacy left by Carlos Parra (1961-2022), an active member of both the UIC and theTDF.
As in 2023 we already had our congress confirmed for Mexico City, we would talk again during that year to align the possibilities.
In addition to the excellent event in Mexico City, at that time we also had the Montevideo congress. That one was an atypical event, as it was carried out as a contingency to the originally planned place, the state of Rio Grande do Sul, in Brazil, affected by the largest flood of the century in May 2024. The event was only saved from being canceled thanks to the support of the Uruguayan community. Thus, for the first time, the congress was held in a public space outside a university: a challenge also for local volunteers.
We did not reach the expected face-to-face audience, but we had a meeting with exceptionally high-quality participations. With the participation of Gastón Hannay in the graphic design activities, we achieved the objective of the congress to always bring, as a minimum, a new permanent volunteer for the project, in addition to interesting results from the participation among the members, such as the development of new formulas for Calc, by Xisco Fauli, based on the presentation of the practical experience of Ismael Fanlo with spreadsheet users.
With the results of 2024, we began planning for 2025 based on the premise of taking advantage of our participation in the event to visit universities, public institutions, third sector entities, local communities, etc., in their own organizational spaces. This idea was very well received by the then new president of the UIC, Omar Correa.
The initiative would also fit the way the event would be carried out. By incorporating our event into a larger one, we obtained the benefit …
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.
This year, LibreOffice was once again a mentoring organization in the Google Summer of Code (GSoC), a global program focused on bringing more developers into free and open source software development. Seven projects were finished successfully. Contributors and mentors enjoyed the time, and here we present some of the achievements, which should make their way into LibreOffice 26.2 in early February 2026!
You can experiment with the new features by using daily builds and report any problems in our bug tracker.
Mentors: Thorsten Behrens (Collabora), Ilmari Lauhakangas (TDF)
Requests to add support for the simple text formatting language known as Markdown to LibreOffice have been more and more frequent. These days Markdown is often encountered in forum posts, chat messages and readme files. In fact, the content of the website of The Document Foundation is written in Markdown.
Thanks to this project, LibreOffice now supports importing Markdown files and pasting Markdown content into Writer as well as pasting Markdown tables into Calc. The supported dialect is CommonMark with GitHub-style table syntax and the library used is MD4C.
Additionally, Collabora developers added support for exporting to Markdown from Writer.
Learn more about Markdown import in the final report.
Mentors: Heiko Tietze (TDF), Rafael Lima
LibreOffice does not yet support proper styles for tables, but has a system for applying direct formatting to them. Before Karthik’s work, it was only possible to add new formatting templates, while now existing ones can be edited as well. At the time of writing this, the feature has not yet been merged into the code base, but hopefully it will appear in the next weeks.
Learn more about the table styles project in the final report.
Mentors: Xisco Faulí, Hossein Nourikhah (TDF)
Power users are sure to love the improvements brought to Python support by this project. Now Python IDEs are able to provide auto-completion for LibreOffice UNO API methods and properties, flag type errors and display information about parameters and types.
Learn more about the Python auto-completion project in the final report.
Mentors: Jonathan Clark, Hossein Nourikhah (TDF), Rafael Lima
BASIC macro developers are not forgotten: this project implemented an object browser, allowing the macro author to see all the available and used methods and properties, including the whole UNO API. A helpful view for details is shown, reducing the need to dig through the API documentation. After this foundational achievement, the next goal is to add context-aware auto-completion to the BASIC IDE editor.
Learn more about the BASIC auto-completion project in the final report.
Mentor: Stephan Bergmann (Collabora)
Rust is a popular type safe programming language, which can now be used to write LibreOffice extensions or do any kind of scripting and processing via the UNO API.
por Gustavo Pacheco
Un informe sobre las actividades de la sexta edición del Congreso Latinoamericano de LibreOffice [1], celebrado en La Habana, Cuba, del 6 al 9 de octubre de 2025.
Con un modelo de organización completamente diferente al de …
Since C++11 when enum class (also named scoped enum) is introduced, it is preferred to plain enum which is inherited from C programming languages. The task here is to convert the old enum instances to enum class.
enum class has many benefits when compared to plain enum, as it provides better type safety among other things. Implicit conversion to integers, lack of ability to define the underlying data type and compatibility issues were some of the problems with plain enum that enum class solved in C++11. Although since then enum has improved and one can specify underlying type in the scoped enumerations.
Plain enums pollute namespace, and you have to pick names that are too long, and have to carry the context inside their names. For example: INETMSG_RFC822_BEGIN inside enum _ImplINetRFC822MessageHeaderState. With an enum class, it is simply written as HeaderState::BEGIN. When placed inside a file/class/namespace that makes it relevant, it is much easier to use: it is more readable, and causes no issues for other identifiers with possible similar names.,
See this change:
You can read more about that in:
You may find some of the instances with:
$ git grep -w enum *.cxx *.hxx|grep -v "enum class"
When you count it with wc -l, it shows something more than 2k instances.
You can see some of the previous conversions here, which is around 1k changes:
$ git log --oneline -i -E --grep="convert enum|scoped enum"
This is a good, but lengthy example of such a conversion:
First of all, please choose good names for the new enum class and values. For example, you may convert APPLICATION_WINDOW_TITLE into Application::WindowTitle. Therefore, do not use the old names as they were.
Converting enum to enum class is not always straightforward. You should try to understand the code using the enum, and then try to replace it with enum class. You may need to add extra state/values for situations where 0 or -1 or some default value was used. There are cases where a numerical value is used for different conflicting purposes, and then you have to do some sort of conflict resolution to separate those cases.
You may end up modifying more and more files, and a few static_casts where they are absolutely necessary because you are interpreting some integer value read from input. These are the places where you should check the values yourself in the code. You have to make sure that the numerical value is appropriate before casting it to the enum class.
If you want to do bitwise operations, you should use o3tl::typed_flags, for example:
enum class FileViewFlags
{
None = 0x00,
MultiSelection = 0x02,
ShowType = 0x04,
ShowNone = 0x20,
};
template<> struct o3tl::typed_flags : o3tl::is_typed_flags<FileViewFlags, 0x26> {}
Then, you may use it like this:
if (nFlags & FileViewFlags::MULTISELECTION)
mxTreeView->set_selection_mode(SelectionMode::Multiple …
| 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. | |