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]
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.
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.
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?
(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.
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.
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.
At line assertXPath(pXmlSettings, "/w:settings/w:compat/w:compatSetting[1]", "val", "15"); // compatible with 2003/2016/2019 I supose there should be 2013/2016/2019
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.
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.
Thanks for the fix, Justin. Is there anything more needed or can this be closed?
(In reply to Buovjaga from comment #10) > Thanks for the fix, Justin. Is there anything more needed or can this be > closed? Several bugs are still open!?
(In reply to Thomas Lendo from comment #11) > (In reply to Buovjaga from comment #10) > > Thanks for the fix, Justin. Is there anything more needed or can this be > > closed? > Several bugs are still open!? Looks like I missed that this is also a META bug.
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.