Created attachment 104048 [details] sample file Steps: 1) open attached file 2) in the first frame, you'll find a paragraph with line spacing of 120% proportional, but ms word has it as single. Tested on 4.3.1 on Linux and master on Windows.
Created attachment 104049 [details] Word 2013 VS LibO 4.3.1
same issue on 4.4.0.0.alpha0+ Build ID: 8dc2ab47b9e5ef0ff381575195a36ceec8789ef1 TinderBox: Win-x86@42, Branch:master, Time: 2014-08-02_23:22:41
Hello, I get similar problem if I open attachment 74088 [details] from bug 60187, save it as docx and open the docx.
Three different recent versions manage to get this three different ways 4.3.5.2: Proportional 120% 4.4.0.2: At least 0.17" 4.5 master: At least 12pt (after a mysterious long pause on startup with no CPU use)
Possibly the same as bug 86371 but would need further investigation to be sure
Frame appears only from 3.5.x, so not inherited from OO, and also not a regression, because it never worked fine.
Migrating Whiteboard tags to Keywords: (filter:docx)
So Word has the 'Text Body' paragraph style as 3pt before, 3pt after, and single line spacing, while LO has it as 3pt before, 3pt after, and atleast 12pt line spacing. This is the xml code for the style and its parent style and in neither is the w:line attribute of <w:spacing> set. <w:style w:type="paragraph" w:customStyle="1" w:styleId="TableText"> <w:name w:val="Table Text" /> <w:basedOn w:val="BodyText" /> ... <w:pPr> ... <w:spacing w:before="60" w:after="60" /> ... </w:pPr> ... </w:style> <w:style w:type="paragraph" w:styleId="BodyText"> ... <w:pPr> <w:spacing w:after="120" /> </w:pPr> ... </w:style> Justin, Mike: thoughts?
Dear Serdar Oktay TUNÇ, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
(In reply to Matthew Francis from comment #4) > 4.4.0.2: At least 0.17" Well, usually it says at least 0.12, but very occasionally I've seen .17 and then after a while it will report .12 instead. Anyway, the change from 120% was a 4.4 commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=c12a78e42e1cbaaf4ea021c82acbec5ea177b1f6 The setting comes from the "Text Body" paragraph style, which is a built-in style so probably related to StyleSheetTable_Impl::SetPropertiesToDefault.
Created attachment 143270 [details] tdf82175_noStyleInheritance.docx: simple, but problematic, problem document The problem with these documents is that the builtin style Text Body (Body Text in MSO) should not be basedOn anything, but in LO it is basedOn "Default" and Default is correctly using the modified value of "atLeast 12". LO 5.3 commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=b79b5e0df6dc5a0ba18054b0503d6fa804b69f02 changed parentless built-in styles to "Standard" (instead of whatever they inherited from in LO), but this document says that they should inherit from -none- instead. That makes sense.
Created attachment 143303 [details] MicrosoftDynamicsGP2013onWindowsAzure [BodyText single line spacing].docx: minimal example Reduced by hand as much as I could, and still keep the paragraph style "Body Text" to be inherited from none, and still be single-spacing (instead of 115%) when testing with MS Office 2010. The style reverts to the expected 115% if the word/_rels folder is deleted.
Created attachment 143308 [details] tdf82175_nopPrDefaults.docx: same as comment 11 except with docDefaults pPrDefaults removed (In reply to Justin L from comment #12) > The style reverts to the expected 115% if the word/_rels folder is deleted. This probably needs some explanation. Although the other documents in this bug report are all supposed to be using single spacing (according to MSO 2010), if docDefaults aren't defined, then MSO spacing defaults to 115%. (But there are some other factors at play as well, which I am not clear on... So, actually, I'm not sure what is "expected" in that particular document.)
Interesting discussion about ODT "Text Body" line spacing in bug 94464.
proposed fix https://gerrit.libreoffice.org/56919
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=58eb31be2dff045aa29e328c73a505104181b563 tdf#82175 writerfilter: honor basedOn -none- for built-in styles It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://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": http://cgit.freedesktop.org/libreoffice/core/commit/?id=961908dde51e44b93567cb59bd398778fe1ece10 related tdf#82175 writerfilter: use docDefault, not w:default It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I got side-tracked a bit when looking at this bug by considering what happens if some of the defaults are not defined/missing. That is a really dangerous area since it obviously will be very implementation dependent on different versions. "Compatibility" in those cases will be in the eyes of the beholder, not based on specification. Although this bug falls CLOSE to that area, it doesn't really apply. No intention to back-port this one, because the chances of perceived regressions are too high for my liking.