In LibreOffice development, there are many cases where you want to validate some documents against standards: either Open Document Format (ODF) or MS Office Open XML (OOXML). Here I discuss how to do that.

Update: Article updated to reflect that odfvalidator 0.13.0 has just released.

Open Document Format (ODF) Validation

ODF is the native document file format that LibreOffice and many other open source applications use. It is basically set of XML files that are zipped together, and can describe various aspects of the document, from the content itself to the way it should be displayed. These XML files have to conform to ODF standard, which is presented in XML schemas. The latest version of ODF is 1.4, which is yet to be implemented in LibreOffice.

You can find more about ODF in these links:

• Wikipedia – OpenDocument
• Open Document Format for Office Applications (OpenDocument) TC

There are various tools to do the validation, but the preferred one is the ODF Toolkit Validator:

• ODF Toolkit website > ODF Validator 
• ODF Toolkit on Github

Compiled binaries of ODF Toolkit can be downloaded from the above Github project:

• odftoolkit-0.13.0-bin.zip

Then, you can use the ODF validator this way:

$ java -jar odfvalidator-0.13.0-jar-with-dependencies.jar test.odt

You may also use the online validator, odfvalidator.org, to do a validation.

Online odfvalidator tool

Please read this disclaimer before using:

This service does not cover all conformance criteria of the OpenDocument Format specification. It is not applicable for formal validation proof. Problems reported by this service only indicate that a document may not conform to the specification. It must not be concluded from errors that are reported that the document does not conform to the specification without further investigation of the error report, and it must not be concluded from the absence of error reports that the OpenDocument Format document conforms to the OpenDocument Format specification.

Office Open XML (OOXML) Validation

MS Office Open XML (OOXML) is the native standard for Microsoft documents format. It is also a set of XML files zipped together, and conform to some XML schemas.

You can find out more about OOXML here:

• Wikipedia – Office Open XML

There are tools to do the validation, and the one is used in LibreOffice is Office-o-tron. One can use it with below command to validate an example file, test.docx:

$ java -jar officeotron-0.8.8.jar ~/test.docx

Office-o-tron can be downloaded from dev-www.libreoffice.org server of LibreOffice, and this is currently the latest version:

• Office-o-tron 0.8.8 Jar file

It is worth noting that Office-o-tron can be also used to validate ODT files.

Extensions to ODF Standard

To go beyond the current ODF standard, new features are sometimes introduced as “ODF extensions”, then are gradually added to the standard. You can read more in TDF Wiki:

• ODF > ODF Extensions > Why does LibreOffice save extended ODF by default?

In these cases, you may see validation errors for such extensions. For example:

test.odt/styles.xml[2 …

Happy new year 2026! I hope that this year will be great for you, and the global LibreOffice community, and the software itself! I hereby discuss the past year 2025, and the outlook for 2026 in the development blog.

At The Document Foundation (TDF), our aim is to improve LibreOffice, the leading free/open source office suite that has millions of users around the world. Our work is community-driven, and the software needs your contribution to become better, and work in a way that you like.

My goal here, is to help people understand LibreOffice code easier via EasyHacks and tutorials, and eventually participate in LibreOffice core development to make LibreOffice better for everyone. In 2025, I wrote 14 posts around LibreOffice development in the dev blog (4 of them are unpublished drafts).

Outlook For the New Year

Focus of the development blog for 2026 in this blog will be:

• Introducing new EasyHacks
  • Using new C++20 constructs
  • Difficulty Interesting EasyHacks
• Describing user interface creation with VCL
  • VCL weld mechanism
  • Various weld widgets
• Describing UNO Components

You can provide feedback simply by leaving a comment here, or sending me an email to hossein AT libreoffice DOT org.

We provide mentoring support to the individuals who want to start LibreOffice development. You are welcome to contact me if you need help to build LibreOffice and do some EasyHacks via the above email address. You may also refer to our Getting Involved Wiki page:

• TDF Wiki: Getting Involved in LibreOffice Development

Let’s hope a better year for LibreOffice (and the world) in 2026.

After submitting a patch to LibreOffice Gerrit, one has to wait for the continuous integration (CI) to build and test the changed source code to make sure that the build is OK and the tests pass successfully. Here we discuss the situation when one or more CI builds fail, and how to handle that.

Why Build and Test on CI?

After you submit code to LibreOffice Gerrit, reviewers have to make sure that it builds, and the tests pass with the new source code. But, it is not possible for the reviewers to test the code on each and every platform that LibreOffice supports. Therefore, Jenkins CI does that job of building and testing LibreOffice on various platforms.

This can take a while, usually 1 hour or so, but sometimes can take longer than that. If everything is OK, then your submission will get     Verified +1    .

CI Platforms for LibreOffice

Currently, these are the platforms used in CI:

• Linux / GCC:  gerrit_linux_gcc_release
• Linux / Clang: gerrit_linux_clang_dbgutil
• Android Viewer: gerrit_android_x86_64 and gerrit_android_arm
• Windows: gerrit_windows_wsl
• macOS: gerrit_mac

Some of the tests are more extensive, for example Linux / Clang also performs additional code quality checks with clang compiler plugins. Also, UITests are not run on each and every platform.

LibreOffice CI uses Jenkins

Why Failures Happen and How to Fix?

There can be multiple reasons for why a CI build fails, and give your submission    Verified -1   . These are some of the reasons, and depending on the reason, solution can be different.

1. Your code’s syntax is wrong and compile fails

In this case, you should fix your code, and then submit a new patch set. You have to wait again for a new CI build.

2. The code’s syntax is OK, but it is not properly formatted

You should refer to the below TDF Wiki article and use clang-format tool to format your code properly.

• TDF Wiki – clang-format

3. Your code’s syntax is OK, but it logically not OK and fails some tests.

In this case, you should try fixing your code logic, and run the tests that fail and make sure they pass. After that, you may send a new patch set and wait for a new CI build.

4. Your code’s syntax and logic is OK, but some machine fails for other reasons like their disk being full or other software/hardware failures or hiccups

In this case, usually resuming the build can be a good option. You may ask on #libreoffice-dev or #tdf-infra IRC rooms for such a resume, or request access, if you submit many patches.

Resume build in LibreOffice CI

5. Your code’s syntax and logic is OK, but there are issues from other patches.

In this case, intervention from other LibreOffice developers is needed. Informing people on #libreoffice-dev can help, and then you have to re-base your submission in case new patches fix the build issue.

Final Notes

The best way to know the reason of the build failure is to look into …

In LibreOffice C++ code, there are many cases where developers want to use string literals in their code. If these are messages in the graphical user interface (GUI), they should add them to the translatable messages. But, there are many cases where the string literals has nothing to do with other languages, and there will not be any further translations. In these cases, enumarray is helpful. Although enumarray can be used beyond string literals, for any kind of data.

Using Symbolic Constants

In old C code, using #define was the preferred way one could give a name to a string literal or other kinds of data. For example, consider this code:

const char[] FRAME_PROPNAME_ASCII_DISPATCHRECORDERSUPPLIER = "DispatchRecorderSupplier";
const char[] FRAME_PROPNAME_ASCII_ISHIDDEN = "IsHidden";
inline constexpr OUString FRAME_PROPNAME_ASCII_LAYOUTMANAGER = "LayoutManager";
const char[] FRAME_PROPNAME_ASCII_TITLE = "Title"_ustr;
const char[] FRAME_PROPNAME_ASCII_INDICATORINTERCEPTION = "IndicatorInterception";
const char[] FRAME_PROPNAME_ASCII_URL = "URL";

And also, the relevant states:

#define FRAME_PROPHANDLE_DISPATCHRECORDERSUPPLIER 0
#define FRAME_PROPHANDLE_ISHIDDEN 1
#define FRAME_PROPHANDLE_LAYOUTMANAGER 2
#define FRAME_PROPHANDLE_TITLE 3
#define FRAME_PROPHANDLE_INDICATORINTERCEPTION 4
#define FRAME_PROPHANDLE_URL 5

Although this C code still works in C++, it is not the desired approach in modern C++.

Using enumarrays

In modern C++ code, you can use enumarry from o3tl library in LibreOffice. The above code becomes:

enum class FramePropNameASCII
{
    DispatcherRecorderSupplier,
    IsHidden,
    LayoutManager,
    Title,
    IndicatorInterception,
    URL,
    LAST=URL
};

And also, the string literal definitions:

constexpr o3tl::enumarray<FramePropNameASCII, OUString> FramePropName = {
    u"DispatchRecorderSupplier"_ustr,
    u"IsHidden"_ustr,
    u"LayoutManager"_ustr,
    u"Title"_ustr,
    u"IndicatorInterception"_ustr,
    u"URL"_ustr
};

Why an enumarray?

The names are much more readable, as they do not have to be ALL_CAPPS, as per convention for symbolic constants in C. Their usage is also quite easy. For example, one can use [] to access the relevant string literal:

- xPropSet->getPropertyValue( FRAME_PROPNAME_ASCII_LAYOUTMANAGER ) >>= xLayoutManager;
+ xPropSet->getPropertyValue( FramePropName[FramePropNameASCII::LayoutManager] ) >>= xLayoutManager;

Final Notes

In LibreOffice, enumarrays are not limited to string literals, and they can be used with other data. This task is tdf#169155, and if you like, you may try finding some instances in the code and modernize it using enumarrays.

To learn more about LibreOffice development, you can refer to TDF Wiki. You may follow this blog to read about EasyHacks, tutorials and announcements related to LibreOffice development.