Category: Open Document Format

ODF ensures that documents remain accessible, portable, and free from restrictions. Now that version 1.3 has been widely adopted and version 1.4 is on the horizon, it’s time to have a look at the new features and upcoming releases.

ODF 1.3: What’s New

ODF 1.3 was finalised in January 2021 by OASIS. It introduced a number of long-awaited improvements, particularly in the areas of security, digital signatures, and document integrity.

1. Digital signatures and document security:

One of the most significant enhancements in ODF 1.3 was the formal specification for digital signatures:

• It now supports XAdES (XML Advanced Electronic Signatures).
• You can sign entire documents, individual parts (e.g. only spreadsheets), or even multiple sections.
• Improved metadata provides information about who signed, when and under what circumstances.

This is a significant development for public administrations and organisations that require reliable document verification.

2. OpenPGP support for encryption

• ODF 1.3 now offers optional OpenPGP-based encryption in addition to the traditional Blowfish method.
• Higher cryptographic standards and better integration with tools such as GnuPG are also included.
• It encourages key-based encryption for personal and business documents.

3. Change management:

• The format now offers greater granularity for change management.
• Supports change tracking in tables, which was previously a weak point.
• Improves compatibility with editing tools that handle collaborative workflows.

4. Metadata:

• Improved management of custom metadata fields using RDF.
• Greater richness of semantic descriptions of content (e.g. for archival or academic purposes).
• Encourages integration with deep graphs and linked data systems.

5. Other changes:

• New chart types and charting features.
• Improved text formatting options.
• Improved compliance with accessibility standards.

ODF 1.3 introduced two new compliance modes: Strict, for clean documents that comply with the specifications, and Extended, which allows specific enhancements by a company for broader feature support.

What’s new in ODF 1.4

ODF 1.4 is still under active development, with the first drafts already implemented in the latest versions of LibreOffice. Although the specifications are not final, the following is planned:

1. Change tracking:

• Support for tracking style changes (e.g. switching from bold to italic).
• Better differentiation between insertions, deletions and formatting changes.
• Change IDs and support for real-time conflict resolution for collaborative editing.

2. Charts:

• More flexibility in charts, including custom colours, gradient fills, multiple axes and formatted data labels.
• Better alignment with modern expectations and improved interoperability with Excel.

3. Accessibility:

• Clearer semantics for assistive technologies.
• Improved navigation for screen readers.
• Structural tags for headings, lists and tables make documents easier to analyse programmatically.

4. Form controls:

• More robust form field types, such as date pickers, drop-down menus and sliders.
• Better interaction support for forms within spreadsheets and presentations.
• Cross-platform consistency.

5. Improved spreadsheet features:

• Native support for named ranges in the sheet.
• Improved formula representation for functions in edge cases.
• More complex conditional formatting rules.

6. Compatibility:

• Mapping of Microsoft Office formats (DOCX, XLSX and PPTX) to reduce conversion issues.
• Improved handling of embedded media and OOXML-style layouts.

Final considerations

ODF 1.3 represented a significant advancement in terms of security and interoperability. ODF 1.4 adds usability improvements, more modern features, and better alignment with current office suite trends.

With an increasing number of governments and organisations adopting open standards, the evolution of ODF is crucial. The focus is not on competing with Microsoft; it’s about ensuring that your documents remain yours.

If you’ve ever wondered what those .odt, .ods, or .odp files are all about – or if you’ve stumbled across them and weren’t sure what to do – this post is for you.

.odt: The Open Document Text File

Think of .odt as the open counterpart to .docx. It’s the default file format for LibreOffice Writer. You can use it for everything from a quick grocery list to a dissertation.

What’s great about .odt is that it’s built on open standards. That means anyone can build software to read or write it without jumping through legal hoops. It also means you’re not tied to one company’s ecosystem, which is increasingly important when you think about long-term access to your own data.

Yes, you can open .odt files in Word – and yes, the formatting usually holds up pretty well. Not perfect, but usable.

.ods: Spreadsheets Without Strings Attached

Spreadsheets aren’t just for accountants anymore. Whether you’re managing a budget, tracking tasks, or planning a trip, you’re probably using rows and columns for something. .ods is the ODF version of .xlsx, and it’s handled by tools like LibreOffice Calc.

If you’re used to Excel, Calc will feel familiar enough. Basic formulas, charts, conditional formatting – it’s all there. Advanced Excel users might bump into limits (especially with macros or highly specific plugins), but for everyday work, .ods gets the job done.

And again, it’s open. Your data isn’t buried in a proprietary format you need a subscription to access five years from now.

.odp: Presentations Without PowerPoint

Then there’s .odp, the ODF format for presentations. It works like PowerPoint’s .pptx. You’ve got slides. You’ve got transitions. You’ve got bullet points. Even if you’re trying to build the next TED Talk with embedded video and flashy animations, it’s more than enough.

LibreOffice Impress opens and edits .odp files easily, and you can usually open them in PowerPoint too, though some visual effects might not translate perfectly. For most professional or academic presentations, it’s a reliable option – especially when you don’t know what software will be available on the receiving end.

Other File Types in the ODF Family

ODF isn’t limited to just text, spreadsheets, and slides. There are a few lesser-known formats worth mentioning:

• .odg – for vector graphics and diagrams. Think flowcharts, not Photoshop.
• .odf – confusingly, this one’s for formulas (as in math), used by LibreOffice Math.
• Templates like .ott (text), .ots (spreadsheets), and .otp (presentations) make it easy to standardize layouts and branding across documents.

These formats are all part of the same ecosystem. They’re modular, open, and designed to work well together.

Why It Matters

It’s easy to dismiss file formats as a technical detail, but they shape who controls access to your work. When you rely only on proprietary formats, you’re tied to that company’s tools, updates, subscriptions and limitations. You’re renting your own documents.

ODF flips that script. It’s not just a format – it’s a philosophy. One that says your work belongs to you, and you should be able to access it any time, on your terms.

If you’re already using open-source tools, chances are you’re already working in ODF whether you realized it or not. If not, it’s worth considering – especially if you want to keep your documents open, portable and future-proof.

A document format is a tool for sharing knowledge and, as such, should be as simple and accessible as possible in relation to the complexity of the document content itself. This remains true even when the format is based on an XML schema that is hidden from users when the document is displayed on screen.

Unfortunately, while an XML schema can be simple, it can also be unnecessarily complex, bloated, convoluted and difficult to implement without specific knowledge of its features. This is true even if the on-screen documents are identical. In this case, complexity is an intentional tactic used to lock users into a vendor, as is the case with the Microsoft 365 document format.

An XML schema comprises the structure, data types and rules of an XML document and is described in an XML Schema Definition (XSD) file. This tells the PC what to expect and checks that the data follows the rules. In theory, XML and XSD together form the basis of the concept of interoperability. However, in practice, an XML schema can be made so complex that it becomes a barrier rather than a bridge.

An “artificially complex” XML schema goes beyond the level of complexity needed to display even the most intricate content on screen. In fact, it is completely disconnected from the actual complexity of the content, to the extent that even a simple sentence such as “To be, or not to be, that is the question” becomes an inextricable sequence of tags that users cannot access.

This artificial complexity is characterised by a deeply nested tag structure with excessive abstraction, dozens or even hundreds of optional or overloaded elements, non-intuitive naming conventions, the widespread use of extension points and wildcards, the multiple import of namespaces and type hierarchies, and sparse or cryptic documentation.

In the case of the Microsoft 365 document format, the only characteristic not present is sparse or cryptic documentation, given that we are talking about a set of documents totalling over 8,000 pages. All the other characteristics are present to a greater or lesser extent, making life almost impossible for a developer trying to implement the schema.

To illustrate how this translates into a lock-in strategy, consider a railway system where the tracks are accessible to all, but the main train manufacturer imposes its own incredibly complicated control system. In theory, anyone could build a train compatible with the tracks, but the control system specifications are so convoluted that only the main train manufacturer can ultimately offer rail services.

The worst thing is that passengers don’t realise they are being held hostage by technical constraints that they cannot understand until ticket prices rise or the number of cities served declines. At this point, the main manufacturer can dictate its terms, which passengers are forced to accept.

This is very similar to what is happening in the world of information technology, where Microsoft is effectively forcing its customers to switch from Windows 10 to Windows 11 against their will. This switch has no technical justification and locks customers into using Windows 11 and Microsoft 365. This is because customers have completely ignored the problems that arise from using proprietary technologies.

If, over the years, the millions of Microsoft users who uncritically accepted a narrative that was credible to non-technical users but divorced from technological reality had taken a critical stance towards this monopoly, which would have raised doubts in any other sector, we would be in a very different situation today.

Instead, these users – including governments and supranational organisations – have allowed lock-in strategies, in which Microsoft 365’s artificially and unnecessarily complex XML document schema plays a fundamental strategic role, to become increasingly sophisticated and pervasive.

Therefore, if you are developing or choosing an XML-based system, bear in mind that complexity imprisons people, whereas simplicity and clarity set them free.

To write this article, I went beyond the limits of my technical knowledge, which is that of an advanced user who has studied standard formats and their characteristics in depth, to understand why standard formats – one of the pillars of digital sovereignty – and proprietary formats – their opposite, and one of the biggest obstacles to digital sovereignty – are not perceived as a problem by most PC users, who continue to use Microsoft’s proprietary formats and place the access and availability of their content in the hands of the US company.

To try to remedy this problem, I will try to explain as simply as possible, using non-technical language (which may shock developers, but this article is not aimed at them), some technical features of the Open Document Format (ODF), which make it the cornerstone of an open and vendor-independent ecosystem for office documents, defending the digital freedoms of all users and the governance of their content.

I will begin by explaining how to unpack an ODF file, which is nothing more than a set of XML files and other files (for images and videos) contained within a ZIP folder, in order to examine its internal components and, in particular, the content.xml file, which is the one that contains the body of the document (i.e., the user’s intellectual property).

The aim is not so much to assess conformity (compliance with specifications) and interoperability (the ability to exchange files consistently between tools), as these aspects will always be dealt with by specialists, but rather to understand the advantages for the user of the open and standard format over the closed and proprietary format (which is falsely standard, since it was approved by ISO/IEC in defiance of “their” definitions of standards).

For this reason, I will make a brief concluding digression on the characteristics of the OOXML (Office Open XML) format used by Microsoft Office and Microsoft 365, again to clarify to users the risks they face and the harm they do to themselves and other users when they use DOCX, XLSX and PPTX formats, as well as the ‘gift’ they are giving to Microsoft, to whom they are effectively entrusting the management and future of their content.

Analysing an ODF file

Take any document you have created with LibreOffice. For convenience, I recommend starting with a text document created with LibreOffice Writer, with the ODT extension. Before doing anything else, duplicate the file, because an error in the procedure could make it unreadable, and move the original to another folder.

Rename the copy, replacing the ODT extension with the ZIP extension, without deleting the dot. The file icon will become that of a compressed file. If it becomes white or empty, you have done something wrong or deleted the dot. Check all the steps until the icon becomes that of a compressed file.

At this point, right-click on the icon and select “unzip” or “expand” to extract the contents of the compressed file into a folder with the same name as the file without the extension.

The folder will contain the following items:

• the META-INF folder, which will contain the manifest.xml file
• the Thumbnails folder, which may contain the thumbnail.png file
• the content.xml file, which contains the body of the document
• the styles.xml file, which contains the style definitions
• the meta.xml file, which contains the file metadata (author, creation date, last modification date, etc.)
• the settings.xml file, which contains the application settings

Each XML file within an ODF document must comply with the RelaxNG XML schema, or REgular LAnguage for XML Next Generation, created by OASIS in 2001 and 2002, which is simpler – and therefore more accessible to non-technical users – than other XML schemas. The packaging rules are defined by the OpenDocument Packaging specifications.

In addition to schema validation, it must meet a number of conditions.

• Structural compliance: the elements of the ZIP and manifest.xml files
• Functionality compliance: all standard and optional functionality (metadata, styles, tables, graphics, etc.)
• Formula compliance: spreadsheet formulas must be compatible with OpenFormula semantics
• Security compliance: ODF profiles, encryption, digital signature

The manifest.xml file contained in the META-INF folder must list all the files in the ZIP file, with their media type:

<manifest:manifest xmlns:manifest=”urn:oasis:names:tc:opendocument:xmlns:manifest:1.0″>
     <manifest:file-entry manifest:full-path=”/” manifest:media-type=”application/vnd.oasis.opendocument.text”/>
     <manifest:file-entry manifest:full-path=”content.xml” manifest:media-type=”text/xml”/>
     <manifest:file-entry manifest:full-path=”styles.xml” manifest:media-type=”text/xml”/>
     <!– thumbnails, settings, etc. –>
</manifest:manifest>

Simply omitting a file or making an error in the description of its media type is enough to make the ODF file structurally non-compliant.

ODF: the importance of the content.xml file

To understand the user benefits of an open standard format such as ODF over a proprietary format, even one that is theoretically open such as OOXML, a quick analysis of the content.xml file of ODF files and its equivalent in OOXML files, which differs depending on the file type (and this alone is a sign that the development of OOXML did not take user needs into account at all, but focused on artificially increasing complexity), is sufficient.

Let’s take a first example, based on one of the most famous phrases in the history of world literature, namely “to be, or not to be, that is the question” uttered by the protagonist of William Shakespeare’s Hamlet.

The content.xml file of a text document containing only this sentence is 32 lines long: the first 18 provide references to all the standards used (such as X-Forms and MathML), list the fonts used in the document styles, and define the styles (in this case only one, given the length of the text and the absence of formatting).

The next 13 lines are as follows:

<office:body>
     <office:text>
          <office:forms form:automatic-focus=”false” form:apply-design-mode=”false”/>
          <text:sequence-decls>
               <text:sequence-decl text:display-outline-level=”0″ text:name=”Illustration”/>
               <text:sequence-decl text:display-outline-level=”0″ text:name=”Table”/>
               <text:sequence-decl text:display-outline-level=”0″ text:name=”Text”/>
               <text:sequence-decl text:display-outline-level=”0″ text:name=”Drawing”/>
               <text:sequence-decl text:display-outline-level=”0″ text:name=”Figure”/>
          </text:sequence-decls>
          <text:p text:style-name=”P1″>To be, or not to be, that is the question</text:p>
     </office:text>
</office:body>

The first lines define the body of the document and the fact that it is a text. The following lines are declarations that, in this case, do not add anything, but in other contexts would provide information about other elements of the document.

The key line is this: <text:p text:style-name=‘P1’>To be, or not to be, that is the question</text:p>, which defines a paragraph, declares its style (P1) and provides the content: To be, or not to be, that is the question. Clear and readable by any user, who now has the keys to access the document and manage its contents, i.e. the product of their brain.

Of course, more complex documents and contents would correspond to a more complex content.xml file, but always respecting the readability of the contents and the simplicity of the XML schema.

OOXML: what happens inside the file

Let’s see what happens in the case of the same document saved in DOCX format, closed and proprietary, and artificially complex. The file is called document.xml and not content.xml, and this – obviously – would not be significant if it were not a further sign of the complexity of the format, given that in the case of Excel the file is called workbook.xml and in the case of PowerPoint it is called slide1.xml, and so on.

The document.xml file of a text document containing only the phrase “To be, or not to be, that is the question” is 41 lines long: the first provides references to all the proprietary elements used (such as wordprocessingCanvas, VML and WordML), and all the subsequent lines relate to the content:

<w:body>
     <w:p xmlns:wp14=”http://schemas.microsoft.com/office/word/2010/wordml” wp14:paraId=”2DC08235″ wp14:textId=”776AF5CB”>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t xml:space=”preserve”>To be, or </w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t>not</w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t xml:space=”preserve”> to be, </w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t>that</w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t xml:space=”preserve”> </w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t>is</w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t xml:space=”preserve”> the question</w:t>
          </w:r>
     </w:p>
     <w:sectPr>
          <w:pgSz w:w=”11906″ w:h=”16838″ w:orient=”portrait”/>
          <w:pgMar w:top=”1440″ w:right=”1440″ w:bottom=”1440″ w:left=”1440″ w:header=”720″ w:footer=”720″ w:gutter=”0″/>
          <w:cols w:space=”720″/>
          <w:docGrid w:linePitch=”360″/>
     </w:sectPr>
</w:body>

Obscure and unreadable. I challenge any user to reconstruct a text of any complexity from an XML document like this, if the original file is damaged. In the case of ODF, we were able to reconstruct even documents of hundreds of pages, or presentations of dozens of slides, because the content was readable by any user, even non-technical ones.

Let’s try to imagine the size of the content.xml file and the document.xml file if, instead of Prince Hamlet’s sentence, there were all 5,566 lines of the entire tragedy, in the original version written by William Shakespeare. In this case, the difference speaks for itself: content.xml is 5,598 lines long (32 lines more than the text), document.xml is 93,289 lines long (87,723 lines more than the text).

File complexity as the new lock-in strategy

This file complexity is intentionally hidden from the user, who sees a normal-looking document on the screen and has no idea that they are writing a file on their hard drive or in the cloud that has characteristics very similar to those of the proprietary files used in the last century, which are unreadable without the software with which they were written.

A user who believes they have made significant progress in terms of digital sovereignty because they use a format they believe to be open and standard but which, on the contrary, is even worse than the binary formats of the 1900s – which were nothing more than the writing of what was in memory – because, being based on XML, it is the offspring of an algorithm that can be modified remotely with a routine update (as happens in reality, where the same document is written in DOCX format but with a completely different XML syntax each time, based on parameters known only to the vendor, i.e. Microsoft).

So, it is an even more closed and proprietary format than the binary formats it replaced in 2006. The latter, being the result of writing what was in memory to files, were predictable and could be emulated, while OOXML is unpredictable due to the algorithm, and therefore almost impossible to emulate without constant study of its many evolutions.

OOXML is a theoretically open and standard format, which in reality is closed and proprietary, and represents the latest evolution of the lock-in strategy that underpins all Microsoft products for individual productivity, defending an estimated turnover of over $25 billion per year, with an estimated net profit of over $20 billion per year (all figures are estimates, as analysts’ figures are no longer available and are probably lower than the actual figures).

Perhaps the time has come for supranational organisations, central and local governments, and probably also individual users, to open their eyes and take a simple step forward towards digital sovereignty, i.e. the governance of documents and their content independent of the commercial choices of a single company, by adopting ODF and abandoning OOXML.

The Open Document Format (ODF) is an open standard format for office documents, which offers a vendor-independent, royalty-free way to encode text documents, spreadsheets, presentations, and more.
However, to realise its potential, it is necessary to understand the concepts of compliance – the degree to which an implementation adheres to ODF specifications – and interoperability – the ability to exchange and view ODF files without loss of fidelity or functionality across different applications and platforms.

ODF is an XML-based file format that has been standardised by OASIS and ratified by ISO/IEC 26300. Milestones include:

• ODF 1.0 (2006): the initial version defining the basic document types: text (.odt), spreadsheet (.ods) and presentation (.odp).
• ODF 1.1 (2012): updates to formula specifications and accessibility improvements were made, but it was never submitted for standardisation.
• ODF 1.2 (2015): introduces digital signatures, RDF metadata, and OpenFormula for standardising spreadsheet calculations.
• ODF 1.3 (2020): an extension of security features, including improvements to encryption and import/export conventions, as well as a clarification of compliance clauses.

Each version has strengthened the role of ODF as a universal interchange format, ensuring that documents remain readable and editable in all programs, both now and in the future.

Definition of compliance

Compliance refers to the extent to which a given software implements the ODF standard. It comprises several levels:

1. Structural compliance: ensures that file archives contain the expected XML files (e.g. content.xml, styles.xml and meta.xml), in accordance with the ODF Packaging specifications.
2. Schema validation: verifies that the XML content matches the applicable ODF schemas (Relax NG or W3C XML Schema). This prevents a <draw:image> element, for example, from appearing where only text is permitted.
3. FeatuSecurity profilesre compliance: supports the required features (styles, tables, charts and metadata) and the correct implementation of the optional features required by the application (digital signatures, encryption and change tracking).
4. Formula compliance: for spreadsheets, adherence to OpenFormula specification ensures that formulas behave consistently across different applications.
5. Compliance statements and profiles: applications often declare their compliance levels (e.g. ODF 1.2 Part 1: OpenDocument Schema). Some define profiles, which are subsets of the full standard tailored to specific industries or workflows.

Non-compliant files risk becoming unreadable or displaying incorrectly in other applications. Validating ODF schemas and integrating compliance tools enables developers and users to guarantee the longevity and accuracy of documents.

The interoperability landscape

Even when two applications claim ODF compliance, disparities can arise.

• Rendering differences: variations in character substitution, line spacing or image placement can slightly alter the layout.
• Functionality differences: for example, an editor may support digital signatures, but implement them in a way that causes signatures to be rejected when files are exchanged.
• Use of extensions: some applications use proprietary extensions (e.g. custom XML blocks) that others do not recognise, which can result in data or content loss.
• Metadata management: different handling of document properties, such as author, version history or custom metadata, can hinder workflows.

To achieve strong interoperability, systematic testing is required.

1. Automated schema validation: tools such as ODF Validator can check thousands of files against ODF schemas in batches.
2. Feature compliance suites: OASIS provides test suites that cover every aspect of the ODF specification, including basic document elements and encryption profiles.
3. Round-trip testing: save a document in application A, open it in application B and save it again, then reopen it in application A to detect any differences.
4. Visual regression testing: use headless rendering engines (e.g. LibreOffice in server mode) to generate PDFs or bitmaps for pixel-level comparison.
5. Community reports: projects such as ODF Plugfest bring vendors together to exchange test files and submit interoperability reports.

Best practices for ensuring compliance and interoperability:

1. Adherence to the core standard: avoid proprietary extensions unless they form part of an agreed ODF profile.
2. Early and frequent validation: integrate schema and conformance testing into CI/CD pipelines for document-centric applications.
3. Prioritise OpenFormula: when creating a spreadsheet, use standard functions and avoid vendor-specific formula syntax.
4. Adopt the Flat ODF format: the Flat ODF format (.fodt, .fods and .fodp) stores the entire document in a single XML file, making it easier to compare, validate and process in scripts.
5. Document compliance statements: indicate the ODF version supported by the application, as well as the schema, encryption and signature parts.
6. Participate in plugfests and community testing: real-world feedback is valuable, so it is important to participate in interoperability events and contribute to public issue trackers.
7. Make smart use of metadata: use ODF metadata elements (e.g. dc:meta, RDF blocks) to ensure the consistency of document properties when transferring between tools.

Looking ahead: ODF 1.4 and beyond

Although ODF 1.3 has addressed many functional issues, the ecosystem continues to evolve.

• Accessibility improvements: better support for tagged PDFs, ARIA roles and semantic markup.
• Native cloud editing: harmonisation of ODF with collaborative protocols (e.g. WOPI and CMIS) to enable real-time co-authoring.
• Extended multimedia management: richer multimedia support is incorporated (e.g. video and embedded web components), while maintaining interoperability.
• Security profiles: standardisation of profiles for high-security environments (e.g. government or healthcare), combining encryption, signatures and content redaction.

Conclusion

ODF compliance and interoperability are fundamental to document longevity, workflow resilience, and user trust. By adhering to ODF schemas, testing across multiple applications and adopting community best practices, organisations can safeguard their content against vendor lock-in and format degradation. As it continues to mature, ODF is set to remain the foundation of open, accessible and durable office documents.