tdf#131304 .docx: flag new files as MS Word 2019 native mode

compatibilityMode = 15: [Word 2013/2016/2019]

Up till now, documents that were exported into the docx format
were treated by default as native Word 2007 format,
since no compatibilityMode setting was provided.

(Don't worry, we still round-trip existing older values.
This patch only affects non-docx >>= .docx export.)

Ultimately, this change is for the benefit of MS Word.
It has no practical effect for LO.

NOTE: This patch depends on previous
commit 53f099c842d39266a0b4786a1af3db5628746634
which sets an appropriate value for existing .docx files.

This scary change shouldn't actually be all that scary,
since we already round-trip native 2019 files,
without any complaint from Word or our users.

The biggest change is that Word 2010 users might not be able
to open NEW files perfectly. But Microsoft has already been doing
that to them since 2013. By the time LO 7.0 hits stable version,
it will have been months since 2010 has reached end-of-life.
The vast majority of documents will still open perfectly for them.
Plus, if a Word 2010 user does modify our new document,
we will drop back down to their level.

A nice, clear explanation of what compatibilityMode does is at
howtogeek.com/256269/what-is-compatibility-mode-in-microsoft-office/

The MAIN CHANGE is that MS WORD has been DE-ACTIVATING features
when it notices that it is SHARING the document with
OLD_VERSION users. So Word is limiting what it will do
for the BENEFIT OF THE OTHER USER while collaborating.

There are a few instances where layout is affected by
compatiblityMode. For example, tdf#123116 wants compat=15
so that Word will nicely layout an oversized table-row.
tdf#131121 wants it too.
By changing to compat=15, we can help Word take advantage
of some fixes since docx 1.0, and avoid having to write
new logic to export to old formats as well as new.

Unfortunately, documentation on what layout changes are expected
has not been identified yet. But in 7 years we should have
run into most of them already... well maybe no.

Change-Id: I1ce016618a680b9842fa6828c9e87cc6b677a557
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90455
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit f25985c55541cbbc9a4fc79e660592d3d0485196)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90920
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

1 files changed, 3 insertions, 0 deletions

diff --git a/writerfilter/source/dmapper/DomainMapperTableHandler.cxx b/writerfilter/source/dmapper/DomainMapperTableHandler.cxx
index a0b214a76555..3031516fd445 100644
--- a/writerfilter/source/dmapper/DomainMapperTableHandler.cxx
+++ b/writerfilter/source/dmapper/DomainMapperTableHandler.cxx
@@ -584,6 +584,9 @@ TableStyleSheetEntry * DomainMapperTableHandler::endTableGetTableStyle(TableInfo
 
         // tdf#106742: since MS Word 2013 (compatibilityMode >= 15), top-level tables are handled the same as nested tables;
         // the default behavior when DOCX doesn't define "compatibilityMode" option is to add the cell spacing
+
+        // Undefined should not be possible any more for DOCX, but it is for RTF.
+        // In any case, continue to treat undefined as version 12 during import.
         sal_Int32 nMode = m_rDMapper_Impl.GetSettingsTable()->GetWordCompatibilityMode();
 
         if (((nMode < 0) || (0 < nMode && nMode <= 14)) && rInfo.nNestLevel == 1)