Bug Hunting Session
Bug 82175 - FILEOPEN: DOCX - Line spacing isn't imported correctly
Summary: FILEOPEN: DOCX - Line spacing isn't imported correctly
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: Other All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:6.2.0
Keywords: filter:docx
Depends on:
Blocks: DOCX-Paragraph DOCX-Styles
  Show dependency treegraph
 
Reported: 2014-08-05 05:10 UTC by Yousuf Philips (jay) (retired)
Modified: 2018-07-05 04:39 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
sample file (124.78 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-08-05 05:10 UTC, Yousuf Philips (jay) (retired)
Details
Word 2013 VS LibO 4.3.1 (157.95 KB, image/png)
2014-08-05 05:11 UTC, Yousuf Philips (jay) (retired)
Details
tdf82175_noStyleInheritance.docx: simple, but problematic, problem document (5.30 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-07-02 17:00 UTC, Justin L
Details
MicrosoftDynamicsGP2013onWindowsAzure [BodyText single line spacing].docx: minimal example (6.31 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-07-04 08:29 UTC, Justin L
Details
tdf82175_nopPrDefaults.docx: same as comment 11 except with docDefaults pPrDefaults removed (5.29 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-07-04 12:12 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-08-05 05:10:53 UTC
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.
Comment 1 Yousuf Philips (jay) (retired) 2014-08-05 05:11:54 UTC
Created attachment 104049 [details]
Word 2013 VS LibO 4.3.1
Comment 2 tommy27 2014-08-05 05:36:04 UTC
same issue on 4.4.0.0.alpha0+
Build ID: 8dc2ab47b9e5ef0ff381575195a36ceec8789ef1
TinderBox: Win-x86@42, Branch:master, Time: 2014-08-02_23:22:41
Comment 3 Alexandr 2014-08-31 15:32:41 UTC
Hello,
I get similar problem if I open attachment 74088 [details] from bug 60187, save it as docx and open the docx.
Comment 4 Matthew Francis 2015-01-19 09:50:58 UTC
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)
Comment 5 Matthew Francis 2015-01-19 10:02:51 UTC
Possibly the same as bug 86371 but would need further investigation to be sure
Comment 6 Timur 2015-06-19 13:34:25 UTC
Frame appears only from 3.5.x, so not inherited from OO, and also not a regression, because it never worked fine.
Comment 7 Robinson Tryon (qubit) 2015-12-09 18:44:57 UTC Comment hidden (no-value, obsolete)
Comment 8 Yousuf Philips (jay) (retired) 2017-10-31 07:36:03 UTC
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?
Comment 9 Xisco Faulí 2018-06-14 09:37:43 UTC Comment hidden (obsolete)
Comment 10 Justin L 2018-06-30 18:13:01 UTC
(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.
Comment 11 Justin L 2018-07-02 17:00:13 UTC
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.
Comment 12 Justin L 2018-07-04 08:29:55 UTC
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.
Comment 13 Justin L 2018-07-04 12:12:26 UTC
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.)
Comment 14 Justin L 2018-07-04 13:56:08 UTC
Interesting discussion about ODT "Text Body" line spacing  in bug 94464.
Comment 15 Justin L 2018-07-04 15:37:50 UTC
proposed fix https://gerrit.libreoffice.org/56919
Comment 16 Commit Notification 2018-07-04 15:46:16 UTC
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.
Comment 17 Commit Notification 2018-07-05 04:23:53 UTC
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.
Comment 18 Justin L 2018-07-05 04:39:59 UTC
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.