LibreOffice 7.2 brings improved but still imperfect Microsoft Office compatibility

Also: Native for Apple Silicon but with health warning

The Document Foundation has released LibreOffice 7.2, including a native build for Apple Silicon though users are warned not to use it "for any critical purpose."

The new release is not a big one for features but is nevertheless notable for a couple of reasons.

First, there is now an official Apple Silicon build which can be found here, though the Foundation said that "because of the early stage of development on this specific platform, binaries are provided but should not be used for any critical purpose."

Second, there has been an effort to further improve compatibility with Microsoft Office document formats, with hundreds of fixes to small details that previously prevented identical rendering.

Both Microsoft Office and LibreOffice use an XML document format. According to the foundation: "Microsoft files are still based on the proprietary format deprecated by the ISO in April 2008, and not on the ISO approved standard, so they have a large amount of hidden artificial complexity." The native format of LibreOffice is the rival Open Document (ODF) standard.

Behind this comment lurks a large amount of intricacy. The Office XML wars data from the early 2000s when Sun led the open-source community in trying to disrupt the dominance of Microsoft Office by promoting its free OpenOffice alternative (LibreOffice was forked from the OpenOffice code).

ODF standardisation was part of that effort. Worried about losing market share because of standards mandated by governments and others, Microsoft embarked on its own standardisation effort, Office Open XML (OOXML).

Both are now ISO standards, but the complexity of Microsoft's formats, the huge legacy of existing documents going back to the '80s, and the fact that these formats are designed for Microsoft Office, means that OOXML is far from ideal as a universal document format.

LibreOffice 7.2 on Windows 10

A further complication is that in theory a variety of OOXML called Strict is the preferred standard, but in practice everyone (including Microsoft) uses OOXML Transitional, and realistically it seems that the period of transition may never end. This is the issue referenced by The Document Foundation above yet LibreOffice itself saves in the Transitional format, and an open issue to support Strict gets little attention. In practice, therefore, the Strict format is less well supported than Transitional – even though Microsoft has offered Strict as an option since 2012.

The US Library of Congress has some pragmatic notes on these formats. Regarding ODF, it said: "Despite official mandates and recommendations, adoption of ODF formats has been slow, particularly in the US," and reveals that the library has "around 52,000 files" with formats in the ODF family.

As for OOXML, the library said that it has nearly 800,000 files in .docx, which it considers an "acceptable format for textual works," unlike the older binary Microsoft Office formats. The library also notes the interest in converting documents from OOXML to ODF and said: "Although simple documents can be effectively converted, a round-trip to an identical document should never be expected."

Some Microsoft Office rivals made the decision to use Microsoft's formats as their own native formats. The makers of OnlyOffice claimed that "all the objects present in OnlyOffice are created strictly according to MS Office format specs. So, if you look at a doc as a set of objects, OnlyOffice's object models corresponds to OOXML specifications, while Libre's object model corresponds to ODF's ones."

Similarly, SoftMaker Office said that it "uses the Microsoft Office formats DOCX, XLSX and PPTX natively, obviating the need to convert documents for colleagues or business partners."

Compatibility hassles: A document with a diagram can get corrupted when saved as .docx from LibreOffice Writer (top is how it looks reopened in Microsoft Word)

Following the work done in LibreOffice 7.2, is its support for Microsoft Office formats now so good that this is no longer a concern? In search of a complex document, we took a 150-page PDF, used Word to convert it to .docx, and opened it in LibreOffice Writer.

The result was impressive: the document looked the same in Word and in Writer. Next, to test round-tripping, we saved the document as Open Document Text (.odt) and then resaved as .docx and opened it in Word. This was not so good: diagrams had gone wrong and were now broken up and overlaying the text, when reopened in Word.

A further experiment established that even without the intermediate step, just changing one character and saving the document corrupted it when opened in Word. Incidentally, this test also showed that using Microsoft Office support for Open Document formats is challenging: in our test, importing the .odt version to Word made the diagrams disappear completely.

No doubt the many improvements the LibreOffice team has made will make compatibility better and many documents will interoperate smoothly, but our brief experiment shows that sticking to one format and Office suite does still reduce friction in some cases.

There is a good financial and standards-based rationale for making that single suite LibreOffice, but against that, Microsoft Office is so deeply embedded that it remains a challenge. That said, in 2014, the UK Government Digital Service selected PDF/A or HTML for view-only government documents, and Open Document Format (ODF) for editable documents.

LibreOffice 7.2 is not just about document compatibility. Users can also enjoy new features like multiple columns in text boxes, new templates for the Impress presentation graphics application, full background fills in Writer, user interface improvements, and a new object inspector for developers. We covered many of these here.

Occasional compatibility hassles aside, LibreOffice remains among the most useful and widely used open-source desktop applications and, unlike Microsoft Office, is available for Linux as well as Mac and Windows. ®

Source