Why OOXML-Based Suites Handle ODF Badly
The question arises naturally for anyone who chooses the standard format over the proprietary one: why do office suites that use OOXML as their native format handle ODF in ways that range from poor to appalling?
The two most obvious answers are these: vendors have neglected the format, treating it as an afterthought, or they are quietly working to discredit the very idea of transparent interoperability, through support so bad that it demonstrates the format “does not work”.
Both answers are too simplistic. The reality is that three distinct mechanisms are at work, applying to different vendors in different proportions and ultimately converging on the same outcome.
A challenge that is not a challenge
Reading and writing ODF faithfully, in isolation, is genuinely feasible: the format is completely and openly specified, and there is no equivalent of OOXML’s notorious legacy compatibility flags, which refer to undocumented behaviours of old Microsoft products that only Microsoft can reproduce.
A competent development team is able to implement ODF correctly on the basis of the ODF specification alone.
An office suite, however, does not implement a format in isolation: it has an internal, in-memory representation of the document. Loading a document is a mapping into that representation, and saving a document is a mapping out of it.
Fidelity is greatest when the internal model is congruent with the document format. LibreOffice’s model is essentially ODF, which is why, in this context, ODF is genuinely native.
When a suite’s internal model has the shape of OOXML, ODF stops being native and becomes an external import that must be converted to and from a representation built for a different format.
Take an ODF feature that OOXML lacks: the ODP field that displays the total number of slides. The instructive part is that the information itself is not missing from a PPTX file. The package enumerates every slide, and the count is available to any program that opens it. What OOXML provides no way to express is the statement that this number is the total. There is a field for the current slide number and none for the count, and Microsoft’s own guidance is to type the figure into a text box and keep it up to date by hand, which is a precise description of not having a field at all. Every published workaround is a macro or an add-in that computes the number once and writes it out as fixed text.
So when an ODP file carrying that field is opened in an OOXML-based editor, what is lost is not the data but the instruction. The number survives. The fact that it was calculated does not, and from that moment the document no longer knows how long it is.
The reverse direction fails more quietly, and therefore worse. A slide count exported from Impress to PPTX has to be written out as fixed text, so the presentation is correct on the day it is converted and wrong the first time a slide is added or removed. A number that has stopped being calculated but still looks plausible is more damaging than a visible gap, because nothing in the document signals that it needs checking.
An ODF-based editor handles the reverse case in an entirely different way. When it encounters a feature present in one format and absent from the other, it sets the data aside rather than discarding it, and restores it when the document returns to OOXML. In LibreOffice this mechanism has a name, the grab bag, and it is a documented part of the import filters rather than an incidental behaviour.
The difference does not lie in the quality of the import filter, but in the fact that the architecture was designed to hold the meaning of the other format.
This matters, because it means that poor ODF support in OOXML-based suites is largely overdetermined before the question of motive even arises. The difficulty is not absolute, but relative to the architecture the vendor has chosen.
Three mechanisms
First: the bet on a reference format. Some suites do not consider ODF at all, because they have built their value proposition on the other format.
OnlyOffice is the clearest case, because it was built around OOXML and converts every other format into that model, so ODF is a second-class import and export format by design.
WPS Office is software created to open docx, xlsx and pptx files faithfully. Its ODF functionality derives from the add-in of Microsoft’s own OpenXML project and was integrated into the application only in May 2022, as a conversion layer written for ODF 1.1, which is to say for the 2007 revision of the standard. Fifteen years of delay were built in on the day of release.
Google Workspace is a variant of the same logic rather than an exception to it. Its internal model is neither ODF nor OOXML but a proprietary web representation, and both formats reach it through a conversion layer. For a public administration the consequence is identical: the open standard is an export target, not the substrate the software thinks in.
For these vendors, ODF was never part of the strategy. Their proposition is to open Microsoft documents in something other than Microsoft Office, and to make them look right, so poor ODF support is the direct consequence of the strategy.
Second: deliberate underinvestment. This is probably a cause that cuts across the whole office suite sector. Although ODF is easier and cheaper to implement correctly, the process still involves development, quality assurance and maintenance costs and timelines, in order to keep pace with a continuously evolving standard.
If a vendor’s users mostly exchange docx files, the marginal commercial value of excellent ODF support is close to zero, so ODF is first implemented at the minimum level and then quietly left to rot.
The perception that ODF support does not matter is itself a consequence of a single company’s market dominance, and its effect is twofold. Lock-in becomes a software feature that the market regards as entirely normal, and ODF acquires a reputation for fragility that no deliberate campaign was required to produce.
Third: deliberate disqualification. This mechanism is real, and it concerns Microsoft itself, with Service Pack 2 for Office 2007. The ODF support it shipped failed in two opposite directions at once.
When reading an ODF spreadsheet produced by another application, Excel silently stripped out the formulas and kept only the last value each cell had held, reducing the document, in Rob Weir’s assessment at the time, to a mere “table of numbers” with the calculation logic gone. When writing, Excel placed formulas in an Excel namespace that was neither the one used by OpenOffice and the other ODF applications nor the OOXML one. Applications that checked the namespace rejected the document outright; those that did not check it displayed a corrupted file showing neither the formula nor the value correctly.
This is a textbook mechanism for discrediting interoperability: meeting a format requirement with an implementation that conforms only on paper and produces visibly broken files, demonstrating to every observer that ODF does not actually work.
At the time, Microsoft argued that the ODF standard did not define spreadsheet formulas, which arrived only with ODF 1.2, and that there was therefore no reference to follow. The argument does not survive Microsoft’s own reply. Responding publicly to Weir, Microsoft’s evangelist Doug Mahugh set the two behaviours side by side: faced with the same unrecognised formula syntax, IBM Lotus Symphony preserved the formula markup, while Excel preserved the cached values. Neither application had a specification to follow. Only one had an architecture with somewhere to put what it did not understand.
It is worth noting what Excel kept. Not the formula, but its last result, which is the same reduction we saw with the slide count, in a different application. A model shaped by OOXML retains the value and loses the computation that produced it, and a document reduced to its last results is a document that has stopped being able to correct itself.
That episode is seventeen years old, and it would be easy to set it aside as history. Microsoft Office today declares support for ODF 1.4. But what improved is the nominal conformance, not the architecture. The internal model is still OOXML, and every ODF document that passes through it is still a translation.
The synthesis
Poor ODF support is not a technical verdict on the format, but the visible shape of a market organised around the dominance of a single vendor, and that shape did not come about by chance.
For European public administrations, this redefines the practical question, because the interoperability problems they encounter when they try to migrate to the open standard ODF are not caused by ODF, which is entirely ready. They are evidence that most of the available tools were designed to be native to somebody else’s format, and that the one vendor with the power to change this situation has repeatedly chosen not to.
The precarious state of ODF support in the market is not a reason to hesitate over adopting the standard, but the strongest possible reason to mandate it, and to mandate it precisely.
The question that protects a public body’s documents, and its sovereignty over them, is not whether ODF is supported, but whether that support is native, that is, whether the software’s own internal model is the open standard, or the standard is merely a foreign element inside an engine built for something else.
The document format is the substrate of administrative continuity and public memory. Choosing tools for which the open standard is native is not a preference between equivalent options, but the difference between owning your documents and renting access to them from whoever controls the format in which they are actually written.
