LibreOffice 26.8 preserves Office charts it cannot render
The Document Foundation announced LibreOffice 26.8 on August 26, 2026, for Windows, macOS and Linux. Its release announcement describes “basic round-trip support” for newer Microsoft Office chart types. Round-trip here means opening a document in LibreOffice, saving it, and returning it to the application that created it.
That support has three distinct parts. LibreOffice recognizes the unsupported chart, tells the user which type it encountered, and retains the underlying definition for export when the document is saved. Rendering the chart on screen and providing controls to edit it are separate capabilities, and these charts do not gain either one in this release.
The foundation’s September explanation names box-and-whisker, funnel, Pareto, radial, treemap and waterfall charts. Its August release announcement uses “sunburst” where the later explanation says “radial.” Those are the terms in the two announcements; neither provides enough detail to treat the naming difference as a precise compatibility guarantee for every chart someone might describe as radial.
For the identified unsupported charts, LibreOffice presents a notice or placeholder rather than a working visualization. According to the foundation, retaining the definition allows the originating application to restore the chart when the file returns to it. That is meaningful progress for document exchange, even though someone relying on LibreOffice to read the chart still cannot complete that task.
This also sets the correct upgrade expectation. Installing LibreOffice 26.8 does not make an Office waterfall or treemap chart available for visual review or editing. The announced improvement concerns preservation. The foundation’s explanation does not establish a chart-by-chart baseline for previous LibreOffice versions, so it would be misleading to say that every earlier version necessarily deleted every chart on this list.
Microsoft’s chartex extension explains the compatibility boundary
The Document Foundation attributes the gap to Microsoft’s newer chart structures, stored in a namespace commonly called chartex. It says Microsoft introduced these chart types from Office 2016 onward and documents the extension separately from the ISO/IEC 29500 international standard for Office Open XML, or OOXML.
A namespace identifies the vocabulary used by a particular set of document structures. In this case, the practical distinction is between understanding the broader Office document format and understanding the additional structures that describe these charts. LibreOffice can encounter the chart definition inside a file without having the implementation needed to turn it into a displayed, editable chart.
This is why the phrase “supports Office files” leaves so much unsaid. A suite may open a document successfully while lacking support for a particular object inside it. For users exchanging documents, the useful questions are more specific: Does the chart display? Can its properties be edited? Does its definition survive saving? LibreOffice 26.8 gives different answers to those questions.
The foundation argues that vendor-specific extensions put alternative implementations in a continuing catch-up position. Its complaint is about the difference between the standardized format cited in procurement or policy documents and the richer format that applications actually write. That is TDF’s assessment of the interoperability problem, rather than evidence that Microsoft deliberately designed these charts to obstruct competitors.
There is also an important limit to the word “cannot.” TDF acknowledges that Microsoft documents the extension. The announcement establishes that LibreOffice currently lacks rendering and editing support; it does not establish that implementing those capabilities is technically impossible. Nor does it announce a release in which full support will arrive.
For an IT department, the immediate consequence is narrower than the standards dispute. A requirement that software “read and write OOXML” is insufficient to establish compatibility with a particular business document. The file’s actual features—and the operations employees need to perform on them—determine whether the workflow works.
LibreOffice’s preservation strategy protects content without enabling review
TDF frames the implementation choice as three possible responses to an unsupported chart: reject the document, discard the unrecognized object, or retain it while warning the user. LibreOffice 26.8 takes the third route. Its stated aim is to avoid silently removing content simply because the application cannot display it.
Rejecting the entire document would prevent users from working on content the suite does understand. Discarding the chart could be worse: a document might appear to open and save normally while losing something its author intended to keep. Retention makes a more useful compromise possible, with the unsupported object carried through the edit rather than treated as disposable.
But preserved does not mean reviewed. A person looking at a placeholder cannot verify the chart’s appearance or conclusions inside LibreOffice. If the chart is necessary to understand the document, successful opening is not successful reading. If it is necessary to approve the document, successful saving is not sufficient evidence for approval.
The same boundary applies when someone edits surrounding material. Keeping a chart definition intact protects that object, but it does not establish that every possible change to the rest of the document will remain consistent with it. The announcements do not document how all such interactions behave. Teams should therefore avoid treating the preservation claim as a guarantee for arbitrary cross-suite editing.
This suggests a useful distinction between participation and completion. LibreOffice 26.8 may let someone participate in a document workflow despite an unsupported chart. Completing visual review or chart editing still requires an application that understands that chart. That boundary should be explicit before a file moves through an approval chain, rather than discovered at its final handoff.
Regional map charts remain a documented data-loss exception
The regional-map limitation deserves more attention than a general compatibility footnote. TDF says these charts contain extensive geographic information that LibreOffice cannot preserve. The chart type survives import and export, but “very little of its content remains intact,” according to the foundation’s September explanation.
That is materially different from carrying an intact chart definition behind a placeholder. An object can remain identifiable as a map chart while losing much of the content needed to make it useful. Consequently, finding that a chart object still exists after saving is not enough to establish that a regional map survived.
For these documents, keep an untouched original before experimenting with a LibreOffice edit-and-save workflow. This is a precaution drawn from the documented loss, not a claim that LibreOffice provides a special recovery mechanism. Neither announcement describes a method for reconstructing the missing geographic information from the saved result.
Verification also needs to examine content, not merely the absence of an error message. Reopening the edited copy in Microsoft Office and comparing the map with the original is a reasonable acceptance check. The objective is to confirm that the geographic content required by the document remains present, rather than simply that Office can open the file.
The foundation does not enumerate every regional map configuration affected or provide a safe subset. Administrators therefore cannot use this announcement to certify a particular map-based template without checking that template’s actual workflow. Where preserving the map is essential, retaining the original and completing the edit in a known-compatible application is the more defensible choice.
Choose LibreOffice workflows by the chart task, not the file extension
Use LibreOffice 26.8 for these documents only when its preservation boundary fits the job; keep a compatible application available when users must inspect or edit the unsupported charts. That decision is more useful than classifying either suite as universally compatible or incompatible.
For a mixed Office-and-LibreOffice deployment, the acceptance criteria should separate display, editing and round-trip retention. A workflow that needs only to preserve an object has different requirements from one that needs to approve its visual contents. Regional maps require an additional content-integrity check because TDF expressly excludes them from the general preservation behavior.
A practical check can be kept simple, without relying on undocumented settings or conversion options:
- Keep an unchanged copy of a representative document containing the charts your team actually uses.
- Open a working copy in LibreOffice 26.8 and note which charts receive an unsupported-type notice.
- Perform only the kind of edit the proposed workflow requires, then save the working copy back in its Office format.
- Reopen that copy in Microsoft Office and compare the relevant chart content and appearance with the original.
- Accept the workflow only if the result meets the team’s actual reading, editing and preservation requirements.
This is a suggested validation process, not a reproduction of testing performed by WindowsForum or a vendor-certified procedure. It also does not establish behavior for every document once one example passes. Its value is that it tests the task an organization intends to permit.
When cross-suite chart editing is essential, a reasonable alternative is to agree on a chart type that both applications have demonstrated they can handle in that workflow. For presentation-only material, an accompanying static rendition can give recipients something to inspect, but it should be treated as a separate deliverable rather than evidence that the editable chart is supported.
The most concrete takeaways are:
- LibreOffice 26.8’s new support preserves specified Office chart definitions without making those charts visible or editable.
- An unsupported-chart notice identifies a real limitation and should affect who performs the document’s final review.
- Regional map charts can lose most of their geographic content, so their preservation must not be assumed.
- Keep original files and verify important charts in Microsoft Office before distributing a document saved through LibreOffice.
- Evaluate the exact document and task rather than relying on an OOXML file extension or a broad compatibility claim.
LibreOffice 26.8 offers a useful improvement for people whose documents must pass between office suites: unsupported charts need not be silently discarded merely because LibreOffice cannot render them. The practical boundary remains clear, however. Preservation can support a handoff; visual review and chart editing still belong in an application that understands the chart, and regional maps require particular care before the saved copy replaces the original.