Created attachment 143622 [details] margin.odt: hand-modified to remove one of each pair of margins. The problem in tdf#118521 can be reproduced for ODT as well. If the paragraph defines only one of fo:margin-top or fo:margin-bottom, the undefined one ought to assume the value of the defined style (MyStyle in this case). However, it reverts to the style:default-style value instead. (The same thing is true for margin-left and margin-right.) Paragraph 1 <style:style style:name="P1" style:family="paragraph" style:parent-style-name="MyStyle"><style:paragraph-properties fo:margin-top="0cm" fo:margin-right="0cm" Paragraph 2 <style:style style:name="P2" style:family="paragraph" style:parent-style-name="MyStyle"><style:paragraph-properties fo:margin-bottom="0cm" fo:margin-left="0cm" MyStyle <style:style style:name="MyStyle" style:family="paragraph" style:parent-style-name="Standard" <style:paragraph-properties fo:margin-top="0.9cm" fo:margin-bottom="0cm" fo:margin-left="0cm" fo:margin-right="1.9cm" Document Defaults <style:default-style style:family="paragraph"><style:paragraph-properties fo:margin-top="4cm" fo:margin-bottom="3cm" fo:margin-left="2cm" fo:margin-right="5cm" To reproduce. 1.) open the ODT file and notice that both paragraphs are set to MyStyle. 2.) look at the paragraph properties. Notice that the spacing that is not zero matches the Docuemnt Defaults, not the MyStyle settings. Expected results: Paragraph 1 has no upper/lower space and not left/right space. Paragraph 2 has a top margin of .9 and a right margin of 1.9 Actual results: Paragraph 1 has "Before text" 2cm and "Below paragraph" 3cm. Paragraph 2 has "After Text" 5cm and "Above paragraph" 4cm
Bibisect-43all suggests inherited from OOo. Assuming this gets fixed, the commit for docx in bug 118521 can be reverted (since it starts hard-coding paragraph properties where they didn't exist before).
Confirmed. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 860a9daf2b45942a4b10ff22d36aa3fe29be19f4 CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on July 14th 2018
(In reply to Justin L from comment #1) > Bibisect-43all suggests inherited from OOo. > > Assuming this gets fixed, the commit for docx in bug 118521 can be reverted > (since it starts hard-coding paragraph properties where they didn't exist > before). It seems, LibreOffice UI does the same. It's possible that not just because of performance, but it's better to handle related properties in a group for consistent UI. For example, we want to set all margins with direct paragraph formatting, but we cannot, if the value is the same as in the parent-style. LibreOffice uses this grouped approach on the other properties, too, and somewhere doesn't not (and there we need to play the following: to modify the attribute to a different value, and reset it to the default for overwriting the inherited value with the same, but direct formatted value for to get the required template settings). Also this is related to the standard, too. It seems, we need to check CSS2 first, according to the OpenDocument standard: https://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#margin-top CSS has got some grouping for these properties, but it is more flexible, than OpenOffice.org style handling, and maybe it's different in this case.
Ie. OpenDocument standard refers the previous XLS section: "20.202 fo:margin-top See §7.10.1 of [XSL]. If this attribute is contained in a <style:paragraph-properties> element, its value may be a percentage that refers to the corresponding margin of a parent style. In the OpenDocument XSL compatible namespace, the fo:margin-top attribute does not support the inherit value."
(and it's worth to analyze ODT compatibility issues with MSO and Google Docs etc., too.)
Created attachment 143632 [details] margin.odt.googleDocs.pdf: looks like current LO - no inheritance, but uses doc defaults (In reply to László Németh from comment #4) > "20.202 fo:margin-top I did look in the documentation first, but never noticed this tag - got hung up in the earlier margin-top entries. Likely code area is this line in unostyle.cxx SwXAutoStyleFamily::insertStyle > aSet.SetParent(&m_pDocShell->GetDoc()->GetDfltTextFormatColl()->GetAttrSet());
Created attachment 143633 [details] margin.odt.wordOnline.pdf: from Word online 16.0.10715.32654 - inherits from MyStyle
Seems clear to me that this is NotABug after all. I'll do some verification on related bug 118521 and add left/right margin support for docx if needed.
(In reply to Justin L from comment #8) > Seems clear to me that this is NotABug after all. I'll do some verification > on related bug 118521 and add left/right margin support for docx if needed. Thanks for these and for analyzing the problem.