The New Writer Guide 26.2 Just Arrived

Continuing our mission to provide the best LibreOffice documentation for our end users, the Documentation Team is proud to announce the release of the latest Writer Guide for LibreOffice 26.2.

Whether you’re a beginner or an expert, this guide covers all aspects of the LibreOffice Writer module—from creating simple one-page document to full book using the best practice in text editing, text formatting and document compilation.

This guide is the result of teamwork by LibreOffice Community volunteers. We extend special thanks to Dione Maddern, Claire Wood, Miklos Vajna, Ed Olson, B. Antonio Fernandez, Peter Schofield and Olivier Hallot.

“This is our first edition of the Writer Guide using Nextcloud Deck to manage the production process. It has been a bit of a learning curve for our team, but it has greatly improved task tracking and communication.” Said Dione Maddern, volunteer Writer Guide coordinator.

 

Dione Maddern

The guide was updated from LibreOffice 25.8 and 26.2 and included several new sections on new features as well as contents on features not yet documented in the previous editions. The Guide is up to date with LibreOffice 26.2 release and included the following updates:

  • Chapter 2 – Working with Text: Basics: Updated to show improvements to the Hyphenation options in the Paragraph Style dialog.
  • Chapter 3 – Working with Text: Advanced: Documents improvements to Writer’s tracking of interdependent changes and documents the new Reject but track new.
  • Chapter 5 – Page Style Basics: Updated instructions for toggling the visibility of Boundaries and Formatting Aids and Page break examples moved from Chapter 8, Introduction to Styles.
  • Chapter 6 – Formatting pages: Advanced: Content on Using Document Themes moved to Chapter 9, Working with Styles.
  • Chapter 7 – Printing and Publishing: Updated information on standards for Reference XObjects.
  • Chapter 8 – Introduction to Styles: Fixed out-of-order sections and figures, and reordered some sections to improve flow and clarity. Improved sections on the Styles sidebar deck and Creating paragraph styles. Page styles examples moved to Chapter 5, Page Styles Basics. Removed obsolete passage about anchoring settings being unavailable for Frame styles.
  • Chapter 9 – Working with Styles: Added sections to document the Asian Typography, Asian Layout, and Text Grid features. Added a section to document the Inline Heading preset frame style. Removed obsolete section about character formatting.
  • Chapter 10 – Working with Templates: Improved introduction. Improved sections on Updating a document by loading styles from a template, Other ways to manage templates, Creating a document from a template, and Creating a template from a document.
  • Chapter 11 – Images and Graphics: Improved grammar and style in multiple sections. Added a section to document the Text within a shape feature.
  • Chapter 13 – Tables: Added contents on table calculations
  • Chapter 15 – Table of contents, Indexes and Bibliography: Updated nomenclature, Updated instructions for adding entries using the Bibliography Database window. Added a section on DOI References.
  • Chapter 16 – Master documents: Chapter was entirely rewritten to improve clarity, completeness, and flow.
  • Chapter 17 – Fields: Improved and clarified instructions on how to set and use variables fields.
  • Chapter 18 – Forms: Added instructions for exporting to PDF forms.
  • Chapter 19 – Spreadsheets, Charts, Other objects: Added instructions on how to create a chart from a writer table. Updated charts with data table addition.
  • Chapter 20 Customizing Writer: Added sections on the Allow text to be dragged and dropped and DeepL Server options. Improved the section on the Load printer settings with the document option.
  • Chapter 21 – User Interface Variants: Added a section documenting the Form tab in the Additional tabs section.
  • Appendix A – Keyboard Shortcuts: This new Appendix was added with most important shortcut for text editing and word processing operation, organized by actions.

The Writer Guide is available in PDF, ODT format and can be read on line as web pages. To access the Guide, readers can use the following

Our sense of meritocracy

Meritocracy is one of the founding principles of the free and open-source software movement. It is also one of the most controversial terms, and the gap between the different meanings people attribute to it is, in some projects, a source of real and damaging conflict.

Let us analyse the meaning of the word, because its potential ambiguity can significantly influence the debate and the various viewpoints.

The theory of legitimacy based on the commit graph

One version of meritocracy argues that governance authority should follow contribution, and that contribution is best measured through code. According to this view, the people who have contributed most to the code have the right to decide the project’s future, because they know the source code and have a personal stake in the most literal sense of the term.

This is not an unreasonable position for a project in its early stages. Although it is also necessary to consider infrastructure, raise funds, and manage relations with the media and institutions, when the main challenge is technical in nature, when the community is small, and when the stakes are low, it makes sense that those doing most of the work should also make most of the decisions.

The problem arises when the principle is carried forward unchanged into a very different context. A FOSS project that has been running for fifteen or twenty years, is used by millions of people, operates in a complex regulatory and legal environment, has enterprise users and political implications, is no longer the same thing. Applying the same governance from the early days to the reality of a large project does not produce good results, but rather a technically sophisticated and strategically blind organisation.

What the commit chart does not measure

The theory of meritocracy based on the number of commits has a blind spot: it measures only one type of contribution and renders others almost invisible.

Let’s consider what is not in the chart:

  • The authors of the documentation who made the software accessible to users who would otherwise have given up on using it.
  • The localisation team that involved entire linguistic communities in the project.
  • The reviewers who transformed rough bug reports into reports ready for resolution.The community moderators who kept the project welcoming to newcomers at the cost of considerable personal effort.
  • The people who spent years building relationships with media, institutions and the political sphere, creating the conditions for the software’s widespread adoption.

These contributions do not produce commits, but they do produce users, adoption, sustainability and relevance. In a mature project, they often make the difference between software that exists and software that matters.

A governance model that excludes these contributors from the decision-making process, or seeks to marginalise them, is a partial meritocracy in that it recognises only one type of excellence whilst ignoring all others.

The problem of conflicts of interest

There is a second dimension to this argument that merits analysis.

When a project’s governance also includes people employed by companies with direct commercial interests in the project’s direction, the issue of meritocracy becomes more complex. The question is not whether those contributors are capable—for they certainly are—but whether the governance structures built around their contributions can reliably produce decisions that serve the project’s mission rather than the interests of their employers.

This is not an accusation, but a simple observation. Conflicts of interest are not linked to bad faith, but are inherent in the situation. A governance model that fails to take this into account is no longer meritocratic, and is also less aware of its own limitations.

Healthy governance in a mature FOSS project requires a diversity of perspectives: people who contribute code, but also people who represent the user community, the institutional mission, and the long-term sustainability of the project as a public good rather than a commercial asset. It is not a question of excluding developers, but of ensuring that no single interest – however legitimate – is the sole factor determining decisions.

Building for those who come after us

All major FOSS projects are intergenerational, because the people who created them are not the ones who will sustain them in ten or twenty years’ time; therefore, the decisions made today regarding architecture, governance, and which contributions are valued and which are not will shape what the next generation inherits. And it must be something upon which to build, not something to be circumvented.

This completely redefines the issue of meritocracy. From this perspective, in fact, the measure of a contribution is not determined solely by its current value, but also by its value for the future of the project.

Meritocracy in a large open-source project does not lay in the accumulation of commits as a claim to authority, but in creating the best conditions for the project to continue growing in the future. The question is not who has done the most, but who is building something that the next generation can actually use and develop further.

Our sense of meritocracy

The original principle underpinning FOSS meritocracy remains valid: decisions must be made by those who do the work, who understand the consequences, and who have earned their place through genuine contribution rather than organisational politics. This principle must be preserved.

Contributions, however, can take many forms, and merit has a temporal dimension that the commit graph fails to capture. The merit of building the source code is real and deserves recognition, but this also applies to the merit of building a community, maintaining documentation, ensuring accessibility, navigating legal complexities, and securing the institutional relationships that keep the project alive for the people who will inherit it.

A true meritocracy finds a way to recognise and value all of this. A project that confuses meritocracy with the dominance of a single type of contributor, however expert, fails to live up to its own values. And a project that bends to the interests of a subset of contributors, at the expense of future generations, is not a meritocracy but a form of appropriation masked by the language of fairness.

Meritocracy is a complex, multifaceted concept that is worth grappling with in order to build something that future generations will be happy to inherit.

Let’s put an end to the speculation

Ideally, we would have preferred to avoid this post. However, the articles and comments published in response to Collabora’s and Michael Meeks’ biased posts compel us to provide this background information on the events that led to the current situation.

Unfortunately, we have to start from the very beginning, but we’ll try to keep it brief. The launch of the LibreOffice project and The Document Foundation was handled with great enthusiasm by the founding group. They were driven by a noble goal, but also by a bit of healthy recklessness. After all, it was impossible to imagine what would happen after September 28, 2010, the date of the announcement.

At the time, nobody could imagine that the companies that had supported OpenOffice.org until then like IBM would create Apache OpenOffice to kill LibreOffice. Also, if the project were to be successful, it would require resources greater than those available, and above all, a deep management experience.

Fortunately, the project grew quite rapidly. However, the founders’ different backgrounds and opinions were at the same time the reason for some bold decisions – many of which right – as well as a few mistakes, which are the root cause of some of the current problems:

  • granting free use of the LibreOffice brand only to companies in the ecosystem, to allow them to sell the software in Microsoft and Apple’s online stores;
  • awarding contracts for the development of LibreOffice – new features, fixing “legacy” bugs, etc. – to companies whose representatives were on The Document Foundation’s Board of Directors, and who were active throughout the procurement process.

Both of these decisions were found to be incorrect for reasons relating to the non-profit law, to which The Document Foundation must adhere. They violated the law itself. When this fact was brought to the attention of the Board of Directors by the foundation’s legal counsels, the companies that had benefited from these errors sought to maintain the status quo rather than finding a solution. At the time – from the end of 2021 to the middle of 2022 – this could have been achieved swiftly and with minimal difficulty.

This attitude increased tensions within the BoD, adding to pre-existing frictions that began in 2020 when the majority of the new board decided to terminate the plan to transfer many of TDF’s tasks and assets to a parallel organisation called The Document Collective (TDC). Several issues that the current board had to solve stemmed from elements of that project that had been partially executed.

The origins of TDC are controversial. One reason given for setting up the parallel organisation was the “alleged inefficiency” of the TDF team [1], which was expressed by some of the directors. Unfortunately, instead of addressing the supposed problem with a reorganization or some training, the BoD decided to react by creating a new problem: a parallel structure with a supposedly “highly efficient” team that would highlight the alleged inefficiency of the TDF team.

TDC was presented at the LibreOffice Conference in Almería in 2019 without prior notice, raising concerns within the team and the community. This was partly because the parallel organisation’s project envisaged leveraging TDF’s financial resources as startup funds. This attempt resulted in permanent damage to relations between the project’s components, and especially between certain BoD members and the team.

After years of discussions marked by accusations and finger-pointing, during which no real progress was made in resolving the legal issues, the German authorities overlooking non profit foundations requested an audit whose results confirmed that resolving the issues was absolutely necessary to avoid losing non-profit status, with unforeseen consequences.

Unfortunately, the presence of company representatives on the Board of Directors (BoD), who were elected by employees of those same companies that are also TDF members, caused further delays to finding a solution, which has not yet been reached.

Fortunately, the introduction of restrictive measures – such as the decision to forfeit TDF membership status of Collabora employees – and the freezing of tenders, alongside the introduction of a robust procurement policy for development, has resulted in a positive outcome for the third audit [2]. At least, the BoD has demonstrated a willingness to break the deadlock that has persisted since 2022.

The board also reviewed governance issues from the past and set clear rules to minimise the risk of them recurring in future. These rules are set out in the Code of Ethics and Fiduciary Duties, the updated Conflict of Interest Policy and the Community Bylaws.

Of course, if we could rewind the course of history, some of the choices made since 2010 would hopefully be different and no one would repeat the mistakes or the wrong behaviours of the past.

As we said at the beginning, we would gladly have done without this post, but it was necessary to set the record straight and avoid speculation.

TDF has been preparing for some time for Collabora’s announcement, by hiring developers and exploring new partnership opportunities to support a growing interest in LibreOffice on the desktop, still a viable option for many deployments, the cloud and mobile, and in ODF as the preferred document format for governments worldwide.

Thanks to the growing importance of free and open source software, as well as open standards for document formats, the concepts that we have been advocating for over twenty years and have finally reached political institutions and users, The Document Foundation and the LibreOffice project are well positioned for the future.

[1] The Document Foundation’s daily activities are managed by a team of employees and contractors who handle administrative tasks, infrastructure, release management and developer’s mentoring, and coordinate community, quality assurance, UX, documentation, localization and marketing.

[2] The first audit in 2023 raised concerns about the mentioned issues. The second audit in 2024 confirmed the concerns. The third audit in 2025 did not raise concerns.

Document formats: a mystery to many

Euro-Office’s announcement – which sees IONOS, Nextcloud and other companies coming together to create a European alternative to office productivity software – has predictably sparked a wave of comments. Most of these focus on the issue of licensing: is the code open source? Who controls the repository? What are the conditions for forking, modifying or implementing it?

While these are all valid questions, they fail to address the most important issue. The fact that almost no one is asking the question that matters tells us something significant about how the debate on digital sovereignty has been framed and who benefits from that framing.

A licence tells you who owns the software, while the format tells you who owns the data

A licence can be renegotiated, modified or updated. The history of FLOSS is full of projects that have changed governance models, divided communities, or changed course under new management. Licence terms are important, but they operate at the level of the software artefact.

The native document format operates at a completely different level. It is the encoding level of every document produced, archived, and exchanged by institutions that adopt the software. It is the invisible structure of administrative memory within which public documents exist for years, or even generations. It is the infrastructure.

If Euro-Office is supplied with OOXML as the default native format – even if it is wrapped in an open licence, hosted on European servers or governed by a European legal entity – every document drafted by public administrations, schools and institutions will be written in a format designed around the behaviour of a single vendor’s application.

OOXML is governed by a specification that is so complex and internally inconsistent that it compromises interoperability. As if that were not enough, it is optimised for backward compatibility with Microsoft Office rather than for seamless exchange between systems.

The licensing issue asks: who controls the code? The format issue asks: who controls the data? These are not equivalent situations. The latter has long-term implications for public archives, administrative continuity, and the practical significance of vendor independence.

For thirty years, the FLOSS and digital rights communities have been working on licences based on the fundamental principle that a licence equals freedom. This work has produced enormous value, but it has also created an unintentional blind spot.

Microsoft has spent decades conducting one of the most effective user education campaigns in the history of the software industry. However, what it has taught is dependency. Consequently, a generation of users, administrators, developers and even FLOSS advocates has grown up treating OOXML documents as the natural unit of document exchange — just like water flowing from a tap. OOXML files are not perceived as a lock-in mechanism, but as normal documents.

This is an incredible strategic achievement. Microsoft has managed to transform a proprietary file format, which was designed to replicate the behaviour of its own applications rather than enable transparent content exchange, into an interoperability standard.

Compatibility with the OOXML format is not viewed as a courtesy to the monopoly holder; rather, it has become a feature that alternative software must provide to prove its legitimacy. Lock-in has been transformed into an advantage: users are not trapped in Microsoft’s format; they are simply using the format that everyone else uses.

The FOSS community, which should be particularly vigilant about such dynamics, has often uncritically accepted Microsoft’s approach. Indeed, when evaluating an alternative productivity suite, the first question is often about the ability to open OOXML files rather than about the native format and whether it enables interoperability. Unfortunately, the alternative is judged according to criteria subtly dictated by Microsoft.

Consequently, format policy is treated as a secondary technical issue rather than the major political issue it really is. Meanwhile, Microsoft has pursued a precise and successful strategy of securing OOXML certification as an ISO standard to define it as ‘open’, while ensuring that licensing issues take precedence over format issues.

The result is that “supporting ODF” has become a box to tick rather than a specific commitment. This explains why all office suites today claim to support ODF. The practical implications of this support – such as whether ODF is the native or default format, or the format in which documents are created and stored without user intervention – are rarely considered, let alone addressed.

The test that matters

Euro-Office presents itself as a genuine European alternative: an infrastructure project for digital sovereignty. This claim deserves to be put to the test in terms of whether institutions will manage to free themselves from Microsoft lock-in, or if they will simply reproduce it under a different banner.

The test is simple and admits only one answer: ODF will be the native format of Euro-Office; the format in which documents are created, stored, and exchanged by default without user configuration or technical intervention.

Not: Euro-Office supports ODF because, in a nominal sense, everything supports ODF. Users can save in ODF format because this is a compatibility feature, not a commitment to true digital sovereignty.

If the answer is yes, then Euro-Office represents a significant structural break with the dominant proprietary format. However, if the answer implies “compatibility”, “user choice”, “transition paths” or “broad format support”, then Euro-Office is, regardless of the licence, a server migration that leaves Microsoft’s lock-in on data unchanged.

Digital sovereignty is not achieved by changing who hosts the software, but by changing the format in which data is encoded. European institutions, public administrations, and civil society organisations considering Euro-Office deserve a direct and immediate answer to this question before making any further commitments.

ODF has to be native, default, and by design.

Since its foundation, the Document Foundation has supported ODF as an open standard for document exchange. ODF (ISO/IEC 26300) is the only document format standard designed from the outset to ensure interoperability, long-term preservation, and total vendor independence.

Comment about Collabora blog post

Many people have asked The Document Foundation for its official position on what Collabora announced in a blog post.

This is not the first announcement of this kind in FLOSS environments, nor will it be the last. Collabora feels that it has to invest in a specific product that differs from traditional, full-featured office suites such as LibreOffice. They are, of course, free to take this approach based on the MPL licence.

However, Collabora has framed this as a direct consequence of the Membership Committee’s decision to remove Collabora employees from TDF membership based on the recently approved Community Bylaws.

The Community Bylaws require that employees of companies involved in legal disputes with The Document Foundation be removed from TDF membership because, in the past, people made decisions in the interest of their employers rather than in the interest of The Document Foundation.

We would prefer to avoid further discussion about who is responsible for what, as this would lead to endless debates that would not benefit the project as a whole (i.e. The Document Foundation, its ecosystem companies, and its volunteer contributors).

Unfortunately, a series of wrong decisions in the past have turned into an ongoing problem which has grown to the point of posing a significant risk to the project. The Document Foundation could have lost its charitable status, which would have had unforeseen consequences.

This risk remains, but thanks to hard rules such as those included in the Community Bylaws, whose enforcement is unpleasant for everyone, it is being significantly reduced and hopefully avoided.

The project welcomes contributions from true believers in open source. As the majority of people at Collabora are such believers, we expect them to continue contributing when the time comes.

Also, removal from membership does not mean removal from community. Anyone is welcome to contribute and participate.

On the other hand, The Document Foundation is hiring developers and donations are growing, which will allow for further developer and team member recruitment.

In the current environment, the project’s focus should be on leveraging the opportunity presented by growing interest in true FLOSS solutions that support digital sovereignty — or, if you prefer, the freedom to own and control your infrastructure, applications, and documents.

Euro-Office: sovereign in name only, or in reality too?

The announcement of the Euro-Office is welcome news. The coalition is credible, the governance is sound and the timing is perfect. Europe needs office software, and The Document Foundation is delighted to see such significant players allocating resources to make it happen.

However, we have a question. It is not meant to be hostile, but it is the only question that matters.

What is the native document format of Euro-Office?

The press release promises full compatibility with Microsoft formats. We are well aware of the logic behind migration: organisations moving away from Microsoft need to be certain that their documents will survive the transition. But “full compatibility with Microsoft formats” is certainly not a definition of sovereignty, but rather the definition of a different kind of dependency.

OOXML is a format designed, controlled and managed solely by Microsoft. Building a European office suite prioritising compatibility with OOXML means ensuring that the European document infrastructure remains subordinate to architectural decisions made in Redmond. The hosting moves to Europe, but the lock-in remains in Redmond.

The alternative exists, is mature and is a law in several European jurisdictions. ODF, the Open Document Format, is an ISO standard developed through an open and transparent process, which is not controlled or managed by a company. The German Deutschland-Stack has made it mandatory, and the EU Commission has approved it. It is not the LibreOffice format, but a European public good.

The Euro-Office press release does not mention ODF even once.

We are not asking Euro-Office to abandon support for Microsoft’s proprietary format. LibreOffice itself reads and writes OOXML: compatibility is a necessity for users, not an ideological concession. We are asking whether ODF will be the native format, the one in which documents are created, archived and exchanged between European public administrations.

This distinction is fundamental, and the time to define the native document format is now, before the architecture is finalised and the implementations take place. If necessary, we are here to help with the deployment of the ODF standard as native document format.

The coalition has the credibility and resources to build something truly innovative. We hope it will use them to build a project of sovereignty and not merely a tool for server migration, flying a European flag but with a lock-in firmly rooted in Redmond.

The Document Foundation is a non-profit foundation and the home of LibreOffice, the world’s leading open-source office suite. LibreOffice implements ODF as its native format and supports a wide range of document formats, including the import and export of OOXML.