Bug 131304 (DOCX-compatibilityMode-15) - [META] MS Word compatibilityMode = 15
Summary: [META] MS Word compatibilityMode = 15
Status: NEW
Alias: DOCX-compatibilityMode-15
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.0 target:7.5.0
Keywords:
Depends on: 76022 104254 133522 137548 142404 143793 143899 143934 157637 158658 160068 77417 77794 106339 106742 115719 116256 119760 119908 121318 123116 128197 129730 131121 135343 137850 139336 144804 145554 150192 153964 156078 158333 158419 158776 159032 159034 159085 159102 160049
Blocks: DOCX OOXML-Transitional-2010vs2013
  Show dependency treegraph
 
Reported: 2020-03-12 09:53 UTC by Justin L
Modified: 2024-03-06 16:54 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
13130_DOCisC11.diff: .doc: provide compatibilityMode value for .docx (2.54 KB, patch)
2021-05-24 13:32 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin L 2020-03-12 09:53:46 UTC
There are some compatibility changes in MS Word 2013 that seem to have no documentation, but can be tracked down to acting differently in compatibility mode verses “native” mode. A compatSetting identifies the compatibility mode.

Currently LO round-trips an existing value, but does not write anything for a new docx file, effectively setting it to Word 2007 mode. This meta bug is intended to track bugs related to compatibilityMode and evaluate when it would be appropriate to start writing compatibilityMode = 15 (Word 2013/2016) for new documents.


We learn from https://docs.microsoft.com/en-us/openspecs/office_standards/ms-docx/90138c4d-eb18-4edc-aa6c-dfb799cb1d0d ...

name:  compatibilityMode
uri:   http://schemas.microsoft.com/office/word
val:   An ST_UnsignedDecimalNumber that specifies the feature set to use when editing the document.

Valid values and their meanings are:
11: Use features specified in MS-DOC.

12: Use word processing features specified in ECMA-376. This is the default. [Word 2007]

14: Use word processing features specified in ISO/IEC29500-1:2016 and ISO/IEC29500-4:2016 as well as those specified in this document with the exception of the features defined by the following elements and/or parts; commentsExtended, people (enumeration), collapsed, docId, repeatingSection, repeatingSectionItem, chartTrackingRefBased, commentsEx, people (element), color), dataBinding, appearance, webExtensionLinked, and webExtensionCreated. [Word 2010]

15: Use word processing features specified in ISO/IEC29500-1:2016 and ISO/IEC29500-4:2016 as well as those specified in this document. [Word 2013 and 2016]
Comment 1 Justin L 2020-03-13 07:34:58 UTC
https://www.howtogeek.com/256269/what-is-compatibility-mode-in-microsoft-office/

What Is Compatibility Mode?

Modern versions of Microsoft Office have introduced new features that aren’t compatible with older versions of Microsoft Office. Modern versions of Word, Excel, and PowerPoint also handle document formatting a bit differently from older versions.

When you create a new document in Office 2013 or 2019, it’s created as a modern document with access to all these new features and the latest formatting styles. However, when you open a document CREATED with Office 2010 or older, it’s opened in Compatibility Mode to ensure it looks the same in 2013 or 2019 as it does in the old versions.

Compatibility Mode also DISABLES access to new features. For example, if someone creates a document in Word 2007 and you open it in Word 2016, Word 2016 will PREVENT YOU from using features that Word 2007 wouldn’t understand. You can then save the document and send it back to the person who sent it to you without running into problems. If Word 2016 let you use modern features, the other person may not be able to view the entire document.

This mode is intended to ensure users of different versions of Microsoft Office can continue working together and documents created with older versions of Office won’t look any different when they’re opened in future versions of Office.

The exact features that are disabled in Compatibility Mode depend on which Office application you’re using and which type of Compatability Mode a document is using. For example, if you’re using Word 2016 and you open a document that’s in Word 2010 Compatibility Mode, you won’t be able to use Apps for Office or embed online videos. These features require Word 2013 or newer. Microsoft offers a complete list of Word features unavailable in Compatability Mode.
Comment 2 Commit Notification 2020-03-13 08:59:49 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/6bc01f234de9a3c5abc00253fed8dc691320fd3b

tdf#131304 writerfilter: cache Word compatibilityMode

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 3 Mike Kaganski 2020-03-13 09:32:21 UTC
Does taking into account the document's original compatibility mode make sense? Writing it back implies that we also write the data according to that mode. Do we implement writing things differently for those levels? When someone edits a DOCX in LO, one sees the data as it was imported; and expects that it shows in Word identically. There are two possible ways to *approach* that:

1. We stick to a chosen compatibility mode, and write everything accordingly;
2. We implement export methods for each possible compatibility mode.

In any case, we likely should have flexible *import* code taking the original mode into account - to read it as it was in original document; but do we want to make the nightmare of supporting export zoo?
Comment 4 Justin L 2020-03-13 11:24:45 UTC
(In reply to Mike Kaganski from comment #3)
Hi Mike. Yes, this is exactly the kind of conversation we want to have here. I think the key here is understanding comment 1. From my understanding, ultimately compatibilityMode has ALMOST NOTHING to do with layout, but mostly with allowing advanced options in the UI.

> Does taking into account the document's original compatibility mode make
> sense?
Absolutely. It basically is required in order to fulfil the intention of being nice to the "oldest version user". And we have been doing that (round-tripping the existing compat mode) since 2014-ish.

> Writing it back implies that we also write the data according to that
> mode. Do we implement writing things differently for those levels?
Yes, but the impact is minimal because there are currently only two cases where export differentiates. When we don't it results in bug reports. However, there are VERY few current exceptions based on compatibilityMode. The ones I could find in the code are noted in the "blocked" section of this bug report.

> When someone edits a DOCX in LO, one sees the data as it was imported; and
> expects that it shows in Word identically. There are two possible ways to
> *approach* that:
> 1. We stick to a chosen compatibility mode, and write everything accordingly;
That would break the spirit of compatibility mode - to overwrite with a NEWER mode. In a shared document context, that puts the user of old Word 2007 at a disadvantage, because now new MS Word will start to add features that old Word 2007 can't understand. Of course, we could revert and say that we will only write in the oldest 2007 mode from now on, but I don't think you are suggesting that...
 
> In any case, we likely should have flexible *import* code taking the
> original mode into account - to read it as it was in original document.
Nothing new here. We already have to handle importing every possible compatibilityMode. But there hasn't been much in the past 7 years.

> 2. We implement export methods for each possible compatibility mode,
> but do we want to make the nightmare of supporting export zoo?
We already have to do this too - since we round-trip the mode.

Considering that the mode number (15) hasn't changed since 2013, there is no nightmare situation here. The nightmare could come at the NEXT revision - and at that time we could decide to NOT round-trip the next version number, but replace it with the old 15 that we support - which is exactly the intention of this flag.
Comment 5 Commit Notification 2020-03-16 13:01:31 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/53f099c842d39266a0b4786a1af3db5628746634

tdf#131304 .docx: provide default compatibilityMode value

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Commit Notification 2020-03-18 08:29:52 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f25985c55541cbbc9a4fc79e660592d3d0485196

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

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 7 BogdanB 2020-08-13 09:54:36 UTC Comment hidden (obsolete)
Comment 8 Justin L 2021-05-24 13:32:51 UTC
Created attachment 172296 [details]
13130_DOCisC11.diff: .doc: provide compatibilityMode value for .docx

I think we are still missing recognizing that a DOC file should export as compatibilityMode=11, not 15, when saved in DOCX format.

Ah yes, I thought I had dealt with that already - but I abandoned it. https://gerrit.libreoffice.org/c/core/+/90437

At the time, there seemed to be very little layout-related stuff, but more layout is coming into play. So perhaps it wasn't a bad idea after all.
Comment 9 Commit Notification 2022-06-29 23:00:09 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a7e0a5a6d0054483d3ed5a753bbba2e8ab599e90

tdf#131304 .doc: provide compatibilityMode value for .docx

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Buovjaga 2022-07-03 13:00:20 UTC Comment hidden (obsolete)
Comment 11 Thomas Lendo 2022-07-03 13:12:47 UTC Comment hidden (obsolete)
Comment 12 Buovjaga 2022-07-03 13:29:21 UTC Comment hidden (obsolete)
Comment 13 Justin L 2023-10-11 18:18:46 UTC
commit e66ddcd4b66923bc835bd7c5f5c784a809a420a2
Author: Michael Stahlon Fri Feb 17 12:10:38 2023 +0100
    tdf#137883 sw: DOCX export: compatibilityMode=12 for ECMA 376 1st ed.