Last updated:
July 08, 2026 05:00 PM
All times are UTC.
Powered by:
Imprint
Privacy Policy
by Popa Adrian Marius (noreply@blogger.com) at July 08, 2026 02:35 PM
This is part of the Annual Report 2025 from The Document Foundation, the non-profit that coordinates the LibreOffice project and community.
Across the reporting period, the public conversation about office software and document formats shifted decisively. The justification for moving away from proprietary suites is no longer framed primarily as cost saving. It is framed as the preservation of independence — the ability of a government to act without asking permission from a foreign supplier. Several of the year’s migrations were announced with that argument stated explicitly and the cost argument set aside; the Austrian Armed Forces went so far as to say the move was not about money at all.
This reframing matters for The Document Foundation, because it moves the debate onto ground where the Foundation has argued for two decades. Digital sovereignty is the ability of nations, organisations and individuals to control their own digital destiny: to control access to their own information without depending on third parties, to make technological choices based on their own needs rather than a vendor’s commercial strategy, and to preserve that self-determination as the market consolidates. When public bodies store their documents in proprietary formats controlled by a single company, they surrender part of that sovereignty.
The year also clarified a distinction the foundation has long insisted on: sovereignty is not delivered by any single layer of the technology stack. It requires an open standard format at the base, an open source application above it, open source infrastructure for data location, and a legislative framework that defines the requirements. A law favouring open source, an open cloud, and an open suite together still leave sovereignty incomplete if the document format itself remains under one vendor’s control. The format is the foundation of the stack, and it is the layer most often overlooked.
The year’s central policy development was Germany’s formal commitment to ODF, a decision whose full weight became apparent only as it moved from principle toward binding implementation.
In April 2025, Germany’s IT Planning Council — a seventeen-member body representing the federal government and the state governments — committed to moving public administration to the Open Document Format, with the stated aim of making ODF the standard for document exchange by 2027. The Council framed open formats and open interfaces as a necessary building block of public-sector transformation toward digital sovereignty, and commissioned its Standardization Board to implement the decision. The commitment set a clear trajectory: a federal-level decision, binding on the implementing board, with a 2027 target for ODF as the standard for document exchange. Its translation into concrete, enforceable infrastructure standards was expected to follow — and the early signs as the year closed pointed toward exactly that outcome.
On 3 December 2025, OASIS Open approved ODF v1.4 as an OASIS Standard — the organisation’s highest level of ratification — coinciding with the twentieth anniversary of ODF’s original adoption as an OASIS Standard. The new version maintains full backward compatibility while improving accessibility support (assistive technologies, decorative-object marking), professional formatting and visual design, and features for data analysis and technical documentation. It remains an XML-based, vendor-neutral, royalty-free format. Earlier ODF versions are published as ISO/IEC 26300; the four-part v1.4 specification is available in the OASIS library.
The year carried the twentieth-anniversary thread throughout: ODF’s adoption as an OASIS Standard in 2005, and its ISO/IEC standardisation on 3 May 2006. The ODF v1.4 ratification in December 2025 was deliberately timed to the OASIS anniversary. The anniversary is not merely commemorative: it underpins the argument that ODF is the only open standard for office documents with a twenty-year record governments can rely on for long-term archival access.
The Foundation ran a sustained ODF communications campaign through the year, built around a regular series of articles on the TDF blog. Rather than isolated announcements, the series formed a coherent body of work that moved from the fundamentals — what ODF is and why it matters — through technical and practical material on file types, compliance and interoperability, the differences between ODF and proprietary formats, migration guidance, and the new features of recent ODF versions, and on to the wider argument connecting open document standards to digital sovereignty. Taken together, the series gave the Foundation a standing reference resource and a consistent public voice on the format throughout the year.
Document Freedom Day was marked as a purely advocacy-driven occasion: blog posts, social media activity across the Foundation’s channels, and small local events organised by community members around the world. The emphasis was on awareness and outreach rather than on any single flagship event.
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.
The following migrations were publicly reported and verifiably advanced during 2025. Status reflects what the cited primary or most reliable source actually supports. Long-standing legacy deployments are deliberately excluded; this list is reserved for movement during the year, and only entries with solid sourcing are included. Figures and completion claims should be confirmed against TDF records before publication.
By early December 2025, the northern German state reported that close to 80% of administrative workstations outside the tax administration were running LibreOffice as the binding standard, with Microsoft Office and Outlook either already uninstalled or in the process of removal, and a new-licensing rate already well below 10%. The state reported licence-cost savings already exceeding €15 million, against a one-time 2026 migration investment of €9 million. The remaining ~20% of workstations depend on specialist applications with technical ties to Microsoft formats; migration paths for these, and for the tax administration, have been defined. In parallel, the state completed the migration of more than 40,000 mailboxes (over 100 million messages and calendar items) off Exchange/Outlook to Open-Xchange and Mozilla Thunderbird, with the cutover finishing 2 October 2025.
The Austrian military migrated approximately 16,000 workstations across all branches from Microsoft Office to LibreOffice, with the project finalised in 2025 and Microsoft Office 2016 removed from all machines (Office 2024 LTSC retained only under special permission for legacy macro/Access cases). The Directorate 6 (ICT & Cyber) stated the primary driver was digital sovereignty and in-house data processing, explicitly not licence savings. The Bundesheer contributed more than five person-years of upstream development back to the LibreOffice project; the migration was presented at the LibreOffice Conference 2025 in Budapest.
The Danish Ministry of Digital Affairs committed to replacing Microsoft 365/Office with LibreOffice, beginning July 2025 with a phased rollout (roughly half of staff in the summer, the remainder by autumn). For accuracy: earlier reporting that Denmark would abandon Windows for Linux entirely was subsequently corrected — Windows remains in use on many devices; the confirmed change is the office-suite migration. Several municipalities, including Copenhagen and Aarhus, were reported to be pursuing similar moves.
The year’s gains were real, but they sit alongside structural threats. The central risk is that the open-source application migrations succeed while the open format battle is quietly lost — that lock-in survives the move by relocating from the application to the document.
An office suite that does not use ODF as its native format handles ODF files imperfectly, which re-creates interoperability problems and pushes users back toward the proprietary format “for convenience.” A government can therefore adopt an open suite and an open cloud and still fail to achieve sovereignty if its documents remain in a format controlled by a single vendor. The format is the base of the stack; without it, every layer above is compromised.
When a public administration is told its documents are stored in “an ISO standard format,” the reasonable assumption is genuine openness. OOXML Transitional does not deliver it: its stacked dependencies — format, rendering and fonts — re-encode failure at each layer. A format named as a standard while defined by its own specification as provisional is the principal rhetorical obstacle to ODF adoption, and the principal target of the Foundation’s three-strand evidence work.
A specific and growing risk is the European sovereignty initiative that adopts open source applications and open infrastructure while defaulting to OOXML rather than ODF as its native document format. Such an arrangement re-encodes the dependency at the format layer even as it presents independence at every other layer. This is the precise failure mode Section 4.5 describes, and it gives the Foundation’s insistence on a native open format its practical
urgency.
Sovereignty gains are reversible without durable policy commitment. Munich’s LiMux reversal remains the cautionary precedent, and the year offered a live counter-signal: even as Schleswig-Holstein advanced, Bavaria was reported to be pursuing a major Microsoft 365 contract. This is why a binding federal commitment to ODF, of the kind Germany set in motion in 2025, matters: it raises the cost of reversal. But commitments depend on sustained political will to carry them into enforceable practice.
Earlier in this series I described the invisible architecture of lock-in as three stacked layers. A document depends on its format, which depends on a rendering engine to become visible, which depends on the fonts that give it its final shape. Each layer is a dependency the user rarely sees and almost never chooses deliberately, and together they explain why “just open it in something else” so often fails. The argument has always been structural rather than moral: it does not matter whether the vendor is benevolent or predatory, because the dependency exists either way.
Two pieces of news from late June give me occasion to extend that architecture. They are not, at first glance, about formats at all. But read structurally, they reveal two further layers of dependency that sit on top of the technical ones. Layers I left implicit until now because the technical case was enough to make the point. It is worth making them explicit, because they complete the account of what dependency actually means.
The first piece of news: Microsoft has extended free security updates for Windows 10 by a further year, to October 2027. The original end date for consumer support was October 2026. Hundreds of millions of users, and the institutions that manage them, had organised their procurement, their budgets, and their migration planning around that date. Then the date moved, quietly, through an editor’s note appended to a blog post, with no formal announcement.
The second: Italy’s competition authority, the AGCM, has opened an investigation into whether Microsoft adequately informed consumers when it integrated its Copilot and Designer AI tools into Microsoft 365 and moved subscribers onto more expensive plans. The allegation, still under investigation, concerns transparency and consent: whether users were given a genuine choice, or were migrated to a costlier tier unless they actively opted out.
I want to be careful here, because the temptation is to treat these as two instances of the same thing, and they are not. They are two sides of one coin. A coin has two faces and a single substance. The substance, in both cases, is that the user is not in control of his desktop stack. The faces are different, and naming them precisely is what gives the argument its force.
The temporal layer
The Windows 10 extension is not, on its surface, bad news. A further year of free security updates is, taken in isolation, a gift to users who cannot or will not upgrade. If you read the story as a tale of corporate character – Microsoft breaking its word, Microsoft flip-flopping – you reach for the weakest version of the argument, and you hand a critic the easy reply that extending support is pro-consumer.
The structural reading is harder to answer. The point is not that the date was wrong, or that moving it was wrong. The point is that the date was never yours. The lifecycle of your own desktop – when it is supported, when it is abandoned, when you must spend money on new hardware – is governed by a vendor’s strategic calendar, not by your operational needs. You reorganised a year of planning around October 2026 because Microsoft told you to, and you will reorganise again around October 2027 for the same reason. A benevolent vendor moving the date without consulting you proves the point exactly as well as a cynical one would. You do not own the clock.
This is the fourth layer. Above format, rendering, and fonts sits time. Your dependency is not only in the file, it is in the calendar.
There is a detail in this story that sharpens the point rather than softening it. The free extension is not unconditional: to enrol without paying, a user must sign in with a Microsoft account and sync settings to the company’s cloud. So the price of keeping your old operating system alive is to move more of yourself into the vendor’s stack. The remedy deepens the dependency it claims to relieve. This is the difference, which I have written about before, between a solution and a substitution. A solution would reduce your dependence. A substitution merely relocates it from the operating system to the account.
The commercial layer
The Italian investigation looks, at first, like a different kind of story altogether: a matter of consumer-protection law, of disclosure and dark patterns, with no obvious connection to open standards. And it would be a mistake to press it into service as evidence of format lock-in, because that is not what it is about. The discipline of letting structure carry the argument requires resisting exactly that kind of stretch.
But it illustrates a different layer cleanly, and the layer is real. When your productivity suite is a proprietary bundle, the vendor can change what you are paying for, and how much, without your meaningful consent. New tools you did not ask for are folded into the package, the price rises to match, and the path to opting out is, allegedly, buried. Whether the AGCM ultimately finds against Microsoft is not the point I am making, as the investigation may take until 2027 to conclude. The point is that the arrangement permits this. The economic terms of your daily work are set by a party that is not you, and can be revised by that party at a moment of its choosing.
This is the fifth layer. Above format, rendering, fonts, and time sits price. Your dependency is in the invoice as much as in the file.
What the layers have in common
Five layers, then: format, rendering, fonts, time, price. The first three are technical and largely invisible. The last two are not technical at all, and they are the ones the user feels most directly, in a migration deadline he did not set, in a subscription cost he did not agree to. Listing them together changes the character of the argument. Lock-in is no longer a catalogue of technical grievances of interest mainly to specialists. It is a complete account of dependency, and it reaches every part of how a person works: what his documents are made of, when his tools will stop being supported, and what he will be charged for them.
What unites all five is a single absence: the user has no exit. He cannot take his documents elsewhere without loss because of the technical layers, he cannot escape the vendor’s calendar or its pricing because of the other two. Every one of these dependencies is only possible because there is no door.
That is why I have spent this series on formats, and on rendering, and on fonts, and now on calendars and invoices. They are not separate complaints. They are the same observation seen from different angles, and the observation is this: an open format and a free application are not, in the first instance, about cost or ideology. They are an exit, they are the door that makes every one of these dependencies optional rather than fixed. The Open Document Format and LibreOffice do not promise that you will never depend on anyone. They promise something narrower and more important: the dependency is one you have chosen, and one you can leave.
A vendor’s calendar will always move. A vendor’s prices will always rise. These are not scandals, they are simply what it means to be governed by someone else’s strategy. The only question that matters is whether you are free to walk away when they do. Everything in this series has been an argument that you should arrange your affairs so that you can.
Images by Manfred Steger from Pixabay
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.
There is a sophisticated mechanism by which proprietary technology ecosystems maintain their grip on users and institutions, even when those users and institutions believe they are making free choices, using open standards, and building independent digital infrastructure.
The mechanism does not work through force, but through a subtler and more durable strategy: the layering of dependencies, in which each layer obscures the one beneath it, so that when the system fails the apparent cause is something other than the real one.
It is a structural pattern with identifiable components and predictable failure modes, and with a single political consequence: the systematic attribution of interoperability failures to open alternatives rather than to the proprietary dependencies that actually cause them.
Understanding all of this is essential for anyone working on a genuine interoperability policy, because without it even the best-intentioned policy interventions address the visible symptom while leaving untouched the larger problem of the underlying architecture, which goes on working exactly as designed.
The perception of malfunction
Let us start from the user’s experience, because this is where the political damage occurs.
A document is created in Microsoft Word and sent to a colleague who uses LibreOffice on a Linux desktop. The colleague opens the file. Something is wrong: a table has shifted, the text has reflowed, a font looks different, the page breaks have moved.
The experience is familiar to millions of people in institutional settings that have adopted, or are considering adopting, open source software. It is the experience that generates the helpdesk tickets, the emails of pure frustration to the IT department, the conversations that end with “can you just send me a PDF?”, and the broader sentiment, consolidating over time, that open source software is not ready for professional use.
What is the cause of this failure? Users will blame LibreOffice, IT managers will blame format incompatibility, policymakers will blame the immaturity of open standards.
These are all wrong answers. Or rather, they are all answers to the wrong question, because they describe where the failure manifests rather than where it originates.
The actual cause is a set of interdependent technical systems, each contributing a different failure mode, all producing a single visible result.
The format contains proprietary structures that only Microsoft’s implementation handles correctly. The rendering introduces platform-dependent variations that the format specification does not control. The proprietary fonts cannot be legally bundled with open source software.
Three distinct failure modes producing the same symptom, and equally invisible to the user, who perceives only that things worked in Word and do not work in LibreOffice.
This is the architecture of layered dependency. Each layer absorbs the causal chain and emits a different signal, one that points toward the open alternative.
Layer One: the format and its hidden features
The first layer is the most discussed and the most politically visible: the document format. The conflict between ODF and OOXML has been extensively documented, litigated within standards bodies, and debated in national parliaments and in the European institutions.
But even within this well-mapped terrain, it is worth clarifying the specific mechanism of obscuration at the format layer.
OOXML, the format Microsoft Office produces by default, exists in two conformance levels. Strict is a reasonably clean specification. Transitional is something categorically different: a format designed to encode the accumulated behaviour of earlier Microsoft Office versions, preserving decades of proprietary implementation choices as normative elements of an apparently open standard.
OOXML Transitional includes VML — Vector Markup Language, a proprietary drawing format from the late 1990s that predates and contradicts the DrawingML system defined elsewhere in the same specification.
It includes references defined as “as in earlier versions of Microsoft Office”, which make sense only if one has access to those earlier versions and to their undocumented implementation details.
It includes extensions that allow Microsoft to embed proprietary functionality in documents, invisible to non-Microsoft implementations, and capable of causing silent rendering differences ranging from minor visual variation to complete layout failure.
Crucially, OOXML Transitional is what Microsoft Office produces by default.
Every time a user saves a Word document without selecting a different format, they produce a file optimised for the Microsoft ecosystem and subtly hostile to every other.
Users do not know this is happening, because the choice is made for them at the format level, and when the document fails in LibreOffice, the format layer’s contribution to that failure is invisible. The user sees a rendering problem, not a format problem.
This is the first layer of obscuration: proprietary format constructs masked by the label “industry standard”, producing errors that appear to be implementation shortcomings in the receiving software.
Layer Two: rendering and its unspecified behaviour
The second layer is less discussed, less politically visible, and for these very reasons more durable as a source of interoperability failure: text rendering.
Document format standards specify content. They define what a document contains: text, structure, logical relationships, embedded objects, and formatting instructions.
What they do not specify, and what none of the major document format standards has ever specified, is how that content should be rendered. The translation of encoded content into visible glyphs on a screen or a page is left to the implementation, and different implementations make different choices.
These choices operate across several subsystems.
Shaping engines — the software components that translate sequences of Unicode characters into sequences of glyphs, and that handle the complex rules of scripts such as Arabic, Devanagari and Thai — differ by platform.
HarfBuzz, the open source shaping engine used by LibreOffice and by most Linux applications, produces correct, standards-compliant output, but that output may differ in detail from Windows’ Uniscribe or DirectWrite engines, particularly for complex scripts with context-sensitive glyph selection.
The differences are almost always invisible for Latin text, but for the non-Latin scripts used by a significant portion of the European public sector and citizenry, they can be significant.
Hinting interpretation varies across rendering engines. Fonts embed hinting instructions — algorithms that adjust glyph outlines for crisp display at low screen resolutions — but those instructions are interpreted differently by different renderers.
A font optimised for Windows’ GDI rendering engine may display with different weight and spacing under FreeType on Linux, even at identical sizes.
The differences are minute for any single character, but they affect the perceived quality of the text and contribute to the general impression that open source environments are slightly less polished.
Line-breaking and justification algorithms are the most significant source of rendering variation and the most direct cause of document reflow.
The algorithm that determines where to break lines — how to distribute words across a line of a given width, whether and how to hyphenate, how to handle justified text — is an implementation choice that no format specification regulates.
Microsoft Word’s line-breaking algorithm is proprietary and undocumented, and it is very different from LibreOffice’s. Both are legitimate implementations of the same function, and they can produce different line breaks; different line breaks mean different page breaks; and different page breaks mean that a document paginated in Word will not be paginated the same way in LibreOffice.
This is not a defect in implementation quality, but the normal and predictable consequence of differing rendering choices that document format standards do not define. And it produces errors that are invariably attributed to the software receiving the document, because that is where the visible difference appears, rather than to the specifications that are their cause.
The rendering layer is the most technically complex component of the layered dependency and the hardest to address, but it is also the layer that most clearly reveals the dimensions of the problem: an error generated by a different choice made by two projects, attributed solely to the open source software, on the basis of an entirely unjustified, almost faith-based trust in the quality of the proprietary software.
Layer Three: fonts and the dependency on proprietary resources
The third layer completes the picture and, in many practical settings, causes the greatest damage: fonts. Here we will not analyse font-level lock-in as such, but will instead explain how the font layer operates within the layered dependency model.
Fonts interact with both layers above. At the format level, fonts appear as named references: a document declares that the body text is set in Calibri and the headings in Cambria. If those two fonts are not available on the receiving system — and this is the case on every system for which a licence for the proprietary fonts has not been acquired — the software must substitute them.
Substitution changes the metrics, and the metrics in turn change the geometry. Altered geometry produces reflow, broken layouts, forms overflowing their margins; and here too the failure is attributed to the application receiving the document.
At the rendering level, fonts interact with the shaping engine, the hinting system and the antialiasing pipeline in ways specific to each font’s design and embedded instructions. A font optimised for the Windows rendering stack will display differently under FreeType, even before any substitution occurs, and this contributes to the overall visual divergence between environments.
What makes the font layer particularly effective as a lock-in mechanism is the combination of legal unavailability and the user’s lack of information. The proprietary fonts at the heart of the problem — Calibri and Cambria, and before them Arial and Times — are not available under any kind of open source licence.
This is a legal constraint that open source software cannot overcome, but one that users perceive not as a licensing problem but as a software problem — not as the consequence of a strategy but as proof that open source software cannot handle ordinary documents.
Only Aptos, the latest of Microsoft’s proprietary fonts, is released under a partially restrictive licence, since it ties use to a download from Microsoft’s site. It can therefore be installed by Linux users too, and used legally, but this has not been communicated widely enough, so the lock-in mechanism is only reduced, not eliminated.
Why “invisible” is the key word
Each of the three layers would be a manageable problem if it were visible, and if users had the chance to see clearly that the error originates in the proprietary format, or in the insufficient rendering specifications, or in the proprietary font. Visible problems can be addressed and solved on the basis of accurate diagnosis and targeted intervention.
The strength of this scheme lies in its obscurity. Each layer acts as a signal re-encoder: it takes the output of the layer beneath it and re-emits it as something that looks like a different kind of problem.
So the dependency on proprietary fonts produces an error that looks like a software rendering issue; the rendering problem produces an error that looks like an implementation shortcoming; and finally the proprietary format structure produces an error that looks like a failure to comply with standards.
By the time the error reaches the user, its origin is completely obscured, and responsibility is systematically redirected to the last element in the chain: the open source software, which was merely trying to display a document designed to defeat it.
This is not a coincidence arising from poor design.
Software that generated random errors would be a problem for the company that developed it, because user frustration would flow back toward the originating software.
A system that generates errors at the boundary with competitors, in such a way that they are always attributed to those competitors, is a competitive asset.
Here the question of intent matters less than the question of structure: whatever the motivation behind the original design decisions, the resulting architecture functions as a constraint, and its effects are observable and measurable.
How policy responded, and where it failed
The policy response to document lock-in has concentrated on the format: mandating the use of ODF and open formats in public procurement, and guaranteeing that government documents can be created and consulted without the use of proprietary software. Unfortunately, these interventions have almost never been paired with penalties to enforce compliance, and the rules have often been ignored.
Moreover, these format mandates have not addressed the use of proprietary fonts in document templates, so by fixing only the upper layer they leave the lower one exposed and fully operational, where it is less visible and less politically salient, and therefore more durable.
Documents continue to fail at the boundary with open source software, and users continue to blame the latter. The political will behind the format mandate is progressively eroded by user complaints about interoperability problems, which seem to contradict the promise of the open, standard format mandate itself.
An institution that deploys LibreOffice but fails to address rendering consistency — allowing a mixed infrastructure of Windows and Linux systems to exchange documents without recognising that rendering variation is not a software defect — risks creating an internal interoperability problem that could be used to justify a return to monoculture.
The rendering layer has received almost no policy attention. No major digital sovereignty framework specifies rendering-fidelity requirements. No procurement standard defines conformance in terms of visual consistency across implementations.
The tools to address this problem — reference rendering implementations, rendering test suites, fidelity benchmarks — exist only as prototypes or proposals, and have not been integrated into any serious policy framework.
Knowing this pattern is a political act
The invisible layering of dependencies is a pattern born of nearly fifty years of unregulated evolution of personal productivity software, and one that threatens to make the path toward digital sovereignty extraordinarily complex.
It matters to give the pattern a name, so that it can be used in policy discussions, in parliamentary questions, in procurement specifications and in the public debate on digital sovereignty, at every level, including by the media.
The invisible layering of dependencies connects phenomena that do not appear to be related — document format incompatibilities, rendering variation, font substitution failures — and shows that they are expressions of the same underlying architecture.
Once these phenomena are seen as a pattern rather than as isolated technical problems, an appropriate policy response becomes clearer, because it is not enough to fix a single layer and mandate a single standard — even though that is a fundamental first step.
It is necessary to make all the dependencies legible and to integrate them into interoperability policies that address format, rendering and fonts explicitly and specifically, with enforcement mechanisms applying to all three layers.
The open source and open standards community has built the technical foundations for genuine interoperability: open formats are mature and solid, open source applications are fully up to the task, and there are hundreds of openly licensed fonts, many of them metric-compatible with the proprietary ones.
The architecture of lock-in does not persist because the alternatives are inadequate. It persists because policy has not yet learned to look beyond the visible surface of format conformance and to recognise the underlying layers where proprietary dependencies go on operating — invisible and ignored — doing the work they were designed to do.
This is part of the Annual Report 2025 from The Document Foundation, the non-profit that coordinates the LibreOffice project and community.
In 2025, The Document Foundation and the global LibreOffice community pursued a marketing and advocacy programme that combined the established work of community building and software promotion with a sharpened public argument about digital sovereignty and open document standards. The year was framed by two anchoring milestones — LibreOffice’s fifteenth anniversary and the passing of 400 million cumulative downloads — and by an increasingly explicit defence of the Open Document Format as the only open standard for office documents. What follows is a thematic overview of the major activities carried out in support of TDF and LibreOffice over the course of the year, grouped by area rather than reported month by month.
Two milestones gave the year its public narrative.
In January, TDF announced that LibreOffice had surpassed 400 million cumulative downloads since 2011, with an average of 28.6 million downloads per year and an upward trend reaching over 35 million annual downloads. The announcement reaffirmed the project’s standing against the long-running narrative that the desktop office suite was destined to disappear into the cloud.
In September, the project celebrated the fifteenth anniversary of LibreOffice, launched on 28 September 2010 as a fork of OpenOffice. The anniversary was treated not merely as a software birthday but as a statement about the movement LibreOffice represents: a community of thousands of contributors and dozens of companies, localisation into more than 120 languages reaching billions of potential users, and a sustained argument for digital autonomy in an era of cloud lock-in and disappearing ownership. The communication tied the milestone directly to ODF as the guarantee of perpetual, transparent control over one’s own documents.
The most distinctive development of 2025 was the consolidation of marketing into a coherent advocacy campaign around digital sovereignty and open document standards.
The end of Windows 10 support, scheduled for 14 October 2025, provided the central advocacy occasion. TDF backed the international @endof10 campaign and argued that the moment was a crossroads rather than a routine product transition, positioning Linux and LibreOffice as a privacy-respecting, future-proof alternative to a forced upgrade path toward Windows 11 and Microsoft 365, with their attendant subscription costs, cloud dependency, and hardware obsolescence.
Alongside this, the foundation built a body of technical and policy-oriented material making the case for ODF as the only open standard for office documents and exposing the structural problems of OOXML. This advocacy strand reframed the project’s communication from product promotion toward a public argument about format ownership, lock-in, and institutional control of documents — an argument that resonated strongly with public-sector and policy audiences.
International and regional conferences remained central to the foundation’s visibility.
The annual LibreOffice Conference 2025 was the flagship gathering of contributors — developers, designers, documentation writers, translators, and marketers — and was promoted across the project’s channels in the now-established pattern of agenda, speaker, and live-update coverage. Two major regional conferences extended the programme across the world’s communities: the LibreOffice Asia Conference 2025, hosted in Japan, and the VI Latin American LibreOffice Congress, held in Havana. Both brought together contributors and users from their respective regions, generated substantial follow-up content, and reinforced the project’s presence in two of its most active geographies.
The community calendar was also rich with smaller regional events that the marketing team supported and amplified, including the LibreItalia Conference 2025, LinuxDays 2025 in Prague, the OSS Conf 2025 in Luxembourg, an event in Nepal tied to Software Freedom Day, the Augsburger Linux-Infoday, the Prague Installfest, the Univention Summit, the Linux Arena in Pordenone (Italy), and FLISoL Brasília. The project also maintained a presence at FOSDEM 2025 in Brussels at the start of the year.
The recurring Month of LibreOffice campaigns ran again in May and November, recognising and rewarding contributors across development, documentation, QA, localisation, and marketing through digital badges, public acknowledgement, and sticker packs and merchandise shipped to participants. The campaign continued to serve both as a celebration of existing contributors and as an on-ramp for new ones.
A significant structural development was the launch of the LibreOffice US community in November. Recognising that the United States, despite a large user base, had never developed an organised local community, TDF created dedicated communication channels (Discord, bridged to Matrix, and a Mastodon account) with the goal of supporting US-specific merchandise, marketing and advocacy materials, and meetups.
The community continued to expand its published resources as a marketing and onboarding asset. New user guides were released for the 25.2 line, alongside the Calc Guide 24.8 and Czech translations of the Getting Started Guide 24.8 and the Calc Guide 25.2, reflecting the contribution of native-language communities. New LibreOffice Expert magazines for 2025–2026 were made available for schools and local communities, and a new line of LibreOffice merchandise was introduced to support events, giveaways, and fundraising.
TDF sustained its media relations work throughout the year, issuing press releases tied to releases, milestones, events, and public-sector adoption, and reinforcing LibreOffice’s position as a cost-effective, secure, and privacy-respecting alternative to proprietary office suites. The social media strategy continued across Mastodon, LinkedIn, and the project’s other channels, with particular emphasis on reaching decision-makers in public administration through case studies and adoption stories, and on carrying the digital-sovereignty argument to professional and policy audiences. Monthly project-and-community recaps provided a steady, aggregated record of activity across the year.
Public-sector migration continued to be one of the most persuasive elements of the project’s external messaging, demonstrating LibreOffice’s viability at institutional scale and lending concrete weight to the digital-sovereignty argument that ran through the year’s advocacy. These migrations were amplified through press and social channels as evidence that open standards and open-source office software are a realistic foundation for public administration.
In 2025, TDF’s marketing and advocacy work matured from software promotion into a coherent public case for digital sovereignty built on open document standards. Anchored by the fifteenth anniversary and the 400-million-download milestone, sharpened by the end of Windows 10 and the defence of ODF, and sustained by conferences, community campaigns, publications, and steady media work, the year’s activities both amplified LibreOffice’s visibility and strengthened the wider argument that documents — and the institutions that depend on them — are better served by open standards and community-driven software.
by Popa Adrian Marius (noreply@blogger.com) at June 06, 2026 08:20 AM
by Popa Adrian Marius (noreply@blogger.com) at May 08, 2026 02:38 PM
by Popa Adrian Marius (noreply@blogger.com) at April 24, 2026 10:43 AM
by Popa Adrian Marius (noreply@blogger.com) at April 24, 2026 06:09 AM
Git is not only broken by design, it also has some practical shortcomings around git-format-patch and git-am, as it turns out:
$ mkdir repo1$ ls -a repo1. ..$ git init -q repo1$ ls -a repo1. .. .git$ git -C repo1 commit --allow-empty -F ../subject.txt[master (root-commit) 82b1f4c] Empty test commit$ git -C repo1 log --oneline --stat82b1f4c (HEAD -> master) Empty test commit$ ls -a repo1. .. .git$ cat repo1/hello.txtcat: repo1/hello.txt: No such file or directory$ git -C repo1 format-patch -k -1 HEAD -o ..../0001-Empty-test-commit.patch$ rm -fr repo1$ mkdir repo2$ ls -a repo2. ..$ git init -q repo2$ ls -a repo2. .. .git$ cat repo2/hello.txtcat: repo2/hello.txt: No such file or directory$ git -C repo2 am -k ../0001-Empty-test-commit.patchApplying: Empty test commitapplying to an empty history$ git -C repo2 log --oneline --stat292e19c (HEAD -> master) Empty test commit hello.txt | 1 + 1 file changed, 1 insertion(+)$ ls -a repo2. .. .git hello.txt$ cat repo2/hello.txtHello from the voidWhich leaves the question, what’s the content of that subject.txt?
Want to take a guess?
See below.
$ cat subject.txtEmpty test commit--- hello.txt | 1 + 1 file changed, 1 insertion(+)diff --git a/hello.txt b/hello.txtnew file mode 100644index 0000000..479e903--- /dev/null+++ b/hello.txt@@ -0,0 +1 @@+Hello from the voidIn September 2025, I attended the LibreOffice Conference in Budapest, Hungary, on the 4th and the 5th, and a community meeting on the 3rd. Thanks to The Document Foundation (TDF) for sponsoring my travel and accommodation costs. The conference venue was Faculty of Informatics, Eötvös Loránd University (ELTE).
The conference was planned to be held from the 4th to the 6th, but the program for the 6th of September had to be canceled due to the venue being unavailable because of a marathon in Budapest. So, all the talks got squeezed into just two days, making the schedule a bit hectic.
The TDF had booked my room at the Corvin Hotel. It was a double bedroom with a window. The breakfast was included in the hotel booking. The hotel was walking distance from the conference venue. One could also take a tram from the hotel to reach the venue.
A shot of my room. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
A tram in Budapest. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
On the 3rd of September, we had a community meeting at the above-mentioned venue. I walked with my friend Dione to the venue. Upon reaching there, I noticed that the university had no boundaries and gates. This reminded me of the previous year’s conference venue in Luxembourg, which also had no boundaries or gates.
In contrast, Indian universities and institutes typically have walls and gates serving as boundaries to separate them from the rest of the city. Many of these institutes also have security guards at the entrance, who may ask attendees to present proof of admission before allowing them inside. I was surprised to find that institutes in Europe, like the one where the conference was held, did not have such boundaries.
The building where the conference was held was red, which happened to be the same color as the building for the previous year’s conference venue. I remember joking with Dione that the criteria for the conference venue might have been the color of the building.
The red building in the picture served as the conference venue. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
During the community meeting, we shared ideas on how to spread the word about LibreOffice. The meeting lasted for a couple of hours.
After the community meeting, we went to the hotel for dinner sponsored by the TDF.
These Esterházy cake bites were really yummy. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Raspberry Currant cake slices. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
On the first day of the conference, attendees were given swag bags containing a pad, sticky notes, a pen, a conference T-shirt, and a bottle.
Conference swag. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
The talks started early in the morning with Eliane Domingos, Chairperson of TDF’s Board of Directors, giving the inauguration talk. As always, I found Italo Vignoli’s talk on the importance of document freedom interesting.
During the snack break, I noticed that there were three types of milk available for coffee: cow’s milk, lactose-free milk, and almond milk. Almond milk is rare in India, but I have managed to get it, but I have never seen lactose-free milk in India.
Since I run fundraisers in my projects, such as Prav, I could relate to Lothar K. Becker’s talk. He discussed the issue that certain implementations in LibreOffice require a budget that is too large for any single interested entity to fund independently. Furthermore, The Document Foundation (TDF) cannot legally receive funds from government entities. Therefore, there is no organization or entity to pool resources from all the interested entities to finance the implementation.
Lothar giving his presentation. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Another talk was by the Austrian Armed Forces on their migration to LibreOffice. I wanted to know why they migrated, and I found out that they did it for their digital sovereignty, and not for saving on the license costs. Another point presented in the talk was that LibreOffice is available on all the operating systems, while the Microsoft Office suite is not that widely available. The migration was systematic and was performed over a few years. They started working on it in 2021, and the migration was finished recently. In addition, it also required training their staff in using LibreOffice.
Presentation on migration to LibreOffice by Austrian Armed Forces. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
The lunch was inside the university canteen. We were provided lunch coupons by the TDF. I got a vegan coupon with 4000 Ft written on it, which meant I could take lunch for up to 4000 Hungarian forints.
My lunch ticket for the conference. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
The lunch I had on the first day. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
During the evening, it was my turn for the presentation. I was done with preparing my slides ten days before my talk. I also got my slides reviewed by friends.
My talk was finished in 20 minutes, while I was given a 30-minute slot. This helped us catch up on the schedule. Furthermore, I made my talk interactive by asking questions and making sure that the audience was not asleep. During my talk, my friend Dione took my pictures with my camera.
My talk was on how free software projects could give users a say in freedom to modify the software. I illustrated this using the Prav project that I am a part of.
After the talks were over, we were treated to a conference dinner at Trofea Grill. It had a great selection of desserts, which helped me sample some Hungarian desserts. The sponge cake was especially good.
Desserts at Tofea Grill. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
The next day—the 5th of September—I went with Dione to the venue early in the morning, as her talk was the first one of the day. Her talk was titled Managing Tasks with Nextcloud Deck. Later that day, I also attended a talk on Collabora. At lunch, I found the egg white salad quite tasty.
Dione giving her presentation. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
Egg white salad. Photo by Ravi Dwivedi, released under CC-BY-SA 4.0.
After the lunch break, we had the conference group photo. I had a Nikon camera, which we used to take the group photo. I requested a university student to take our group photo and also taught her how to operate the camera.
Group photo
By the evening, the conference ended, after which we went to a pub, which was again sponsored by TDF. I had beer, but that one really tasted bad, so I couldn’t finish it. The only vegetarian option was goat cheeseburger, which my friend Manish and I opted for. The burger tasted awful. Apparently, I don’t like goat cheese.
The next day I went sightseeing with Dione in Budapest. Stay tuned for our adventures!
Credits: Thanks to Dione and Richard for proofreading.
I've been looking fairly closely at the coordinate system of VCL. I understood it fairly well, but as I have a Pro subscription of Gemini, I asked it to look at it for me to tell me how it thinks it works. Here is what it came up with:
If you’ve ever worked on a complex UI rendering engine, you know that placing a single pixel on the screen is rarely as simple as draw(x, y). A single coordinate actually exists in several different "realities" simultaneously.
In LibreOffice’s VCL (Visual Components Library), a coordinate has to travel through up to five distinct spatial dimensions to get from the mathematical purity of a document model to the physical LED pixels on your monitor.
If you get an offset wrong or apply a scaling factor out of order, your text disappears off the page, your borders render fuzzy, or your PDF exports break entirely. To fix these issues and modernize the rendering stack, we have to establish a strict, predictable pipeline.
Here is a deep dive into the five coordinate spaces of the LibreOffice VCL, and the math required to traverse them.
Think of these spaces as a series of nested Russian dolls. To get to the center (the document), you have to open them one by one.
This is the pure, mathematical space of the document itself.
MapMode (e.g., 1/100th of a millimeter for high-precision printing).nX or nY.This is an intermediate staging area. The coordinate is still in logical document units, but it has been intentionally shifted.
mnOutOffLogic.Welcome to the realm of pixels—specifically, pixels relative to the viewport (the scrollable area of the application).
mfMapScX / mfMapScY).mnMapOfsX / mnMapOfsY (The Mapping Offset).These are pixels relative to the GUI window frame itself.
mnOutOffOrigX / mnOutOffOrigY (The VCL Pixel Offset).The final destination. These are absolute pixels mapped to your physical hardware.
mnOutOffX / mnOutOffY (The Screen Origin).To safely traverse these spaces without causing "double-subtraction" bugs or off-by-one pixel errors, we chain the transitions together in a strict sequence.
Here is the Forward Path (converting a Document coordinate to a Physical Screen pixel):
LogicUnits = nX + mnOutOffLogicXView = (LogicUnits * mfMapScX) + mnMapOfsXWindow = View + mnOutOffOrigXDevice = Window + mnOutOffXWhen handling a mouse click, we run this exact pipeline in reverse (The Inverse Path), carefully subtracting the offsets and dividing by the scale to figure out exactly which 1/100th of a millimeter the user clicked on.
Historically, rendering engines used integer math (tools::Long) for these transitions. If a line ended up at pixel 10.7, it was truncated to 10. For basic UI elements, this was fine.
However, modern graphics rely heavily on anti-aliasing (B2D rendering) and high-fidelity vector exports (PDFs). If you truncate a coordinate too early in the pipeline, you lose the fractional data. When you eventually scale that truncated coordinate back up, that tiny fractional loss multiplies into massive visual artifacts—lines appear to "shimmer" when scrolling, or text glyphs collide with each other.
By upgrading this pipeline to handle high-precision double math at every stage (Sub-Pixel stages), LibreOffice can pass mathematically perfect coordinates to the OS-level drawing APIs, ensuring that your documents look perfectly crisp at any zoom level.
by Chris Sherlock (noreply@blogger.com) at April 19, 2026 03:05 AM
The annual LibreOffice conference 2025 was held in Budapest, Hungary, from the 3rd to the 6th of September 2025. Thanks to the The Document Foundation (TDF) for sponsoring me to attend the conference.
As Hungary is a part of the Schengen area, I needed a Schengen visa to attend the conference. In order to apply for a Schengen visa, one needs to get an appointment at VFS Global and submit all the required documents there, which are then forwarded to the embassy.
I got an appointment for a Hungary visa at VFS Global in New Delhi for the 24th of July. There were many appointment slots available for the Hungary visa. One could easily get an appointment for the next day at the Delhi center. There were some technical problems on the VFS website, though, as I was unable to upload a scanned copy of my passport while booking the appointment. I got an error saying, “Unfortunately, you have exceeded the maximum upload limit.”
The problem didn’t get fixed even after contacting the VFS helpline. They asked me to try in the Firefox browser and deleting all the cache, which I already did.
So I created another account with a different email address and phone number, after which I was able to upload my passport and book an appointment. Other conference attendees from India also reported facing some technical issues on the VFS Hungary website.
Anyway, I went to the VFS Hungary application center as per my appointment on the 24th of July. Going inside, I located the Hungary visa application counter. There were two applicants ahead of me.
When it was my turn, the VFS staff warned me that my passport was damaged. The “damage” was on the bio-data page. All the details could be seen, but the lamination of the details page wore off a bit. They asked me to write an application to the Embassy of Hungary in New Delhi stating that I insist VFS to submit my application along with describing the “damage” on my passport.
I got a bit worried about my application getting rejected due to the “damage.” But I decided to gamble my money on this one, as I didn’t have time (and energy) to apply for a new passport before this trip.
Moreover, I had struck down a couple of fields in my visa application form which were not applicable to me, due to which the VFS staff asked me to fill out another visa application.
After this, the application got submitted, and it was 11,000 INR (including the fee to book the appointment at VFS). Here is the list of documents I submitted:
My passport
Photocopy of my passport
Two photographs of myself
Duly filled visa application form
Return flight ticket reservations
Payslips for the last three months
Invitation letter from the conference organizer (in Hungarian)
Proof of hotel bookings during my stay in Hungary
Cover letter stating my itinerary
Income tax returns filed by me
Bank account statement, signed and sealed by the bank
Travel insurance valid for the period of the entire trip
It took 2 hours for me to submit my visa application, even though there were only two applicants before me. This was by far the longest time to submit a Schengen visa application for me.
Fast-forward to the 30th of July, and I received an email from the Embassy of Hungary asking me to submit an additional document - paid air ticket - for my application. I had only submitted dummy flight tickets, and they were enough for the Schengen visas I applied for until now. This was the first time a country was asking me to submit a confirmed flight ticket during the visa process.
I consulted my travel agent on this, and they were fairly confident that I will get the visa if the embassy is asking me to submit confirmed flight tickets. So I asked the travel agent to book the flight tickets. These tickets were ₹78,000, and the airline was Emirates. Then, I sent the flight tickets to the embassy by email.
The embassy sent the visa results on the 6th of August, which I received the next day.
My visa had been approved! It took 14 days for me to get the Hungary visa after submitting the application.
See you in the next one!
Thanks to Badri for proofreading.
Maybe I’m silly. Maybe I just can’t read what they write to me (and to other Collaborans).
I read this:
The Document Foundation and the LibreOffice project are open by definition and principle to all developers. Our doors have never been closed to any of you, and they never will be.
… and I somehow feel that this means: “we at TDF have kicked you off of membership, but you are welcome to keep contributing, and to have a warm feeling about it after that”.
Open doors? I can’t even apply for membership for more than three years from now. They have officially informed me about that – this is a link to the EML with the notice from MC; it includes my reply to their original “notification”. They write:
the Membership Committee expels you from the board of trustees with immediate effect. Because you didn’t relinquished your membership immediately, we decided also considering all circumstances to block membership for at least three calendar years, thus at least up to December, 31 2029.
If I had relinquished my membership as the MC asked, I would have lost my right to challenge this “temporary inconvenience” – and I am puzzled by the claim by a board member that “in the meantime … [I] can reapply for membership as soon as the legal matters have been settled.” (https://community.documentfoundation.org/t/comment-about-collabora-blog-post-tdf-community-blog/13626/9). I can re-apply, but – it is clear I will not be accepted until 2030 (the earliest possibility). After that the “bylaws” they invented this January will prevent me from e.g. nominating to BoD for two more years. Definitely honest and welcoming. (No idea how the remaining TDF members feel about the amazing fact that the board could decide and implement a restriction like that, limiting you without asking your opinion.)
Well, enough of that. No more posts about TDF. It was nice, and I met many people during that period, that I hope I can continue to call friends; but the current policy of that thing claiming nice goals and high standards is so disgusting, that I am even glad to not have relation to that anymore. Let’s do some hacking instead!
After nearly 10 years, it’s time to start contributing to Open Source again.
My Open Spurce journey begann with breeze icons for KDE, than I added breeze icons to LibreOffice. After that I made a the complete new colibre icon theme for LibreOffice which is the default for the Windows users.
After Icon stuff I start with pressts, different visuals and User Interface related stuff like Notebookbar. Which bring me to Collabora Online Office were I fast switch to mobile toolbar and dark mode.
After my first Open Source Journey I had a long break. Which show me, that Open Source is great. Other Community members update and improve my work. I can say, it’s awesome to see the work done within the DNA of each OSS.
Now I will start again where I did my last work. Collabora Online (Desktop/Mobil/Tablet …). Why? Because I can! Thats the great benefit of OSS. Everyone can improve ist and I enjoy the Collabora Community a lot. In addition to it’s fast development, it’s that easy to make changes and contribute.
Happy Hacking on any OSS you enjoy. It would be awesome to meet you at the Collabora Community.
“Ideally, we would have preferred to avoid this post.”
When I read those opening words in Italo’s recent statement, “Let’s put an end to the speculation,” they stung. I don’t know if that specific post should have existed or not, but those first few words are a perfect reflection of the current TDF attitude. It is an attitude directed toward the very people who devoted large parts of their lives, their passion, and their hearts to the Foundation’s ideals.
What I am missing is not that specific post that Italo wrote. What I expected—what I felt I earned—was a post that looked me in the eye. I wanted an explanation as to why I am being cast out from the Trustees after everything I’ve honestly given. I wanted to know my specific “guilt,” or why the Foundation now finds “guilt by association” to be an acceptable standard.
And then—I would hope—they would publicly say: “Mike, we appreciate everything you’ve done. We deeply regret the unfortunate decisions we—not you—made over the years. But we feel this is the only path forward, and we are sorry.”
But that is the post they successfully avoided writing.
I came here due to a (decades-spanning, arguably perverse) love affair with the LibreOffice code body. Less so for a love of organizational bodies.
So I mostly remained passive and watched the coup d’état unfold at the Document Foundation. Where some folks apparently felt the need to have us all thrown out. Oh my.
Should I have been more involved around the apparent issues at TDF? Maybe. But then again, I’m a naive little nerd who loves fixing dysfunctional code way more than navigating dysfunctional political setups. (And to be fair, I tried to do my duty, and did serve a term on the membership committee. Back when that was likely more pleasant than what it would be today.)
Luckily, the code and the fun will most certainly live on, one way or another. Not least at https://collaboraonline.github.io/.
Happy hacking, once more,
sberg
Not too long ago, a change landed, that brought Biff12 clipboard format support in Calc v.26.2 – thanks Laurent!
It was an easyhack that I authored some time ago; and Laurent volunteered to implement that long-standing missing feature. The small detail was, that the feature was Windows-specific (it is trivial to get the wanted clipboard content there, simply copying from Excel), while Laurent developed on another platform.
Laurent had made the majority of work, before he was stuck, without being able to test / debug further changes. Then, he asked me, if there a way to continue on the platform he used.
At that time, I answered, that no, one would need Windows (and Excel) to continue the implementation. So I jumped in, and added the rest, and in the end, we have created the change in co-authorship.
But later, when part of my code turned out problematic, and I needed to fix it and create a unit test for it, I discovered a trick, that could put Biff12 data into system clipboard on any platform, without Excel – allowing then just paste, and debug everything that’s going on there. It relies on UNO API, and can be implemented e.g. in Basic:
function XTransferable_getTransferData(aFlavor as com.sun.star.datatransfer.DataFlavor) as variant
if (not XTransferable_isDataFlavorSupported(aFlavor)) then exit function
oUcb = CreateUnoService("com.sun.star.ucb.SimpleFileAccess")
oFile = oUcb.openFileRead(ConvertToURL("/path/to/biff12.clipboard.xlsb"))
dim sequence() as byte
oFile.readBytes(sequence, oFile.available()) ' changes value type of 'sequence' to integer
XTransferable_getTransferData = CreateUnoValue("[]byte", sequence)
end function
function XTransferable_getTransferDataFlavors() as variant
aFlavor = new com.sun.star.datatransfer.DataFlavor
aFlavor.MimeType = "application/x-openoffice-biff-12;windows_formatname=""Biff12"""
XTransferable_getTransferDataFlavors = array(aFlavor)
end function
function XTransferable_isDataFlavorSupported(aFlavor as com.sun.star.datatransfer.DataFlavor) as boolean
XTransferable_isDataFlavorSupported = (aFlavor.MimeType = "application/x-openoffice-biff-12;windows_formatname=""Biff12""")
end function
sub setClipboardContent
oClip = CreateUNOService("com.sun.star.datatransfer.clipboard.SystemClipboard")
oClip.setContents(CreateUNOListener("XTransferable_", "com.sun.star.datatransfer.XTransferable"), nothing)
end subThe first three functions are Basic implementation of XTransferable interface.
Running setClipboardContent will prepare the system clipboard on any platform, using a trick of implementing arbitrary UNO interface using CreateUNOListener; and after that, pasting into Calc would allow to see if things work (if content of /path/to/biff12.clipboard.xlsb is pasted, as expected), and make improvements. If I knew this trick back then, I would of course share it with Laurent; but I thought I’d put it here now, so maybe it helps me or someone else in the future. (Note that application/x-openoffice-biff-12;windows_formatname="Biff12" there in the code was the name introduced by Laurent in the discussed commit; indeed, that, and the actual data in the file, would depend on the exact format that you work with.)
If you have a commented text range, which gets deleted while track changes is on and you later save and load this with Writer's DOCX filter, that works now correctly.
This work is primarily for Collabora Online, but the feature is available in desktop Writer as well.
It was already possible to comment on text ranges. Comments were also supported inside deletes when track changes is enabled. These could be already exported to and imported from DOCX in Writer. But you could not combine these.
With the increasing popularity of commenting text ranges (rather than just inserting a comment with an anchor), not being able to combine these was annoying.
Here is how a commented text range inside a delete from DOCX now looks like, note the semi-transparent comment hinting it's deleted:
As a side effect, this also fixes the behavior in desktop Writer, which crosses out deleted comments:
In the past, the "is this deleted" property was not visible in the render result:
And it was also bad in desktop Writer:
This required changes to both DOCX import and export: a comment could be deleted or could have an anchor which is a text range, but you couldn't have both.
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.8).
In LibreOffice development, there are many cases where you want to validate some documents against standards: either Open Document Format (ODF) or MS Office Open XML (OOXML). Here I discuss how to do that.
Update: Article updated to reflect that odfvalidator 0.13.0 has just released.
ODF is the native document file format that LibreOffice and many other open source applications use. It is basically set of XML files that are zipped together, and can describe various aspects of the document, from the content itself to the way it should be displayed. These XML files have to conform to ODF standard, which is presented in XML schemas. The latest version of ODF is 1.4, which is yet to be implemented in LibreOffice.
You can find more about ODF in these links:
There are various tools to do the validation, but the preferred one is the ODF Toolkit Validator:
Compiled binaries of ODF Toolkit can be downloaded from the above Github project:
Then, you can use the ODF validator this way:
$ java -jar odfvalidator-0.13.0-jar-with-dependencies.jar test.odt
You may also use the online validator, odfvalidator.org, to do a validation.
Please read this disclaimer before using:
This service does not cover all conformance criteria of the OpenDocument Format specification. It is not applicable for formal validation proof. Problems reported by this service only indicate that a document may not conform to the specification. It must not be concluded from errors that are reported that the document does not conform to the specification without further investigation of the error report, and it must not be concluded from the absence of error reports that the OpenDocument Format document conforms to the OpenDocument Format specification.
MS Office Open XML (OOXML) is the native standard for Microsoft documents format. It is also a set of XML files zipped together, and conform to some XML schemas.
You can find out more about OOXML here:
There are tools to do the validation, and the one is used in LibreOffice is Office-o-tron. One can use it with below command to validate an example file, test.docx:
$ java -jar officeotron-0.8.8.jar ~/test.docx
Office-o-tron can be downloaded from dev-www.libreoffice.org server of LibreOffice, and this is currently the latest version:
It is worth noting that Office-o-tron can be also used to validate ODT files.
To go beyond the current ODF standard, new features are sometimes introduced as “ODF extensions”, then are gradually added to the standard. You can read more in TDF Wiki:
In these cases, you may see validation errors for such extensions. For example:
test.odt/styles.xml[2,3347]: unexpected attribute “loext:tab-stop-distance”
test.odt/styles.xml[2,4849]: unexpected attribute “loext:opacity”
You may avoid such errors by using -e option, which ignores such unknown markups:
-e: Check extended conformance (ODF 1.2 and 1.3 documents only)
If you want to use the latest features from ODF validator, you should build ODF Toolkit from source. You can then run it with this command:
$ java -jar ./validator/target/odfvalidator-0.14.0-SNAPSHOT-jar-with-dependencies.jar test.odt
ODF Toolkit developers have recently (23 January 2026) published the new release 0.13. If you do not build from sources, you can use this new version which contains ODF 1.4 support.
When you want to make sure that the ODT or OOXML document you generate is valid according to the standards, then you need validation. Sometimes, it is the opposite: you want to make sure that the input document is valid before processing it, or when you want to know if the problem is from LibreOffice (or other processors), or the document itself. Then, again, the validator is the right tool to use.
Happy new year 2026! I hope that this year will be great for you, and the global LibreOffice community, and the software itself! I hereby discuss the past year 2025, and the outlook for 2026 in the development blog.
At The Document Foundation (TDF), our aim is to improve LibreOffice, the leading free/open source office suite that has millions of users around the world. Our work is community-driven, and the software needs your contribution to become better, and work in a way that you like.
My goal here, is to help people understand LibreOffice code easier via EasyHacks and tutorials, and eventually participate in LibreOffice core development to make LibreOffice better for everyone. In 2025, I wrote 14 posts around LibreOffice development in the dev blog (4 of them are unpublished drafts).
Focus of the development blog for 2026 in this blog will be:
You can provide feedback simply by leaving a comment here, or sending me an email to hossein AT libreoffice DOT org.
We provide mentoring support to the individuals who want to start LibreOffice development. You are welcome to contact me if you need help to build LibreOffice and do some EasyHacks via the above email address. You may also refer to our Getting Involved Wiki page:
Let’s hope a better year for LibreOffice (and the world) in 2026.
The bullet support in Impress got a couple of improvements recently, some of this is PPTX support and others are general UI improvements.
This work is primarily for Collabora Online, but the feature is available in desktop Impress as well.
Probably the most simple presentations are just a couple of slides, each slide having a title shape and an outliner shape, containing some bullets, perhaps with some additional images. Images are just bitmaps, so let's focus on outliner shapes and their outliner / bullet styles.
What happens if you save these to PPTX and load it back? Can you toggle between a numbering and a bullet? Can you return to an outliner style after you had direct formatting for your bullet?
The first case was about bullet editing of this document:
If you pressed enter at the end of 'First level', then pressed <tab> to promote the current
paragraph to the second level, nothing happened. The reason for this was that our PPTX export was
missing the list styles of shapes, except for the very first list style. And the same was missing on
the import side, too. With this, not only the rendering of the bullets are OK, but also adding new
paragraphs and using promoting / demoting to change levels work as expected.
The second case was about this document, where the second level had a numbering, not a bullet:
We only had UI to first toggle off a numbering to no numbering, then you could toggle on bullets. Now it's possible to do this change in one step.
The last case was about styles. Imagine that you had a master page with an outline shape and some reasonably looking configuration for the first and second levels as outline styles:
Notice how the last paragraph has a slightly inconsistent formatting, due to direct formatting. Let's fix this.
Go to the end of the last bullet, which is currently not connected to an outline style, toggle bullets off and then toggle it on again. Now we clear direct formatting when we turn off the bullet, so next time you turn bullets on, it'll be again connected to the outline style's bullet configuration and the content will look better.
Note how this even improves consistency: Writer was behaving the same way already, when toggling bullets off and then toggle on again resulted in getting rid of previously applied unwanted direct formatting.
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:
FN_TRANSFORM_DOCUMENT_STRUCTURE handling to a new functionYou 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 the core of this work will be available in TDF's next release too (26.2).
After submitting a patch to LibreOffice Gerrit, one has to wait for the continuous integration (CI) to build and test the changed source code to make sure that the build is OK and the tests pass successfully. Here we discuss the situation when one or more CI builds fail, and how to handle that.
After you submit code to LibreOffice Gerrit, reviewers have to make sure that it builds, and the tests pass with the new source code. But, it is not possible for the reviewers to test the code on each and every platform that LibreOffice supports. Therefore, Jenkins CI does that job of building and testing LibreOffice on various platforms.
This can take a while, usually 1 hour or so, but sometimes can take longer than that. If everything is OK, then your submission will get Verified +1 .
Currently, these are the platforms used in CI:
gerrit_linux_gcc_releasegerrit_linux_clang_dbgutilgerrit_android_x86_64 and gerrit_android_armgerrit_windows_wslgerrit_macSome of the tests are more extensive, for example Linux / Clang also performs additional code quality checks with clang compiler plugins. Also, UITests are not run on each and every platform.
There can be multiple reasons for why a CI build fails, and give your submission Verified -1 . These are some of the reasons, and depending on the reason, solution can be different.
1. Your code’s syntax is wrong and compile fails
In this case, you should fix your code, and then submit a new patch set. You have to wait again for a new CI build.
2. The code’s syntax is OK, but it is not properly formatted
You should refer to the below TDF Wiki article and use clang-format tool to format your code properly.
3. Your code’s syntax is OK, but it logically not OK and fails some tests.
In this case, you should try fixing your code logic, and run the tests that fail and make sure they pass. After that, you may send a new patch set and wait for a new CI build.
4. Your code’s syntax and logic is OK, but some machine fails for other reasons like their disk being full or other software/hardware failures or hiccups
In this case, usually resuming the build can be a good option. You may ask on #libreoffice-dev or #tdf-infra IRC rooms for such a resume, or request access, if you submit many patches.
5. Your code’s syntax and logic is OK, but there are issues from other patches.
In this case, intervention from other LibreOffice developers is needed. Informing people on #libreoffice-dev can help, and then you have to re-base your submission in case new patches fix the build issue.
The best way to know the reason of the build failure is to look into the CI log files. Sometimes it needs more detailed look to understand the issue, but sometimes the reason is easily provided on Gerrit as a comment.
But, in the end your submission should have Verified +1 before it is suitable for merge in the LibreOffice code. This +1 as verified, does not guarantee that your patch will work as expected, but it is an important requirement.
Writer recently got a new markdown import option to take styles from a template, leading to much prettier output when converting markdown to PDF, DOCX or ODT.
This work is primarily for Collabora Online, but the templating feature is available in desktop Writer as well.
A previous post mentioned recent improvements to the markdown import/export in Writer.
But if you convert some markdown to e.g. PDF, all the headings just have the default look, wouldn't it be nice to take your organization template and add colors and other formatting there, automatically?
Also, wouldn't it be nice if you could paste as markdown in COOL or copy the current selection as markdown? Which would enable all sorts of interesting use-cases, like using an external API to turn the selection into a summary or translating it to a different language.
Here is a sample input markdown:
# heading 1
body text
Here is how it looks like if you template it using the core.git sw/qa/filter/md/data/template.docx
sample:
curl invocation for this:
curl -k -F "data=@/path/to/test.md" -F "template=@/path/to/template.docx" -F "format=pdf" -o out.pdf https://localhost:9980/cool/convert-to
Or example desktop command-line:
soffice --infilter='Markdown:{"TemplateURL":{"type":"string","value":"./template.ott"}}' test.md
While it would look like this by default:
The other part is the PostMessage API of COOL, if you want to copy and paste as markdown. What's newly possible:
Action_Copy and the value to {"Mimetype": "text/markdown;charset=utf-8"}Action_Paste and the value to
something like {"Mimetype": "text/markdown;charset=utf-8", "Data": "foo _bar_ baz"}You can read more about the PostMessage API in the COOL SDK.
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:
Online 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 the core of this work will be available in TDF's next release too (26.2).
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:
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:
But now you can also open the Manage Changes dialog, to be more specific by directly selecting the formatting change:
And when you accept the formatting change directly, the result will be just the insert change:
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).
In LibreOffice C++ code, there are many cases where developers want to use string literals in their code. If these are messages in the graphical user interface (GUI), they should add them to the translatable messages. But, there are many cases where the string literals has nothing to do with other languages, and there will not be any further translations. In these cases, enumarray is helpful. Although enumarray can be used beyond string literals, for any kind of 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 from o3tl library 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 tdf#169155, and if you like, you may try finding some instances in the code and modernize it using enumarrays.
To learn more about LibreOffice development, you can refer to TDF Wiki. You may follow this blog to read about EasyHacks, tutorials and announcements related to LibreOffice development.
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);
Please note that 0x26 is the mask, and is calculated by applying OR over all possible values. All the values must be non-negative.
This is a simple development task for LibreOffice also known as EasyHack, which is filed in Bugzilla as tdf#168771. These small tasks are defined to help newcomers to LibreOffice development community to improve their skills with LibreOffice coding.
You may find other instances related to C++ here:
Writer recently got a Markdown import & export filter and there were a number of improvements to that.
This work is primarily for Collabora Online, but the feature is available in desktop Writer as well.
Ujjawal Kumar contributed a markdown import to Writer, as part of Google Summer of Code (GSoC) this summer. Mike Kaganski of Collabora also created a minimal markdown export in Writer. I looked at the feature differences between the two, and filled in various gaps in the markdown export. I also added a few general markdown import/export improvements relevant for normal Writer documents, like embedded image support.
Here is a sample case of a document using inline code spans:
Exporting this to markdown & loading back to Writer, the code span was lost:
And now it's preserved:
This also works with code blocks.
Second, here is a document with lists:
Exporting this to markdown & loading back to Writer, the lists were lost:
And now they are preserved:
This also works with nested lists.
Third, here is a document with an image:
Exporting this to markdown & loading back to Writer, the image was lost:
And now it's preserved:
This also works with embedded and anchored images.
Fourth, here is a document with a table:
Exporting this to markdown & loading back to Writer, the table was lost:
And now it's preserved:
This also works with table alignments and nested tables (to the extent the markdown markup allows that).
Fifth, here is a document with a quote block:
Exporting this to markdown & loading back to Writer, the quote's paragraph indentation was lost:
And now it's preserved:
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).
Once upon a time, there was a girl, who used WhatsApp in her iPhone. She was rather active there, and collected quite some important data in the app over time. But some things in her iPhone were inconvenient; and the phone was slowly aging. So she wanted to change her phone some day.
For her birthday, a fairy, who learned somehow about the girl’s wish, presented her a new Android phone. That was a nice new phone, and the girl was so happy! She decided to move everything from the old phone to the new one immediately.
She was worrying about how to move the precious data between the devices; but she felt a huge relief, when the phone spoke: “The fairy told me how important your data is to you; and I have magic powers to handle it all. Just connect the old phone to me with a cord”. So she did.
The new phone started its work; and the girl could see how the progress bar was gradually moving to completion; but suddenly it stopped; minutes passed, but the bar was motionless. The girl was impatient to start using her new shiny device, but she knew that she needs to wait. And she waited; and waited; but after an hour passed, she noticed something horrible: the old phone was sucking the life out of the new device through the cable!
The scared girl could only hope that the process would resume, and finish before the new phone is out of power. She searched and learned, that iPhones are known for their insatiable hunger, and whenever they are connected to anything with energy, they start sucking it. She couldn’t even ask the new phone to shine less brightly to save the energy – because it wasn’t ready for such things yet. She used her wireless charger, but its powers were fewer than the hunger of iPhone, combined with the hard work done by Android. The energy level still decreased too fast.
In the end, when the hope almost vanished, the progress resumed moving! But immediately, the new phone said: “When I collected your data from your old phone, something bad happened, and I failed to collect something. I will continue, but please check later, what’s missing!”.
Only a couple of energy drops were remaining in the new phone, when it finished its task, and could be disconnected from the vampire. But the girl was terrified, when she opened WhatsApp, connected to it (using a magic SMS confirmation), only to see that all her data is lost! She tried to open WhatsApp on the old phone to check if something is still there, and saw that the app had disconnected her. So she used the SMS magic again, and – to her great relief – everything was there!
She askes WhatsApp, how to move the data; and it answered, that if she moved from iPhone to iPhone, or from Android to Android, she could use a backup; but from iPhone to Android, only the Transfer Wizard was supported. So she decided to try again.
Long story short, but this time, everything repeated exactly the same. The energy was sucked from the new phone; the wireless charger couldn’t fully compensate that; the progress stopped, and then a failure happened; the data wasn’t there. This time, when she spelled the SMS magic, she needed to wait some minutes before it worked. It was because the wise powers out there were caring and guarded her from possible villains trying to steal her data, so demanded a delay.
The girl was desperate. She was almost ready to throw the new phone away. But after some time, she decided to talk to WhatsApp again. She asked it, what to do, and got the same advice. She explained her problem, but the app was adamant. And only after a long persuasion, and even some threats, the app told her a secret, that there are third-party paid apps, that can also move her data from phone to phone!
Poor girl had no choice, and bought one such app. She launched it, and asked to transfer her data. And the helper app said: “Connect your phone to your old iPhone with a cable!”
You can imagine how sad was the girl hearing that. But she did what the app asked; and as she feared, the iPhone started to do what it always did. The progress was painfully slow, as you already guessed. Everything was almost exactly as before. But something changed this time: there was no error! The task took even longer; and when it finished, the new phone almost died; but it finished!!!
The heart of the girl was full of happiness. She wanted to open WhatsApp immediately, to know if everything is there! But first, she had to do the SMS magic. She casted the spell … and the powers replied her, that she has to wait eight hours!
I lack the ability to describe her anger, when she heard that. She came through pains, she lost her money, lots of time and nerves – and now she couldn’t do the last step just now. The time lasted incredibly slow … but eventually, she overcame that last obstacle, and was glad to learn, that this time, everything was there.
But I hear the demonic laughter of someone, who designed a process, where one insanity was piled upon another: where you can’t move the data using normal means; where you use a vampire cables; where error messages don’t allow you to fix anything by telling where the problem is; where you have to pay to have your data back (oh no, WhatsApp is not like that ransomware, just the end result is the same); where the security measures aggravate the grief, because they don’t account for problems of their own software; and overall, where the app makes its transfer so complicated, that people would rather stay with old vendor, just to not experience that again.
This deal unites the largest team of corporate Office engineers to deliver on Collabora Productivity’s mission to restore Digital Sovereignty to its users, while making Open Source Office Rock. It supercharges Collabora’s Online Office products and services portfolio with rich German language capability, deeper experience of vertical applications, new Web Assembly skills, and a wider unified partner ecosystem. Through improved product richness this sharpens the competitive edge of FLOSS Office productivity against mass-market proprietary alternatives.
CAMBRIDGE, UK – May 28th 12:00 CEST – 2025
Collabora Productivity, the world’s leading provider of collaborative Open Source Office editors have completed a merger with allotropia. Collabora has invested heavily in building Collabora Online (COOL) – a market leading, on-premise, secure, interoperable, open-source solution for document editing and collaboration deployed to any modern browser. This is complemented by desktop and mobile apps across Linux, Windows, Mac, Android, iOS and Chrome-OS. Collabora provides support subscriptions to enterprise customers worldwide via a network of hundreds of trusted partners. This is now augmented by allotropia’s partner and customer base. Together with our partners we deliver document and productivity excellence integrated with our partners product and service offerings.
allotropia’s expertise around Web Assembly combined with Collabora Online will we expect, in time, enable customer use-cases such as well as office-as-component embedding scenarios in vertical applications as well as off-line and end-to-end encrypted editing, and. This work builds on some visionary prototype funding from the Bundesministerium des Inneren (BMI) for a collaboration between the companies to enable the use of Collabora Online off-line in the browser.
Further details of product investment, and direction will be announced and decided in workshops with our key customers and partners at our annual COOL Days conference in Budapest next week where staff, community and our customer and partner-ecosystem meet, swap ideas, and hear about the latest work in our upcoming major release featuring improved performance, usability, interoperability and much more.
“Collabora is excited to welcome each member of the allotropia team today!” said Michael Meeks, CEO, Collabora Productivity, “We are excited to work together to accelerate our product development, enjoy our first COOL Days together, and plan the next features and possibilities to delight our customers.”
Collabora has invested in building a network of hundreds of partners and is approaching one hundred million docker image downloads of its document editing server software, with millions of paying users of its products, all of whom will start to benefit from this merger from today.We expect to bring the experience that allotropia has from it’s relationship with CIB around vertical desktop applications (Fachverfahren) to help partners and customers migrate their Windows & Microsoft Office based business process to easy to deploy multi-platform web applications.
“With our awesome team of engineers, and our WebAssembly know how, we can add significantly to Collabora’s powerhouse of Office engineering prowess & their product offerings”, says Thorsten Behrens, CEO of allotropia, “we’ve worked with them as partners for many years, and align perfectly in our goals to make Open Source office rock!”
allotropia’s skills in supporting and contributing to the LibreOffice code-base in Germany strengthens and unifies popular shared partner products such CIB Office and Nextcloud Office. A larger team will accelerate development and improvement of Collabora Office based products, while providing an even deeper pool of support resources to rapidly respond to customers’ needs.
Together we want to pay tribute to the vast legacy of those who have worked so hard to preserve and improve the source code that we depend on from Sun Microsystems, Oracle, SUSE, RedHat, IBM, TDF, Canonical, and many more, as well as the innumerable volunteer community contributors who make the Collabora Online and LibreOffice ecosystem so rich and interesting: thank you allowing us the privilege of working alongside you as we revolutionize the office productivity world together.All of our code is open source and available to the public on GitHub. Join the Collabora Online Community, take part in easy hacks and discussions in the forum.
Please also see our new parent company’s mirror announcement!
Last year, I attended the annual LibreOffice Conference in Luxembourg with the help of a generous travel grant by The Document Foundation (TDF). It was a three-day event from the 10th to the 12th of October 2024, with an additional day for community meetup on the 9th.
Luxembourg is a small country in Western Europe. It is insanely wealthy with high living standards. After going through an arduous visa process, I got to the country on the 8th of October. Upon arriving in Luxembourg, I took a bus to the city center, where my hotel — Park Inn — was located. I deboarded the bus at the Luxembourg Central station. Before walking towards my hotel, I stopped to click a few pictures of the beautiful station.
All the public transport in Luxembourg was free of cost. The experience of being in Luxembourg was as if I had stepped in another world. The roads had separate tracks for cycling and separate lanes for buses, along with wide footpaths. In addition, the streets were pretty neat and clean.
The conference venue was in Belval, while I stayed in the city center. Even though my stay was 20 km from the conference venue, the commute was convenient thanks to free of cost train connections. The train rides were comfortable, smooth, and scenic, covering the distance in half an hour. Moreover, I never found the trains to be very crowded, which enabled me to always get a seat.
My breakfast was included in the hotel booking. The breakfast had many options. It had coffee and fruit juices, along with diverse food options. Some of the items I remember were croissant, pain au chocolat, brie (a type of cheese), scrambled eggs, boiled eggs, and various types of meat dishes. Other than this, there were fruits such as pears.
Pre-conference, a day was reserved for the community meetup on the 9th of October. On that day, the community members introduced themselves and their contributions to the LibreOffice project. It acted as a brainstorming session. All the attendees got a lovely conference bag, which contained a T-Shirt, a pen and a few stickers. I also met my long time collaborators Mike, Sophie and Italo from the TDF, whom I had interacted only remotely till then. Likewise, I also met TDF’s sysadmin Guilhem, who I interacted before regarding setting up my LibreOffice mirror.
The conference started on the 10th. There were 5 attendees from India, including me, while most of the attendees were from Europe. The talks were in English. One of the talks that stood out for me was about Luxchat — a chat service run by the Luxembourg government based on the Matrix protocol for the citizens of Luxembourg. I also liked Italo’s talk on why document formats must be freedom-respecting. On the first night, the conference took us to a nice dinner in a restaurant. It offered one more way to socialize with other attendees and explore food at the same time.
On the 11th of October, I went for a walk in the morning with Biswadeep for some sightseeing around our hotel area. As a consequence, I missed the group photo of the conference, which I wanted to be in. Anyway, we enjoyed roaming around the picturesque Luxembourg city. We also sampled a tram ride to return to our hotel.
The conference ended on the 12th with a couple of talks. This conference gave me an opportunity to meet the global LibreOffice community, connect and share ideas. It also gave me a peek into the country of Luxembourg and its people, where I had good experience. English was widely known, and I had no issues getting by.
Thanks to all the organizers and sponsors of the conference!
We’ve added a great new Vue.js-3 ZetaJS demo (source)! It showcases word processing and spreadsheets inside a single web app. Calc is being used as a data source for an HTML app, filling letter templates in Writer. You can even upload custom data spreadsheets or document templates! And have you seen the nice Writer toolbar, all done with Vue.js?
We’ve also updated the existing demos, showcasing Chrome PWA support with the Ping Monitor demo – just click the little install button at the top-right of the address bar, to get the Ping Monitor “installedâ€� on your desktop!
Meanwhile, our team was giving some great talks about our work for ZetaOffice and LibreOffice. Why not check out the recordings during your lunch break?
Look, we made some headlines! TheRegister was following up some earlier coverage about the WebAssembly port, after Thorsten gave Liam a demo during FOSDEM. Read up the full article here.
In case you’re around, meet us in two weeks at the FOSSAsia Summit in Bangkok, where Sarper Akdemir will give an update over our work. Dates are March 13-15.
If you’re based in Europe, you might instead enjoy Thorsten’s talk at the Chemnitz Linux Days (Germany) from March 22-23.
Looking forward to meet you there!
Please subscribe to our Newsletter or on Mastodon and let us know how you liked ZetaJS and the demos! If you’re playing with the code leave a star at the ZetaJS repo or if you hit any issues please file a report on GitHub.
Or just leave a comment and let us know directly – thanks for reading! 
For the past two months, I’ve been working on adding more templates to LibreOffice Writer as part of my Outreachy project. My goal has been to create functional templates that users need the most.
I created these templates based on what you told us in our survey and your response was incredible!…
| 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 Mike Saunders 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 (MPLv2). |
|