Gabor Kelemen

Having your Office suite crashing is rather annoying, but crashing while opening or saving files is unsolvable for end users. The upstream LibreOffice project regularly runs testing against this on master - but is it possible to do it on stable branches maintained for customers? In this talk I'll introduce the set of test files and upstream scripts, and show how we use them to deliver added stability of LibreOffice for our customers.

As we know LibreOffice is an editor built around the feature set of ODF standard. When it comes to interoperability with other formats, notably OOXML, this causes another interesting source of problems: there are features available in the editor that might not be available in the counterpart product and consequently neither in OOXML format. The result might be loss of work time: the user assumes if she saves her carefully crafted document in OOXML it will be retained. In some unlucky cases this might not be true because of differences between the LO feature set and the file format preferred by the user or her peers.

My proposed solution to this is a small, simple and gradually extensible one: let's offer a configuration key that might be turned on by system administrators and this in turn would disable elements of the LibreOffice UI that offer features not available in the OOXML file format, or set different defaults in certain situations.