LibreOffice 26.8 adds basic support for importing and exporting a range of chart types that Microsoft Office includes in OOXML files: box-and-whisker, funnel, Pareto, radial, treemap and waterfall charts. LibreOffice is unable to display or edit these charts, but it does recognise them, informs the user that the chart type is not yet supported, preserves the underlying definition unchanged, and rewrites it when the file is saved.
At first glance, this appears to be an admission of incompleteness, whereas it is actually an example of what implementing a proprietary format entails when the aim is interoperability – for the benefit of users, rather than a commercial strategy that treats users as mere tools.
What happened
Microsoft added these chart types to Office from 2016 onwards, storing them in a namespace generally referred to as ‘chartex’. The namespace is not part of the ISO/IEC 29500 text approved as an international standard, but is documented separately in Microsoft’s extension documentation.
This is entirely legal and perfectly normal commercial behaviour: a vendor improves its product and the file format evolves accordingly. The consequence, however, is that the format in everyday use is no longer the one that was standardised. The ISO number continues to be cited in tender documents and policy documents, but the files being exchanged are different.
For any implementer other than the vendor, this creates a permanent state of delay. This is not a one-off gap to be bridged with sufficient effort, but a structural delay, as the specifications are in the hands of a vendor that does not publish its release schedule, with priorities defined according to commercial criteria.
Three possible responses
An office suite that encounters a chart it does not recognise has three options:
- It can reject the file. This is an honest but pointless solution: the user is left with a document they cannot open and concludes that the software does not work.
- It can discard what it does not understand. The file opens, the chart disappears, and the user only realises this when the document is forwarded to a colleague and the chart is no longer present. This is the most damaging outcome, as the loss occurs silently and the blame falls on whoever opened the file last.
- They can retain what they are unable to display. The user is informed that this type of chart is not supported, so they see a placeholder rather than a blank space, and the underlying definition remains intact when the document is transferred from one application to another. The document is restored in full when returned to the source application.
LibreOffice 26.8 adopts the third option, the only one of the three that respects the fact that the document belongs to the user rather than to the software – or, indeed, to the company that develops the software.
Unfortunately, there is a limitation, and this is an exception. Charts with regional maps contain extensive geographical information that LibreOffice is unable to preserve. The chart type survives the import-export cycle, but very little of its content remains intact.
Why this is important beyond charts
The Chartex case is of limited scope. The model, however, is not.
All organisations whose documents are written in a format controlled by a single vendor accept a dependency they are unable to manage, because the specifications may change without notice, with the addition of features that are only understood by a single implementation.
Nothing untoward needs to happen for the organisation’s archives to become progressively more difficult to read by all other software.
The Open Document Format is not immune to change, but it changes differently. Revisions are proposed, discussed and approved by a technical committee at OASIS, whose work is public, and are published as version specifications that anyone is free to implement.
An implementer wishing to support ODF 1.4 can read the ODF 1.4 specification and put it into practice. This is the only difference, and it is sufficient.
The bidirectional preservation of unsupported features is what distinguishes a responsible implementation under current conditions, but it does not constitute an improvement on those conditions. LibreOffice is the only office suite to adopt this approach, in order to protect users and the content within their documents.
Facts Only
* LibreOffice 26.8 adds import and export support for box-and-whisker, funnel, Pareto, radial, treemap, and waterfall charts.
* LibreOffice cannot display or edit these chart types.
* The software notifies users when these chart types are encountered.
* The underlying definitions of these charts are preserved and rewritten upon saving.
* Microsoft Office added these chart types starting in 2016.
* These charts are stored in a namespace called "chartex."
* The "chartex" namespace is not part of the ISO/IEC 29500 international standard.
* Regional maps are an exception where content is not fully preserved during import-export.
* The Open Document Format (ODF) is managed by a technical committee at OASIS.
* ODF revisions are public and published as version specifications.
Executive Summary
LibreOffice 26.8 has introduced basic support for several Microsoft Office chart types, including box-and-whisker, funnel, Pareto, radial, treemap, and waterfall charts. While the software cannot display or edit these specific elements, it can now recognize them, notify the user of the limitation, and preserve the underlying data definition during the save process. This prevents the silent loss of data that occurs when unsupported elements are discarded, though regional maps remain an exception where content preservation is limited.
This technical implementation highlights a broader tension between proprietary and open standards. Microsoft's use of the "chartex" namespace—documented separately from the ISO/IEC 29500 international standard—creates a structural delay for third-party developers who must rely on vendor-controlled specifications. In contrast, the Open Document Format (ODF) utilizes a public, committee-driven revision process via OASIS. The choice to retain unsupported features is presented as a method of protecting user ownership of data against vendor-locked ecosystems.
Full Take
The strongest version of this narrative is that data sovereignty depends on the ability of software to act as a neutral steward of information, regardless of whether it can fully render that information. By implementing "bidirectional preservation," a tool ensures that the user—not the vendor—remains the ultimate authority over the document's integrity.
This situation reveals a persistent pattern of "standardization drift," where a format is nominally compliant with an international standard (ISO/IEC 29500) but evolves via proprietary extensions (chartex) that create a permanent lag for competitors. The argument posits a fundamental dichotomy: one model of evolution is driven by commercial priority and secrecy, while the other (ODF) is driven by public consensus and transparency.
The root cause is the tension between the commercial incentive to create "sticky" ecosystems (vendor lock-in) and the user's need for long-term archival stability. The implication is that relying on a single-vendor format introduces an unmanageable dependency; archives become progressively brittle as the only software capable of reading them evolves away from the public standard.
Patterns detected: none
If this were a coordinated influence campaign, the playbook would involve framing a minor technical update as a moral battle for "freedom" to distract from the software's actual inability to render the features. However, the content here focuses on the structural nature of file standards rather than hyperbole, remaining aligned with a technical critique of interoperability.
Bridge Questions:
1. Does the ability to preserve "invisible" data sufficiently mitigate the risks of using proprietary formats?
2. How would the landscape change if international standards bodies had the power to mandate the inclusion of all commercial extensions?
3. At what point does "preservation" become a poor substitute for actual feature parity?