fix(docx): emit settings.xml so Word does not use Compatibility Mode - #49
Merged
Conversation
Opening the export in Word 16.111.2 for macOS showed "Compatibility Mode" in the title bar and reported accessibility as unavailable. Without a settings part declaring compatibilityMode, Word falls back to the 2007 content model. Adding word/settings.xml with compatibilityMode 15 (Word 2013+), its content type and its relationship clears both. Confirmed on the same machine: the title bar is now the filename alone and accessibility reports "Good to go", with the rendered content unchanged. Found by the first real-hardware check of the DOCX writer; every earlier gate was structural and could not have seen this.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the DOCX exporter to emit a word/settings.xml part (and wire it into the package) so Microsoft Word opens generated documents in the modern content model instead of “Compatibility Mode”.
Changes:
- Add
word/settings.xmlcontaining aw:compatSettingforcompatibilityMode(w:val="15"). - Add the corresponding relationship in
word/_rels/document.xml.relsand content type override in[Content_Types].xml. - Extend the DOCX unit test to assert the presence/value of the settings part.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+562
to
+564
| rels.push_str( | ||
| "<Relationship Id=\"rIdSettings\" Type=\"http://schemas.openxmlformats.org/officeDocument/2006/relationships/settings\" Target=\"settings.xml\"/>", | ||
| ); |
Comment on lines
+1295
to
1304
| // Regression: without this part Word opens the document in Compatibility Mode. | ||
| assert!( | ||
| unzip(&bytes, "word/settings.xml") | ||
| .unwrap() | ||
| .contains("w:name=\"compatibilityMode\" w:uri=\"http://schemas.microsoft.com/office/word\" w:val=\"15\""), | ||
| "settings.xml compatibilityMode" | ||
| ); | ||
| assert!(unzip(&bytes, "[Content_Types].xml").is_some()); | ||
| assert!(unzip(&bytes, "_rels/.rels").is_some()); | ||
| assert!(unzip(&bytes, "word/_rels/document.xml.rels").is_some()); |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found by the first real-hardware check of the DOCX writer — every gate so far was structural and could not have seen this.
Symptom
Opening a v0.7.0 export in Word 16.111.2 for macOS:
P3_DOCX출력 - Compatibility ModeAccessibility: UnavailableThe document itself was fine — no repair dialog, correct heading sizes, correct colspan/vMerge tables. But Compatibility Mode means Word is applying the 2007 content model and disabling newer layout behaviour.
Cause
The package had no
word/settings.xml. With no part declaringcompatibilityMode, Word assumes the oldest mode rather than the current one.Fix
Emit
word/settings.xmlwithcompatibilityMode15 (Word 2013+), plus its[Content_Types].xmloverride and its relationship.Verification
Re-opened the regenerated file on the same machine:
P3_DOCX출력 - Compatibility ModeP3_DOCX출력UnavailableGood to goThe unit test now asserts the part and its
compatibilityModevalue, so this cannot silently regress.scripts/check.shgreen.Note on the wider verification
This PR closes the last item outstanding from the v0.7.0 DOCX work. Word real-open is now confirmed for a heading/list/table document and for a merged-cell table document: both render correctly with no repair dialog.