Bug 168042 - FILEOPEN DOCX: below spacing of 10pt (or 0pt, or 8pt) missing from default paragraph
Summary: FILEOPEN DOCX: below spacing of 10pt (or 0pt, or 8pt) missing from default pa...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: lowest trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX-Paragraph
  Show dependency tree / graph
 
Reported: 2025-08-21 14:47 UTC by Justin L
Modified: 2025-08-21 14:47 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
belowSpacing_withoutPPrDefault.docx: styles.xml has comment out w:pPrDefault (8.42 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2025-08-21 14:47 UTC, Justin L 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Justin L 2025-08-21 14:47:37 UTC 
Created attachment 202434 [details]
belowSpacing_withoutPPrDefault.docx: styles.xml has comment out w:pPrDefault

When MS Word 2010 opens up test.docx (attachment 157274 [details] from bug 129627), the default paragraph style (and the document's contents) have a 10pt below spacing. In LO, this is zero.

LO opens it fine if it is first round-tripped by MS Word.

After the round-trip, styles.xml contains
<w:docDefaults>
  <w:pPrDefault>
    <w:pPr>
      <w:spacing w:after="200" w:line="276" w:lineRule="auto"/>
    </w:pPr>
  </w:pPrDefault>
</w:docDefaults>

Before the round-trip, there is no w:spacing definition at all, nor is there a w:pPrDefault defined.

And that ends up being the difference. If no pPrDefault is defined, then MS Word 2010 uses its program-default of 10pt below spacing. If there is a pPrDefault defined (even if it is empty), then a 0pt below spacing is used.

Sadly, MS Word 2024 uses a program default of 8pt, and MS Word 2003 uses 0pt. So there can be no "right" answer here. Nor does the compatiblityMode level seem to make any difference...

OK - I'll still create this bug report as a reference, but it is not actionable. Our current behaviour is the best course of action IMHO.