Bug 104348 - FILEOPEN DOCX: Spacing below paragraph which is not there in Word
Summary: FILEOPEN DOCX: Spacing below paragraph which is not there in Word
Status: RESOLVED DUPLICATE of bug 118521
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
5.4.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: DOCX
  Show dependency treegraph
 
Reported: 2016-12-02 10:53 UTC by Gabor Kelemen
Modified: 2019-08-06 09:16 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Document without spacing after paragraphs (37.23 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2016-12-02 10:53 UTC, Gabor Kelemen
Details
The file in LO master build (71.09 KB, image/png)
2016-12-02 10:54 UTC, Gabor Kelemen
Details
The document in Word 2013 without spacing ("Térköz") (48.94 KB, image/png)
2016-12-02 10:57 UTC, Gabor Kelemen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gabor Kelemen 2016-12-02 10:53:58 UTC
Created attachment 129237 [details]
Document without spacing after paragraphs

Attached docx has no spacing set before the first two paragraphs in Word.

When opened in current master there is a 0.35 cm spacing after them, making the short text of this name table "template" wrap to two pages.
Comment 1 Gabor Kelemen 2016-12-02 10:54:45 UTC
Created attachment 129238 [details]
The file in LO master build
Comment 2 Gabor Kelemen 2016-12-02 10:57:05 UTC
Created attachment 129241 [details]
The document in Word 2013 without spacing ("Térköz")
Comment 3 Telesto 2016-12-02 12:24:28 UTC
Confirming with
Version: 5.4.0.0.alpha0+
Build ID: 4130c8def811d1dcc87eacaa8ae48ba02738a790
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-11-29_01:03:18
Locale: nl-NL (nl_NL); Calc: CL

but not with:
Versie: 4.4.6.3 
Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d
Locale: nl_NL
Comment 4 raal 2016-12-12 19:40:11 UTC
This seems to have begun at the below commit.
Adding Cc: to Miklos Vajna ; Could you possibly take a look at this one?
Thanks

author    Miklos Vajna <vmiklos@collabora.co.uk>    2016-03-29 12:03:00 (GMT)
committer    Miklos Vajna <vmiklos@collabora.co.uk>    2016-03-29 13:26:57 (GMT)
commit    eae2331f83bd58bacccd898d60f6c5f54856c036 (patch)
tree    f73e187dfc7d8673b15a0bee475ccdb98270a85c
parent    dde79dd5044f6b5d6d9973f8f335956bfcb6fb4c (diff)
tdf#98882 DOCX import: set default para properties on the Standard para style

5c14252fb0be0d2e8f8afdfc2e63525a947adce6 is the first bad commit
commit 5c14252fb0be0d2e8f8afdfc2e63525a947adce6
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Sat Apr 2 17:02:56 2016 -0700

    source sha:eae2331f83bd58bacccd898d60f6c5f54856c036

git bisect log
# bad: [6380ca07b05f68dedcaa379302cfe1fa478571c4] source sha:60b74fe1775e647545d2da1fcc58a4c63ec18aa5
# good: [1f670510f08cb800cbae2a1dd6ea70d3542e4721] source sha:49c2b9808df8a6b197dec666dfc0cda6321a4306
git bisect start 'origin/master' 'oldest'
# good: [38f37b8ec1a2d199bb957cfd2581df7d1b273b74] source sha:c0da1080b61a1d51654fc34fdaeba373226065ff
git bisect good 38f37b8ec1a2d199bb957cfd2581df7d1b273b74
# bad: [11ae494d8c566f23e0ef84ba0cc25fb1388b67f7] source sha:470cfa9860232ab70e017e6084d80f80d469555c
git bisect bad 11ae494d8c566f23e0ef84ba0cc25fb1388b67f7
# good: [d247d25062e6cc4afccdc3c4be84a2b98523b36a] source sha:150c1dcab007dd8acc1551791f42eef692f9e531
git bisect good d247d25062e6cc4afccdc3c4be84a2b98523b36a
# bad: [812f064e57b17d51c4e0804fb39e13f0e0661ff2] source sha:8d123bf1491bcc7415f4dde3ddd397a11146bb38
git bisect bad 812f064e57b17d51c4e0804fb39e13f0e0661ff2
# good: [c649da763f4116e21b0cef91c706ea7bb73c25bc] source sha:402572e25c0c9eb1f01c928f2ae422ab62a55ba1
git bisect good c649da763f4116e21b0cef91c706ea7bb73c25bc
# good: [d16c94f250b69c07168c9c677ae39f5b4f7044c1] source sha:82510829d5be4321166ae80679b43b376f41ae9e
git bisect good d16c94f250b69c07168c9c677ae39f5b4f7044c1
# bad: [3f29a604df78a6d7b5a0fd4f0794b196431f0a34] source sha:a9a9f694089505c5fbbf5e099d5e185e1a46ab29
git bisect bad 3f29a604df78a6d7b5a0fd4f0794b196431f0a34
# good: [e892c24b9cca10f4d3f4b5c2ca30d5744537a21a] source sha:ed7ad21acf35ffdad8656b25e664131bcf38b331
git bisect good e892c24b9cca10f4d3f4b5c2ca30d5744537a21a
# good: [25132308ede791e4e967b1429f8602ed6fcfb5e7] source sha:d739811038c54081ea4039a939af8f320b31378b
git bisect good 25132308ede791e4e967b1429f8602ed6fcfb5e7
# bad: [5c14252fb0be0d2e8f8afdfc2e63525a947adce6] source sha:eae2331f83bd58bacccd898d60f6c5f54856c036
git bisect bad 5c14252fb0be0d2e8f8afdfc2e63525a947adce6
# good: [13d81a7d0fd3bf11073832a936b4e993c86b05f8] source sha:0f2e6f1fbb42fe33bee3ffd5b5200b17be3382d9
git bisect good 13d81a7d0fd3bf11073832a936b4e993c86b05f8
# good: [1a12505420c113393b0bef425c930ce5a81db8e2] source sha:a91272a6a423e911b832b2f103a77521b4106ed1
git bisect good 1a12505420c113393b0bef425c930ce5a81db8e2
# good: [0ab0b76861fe450ae3ae246d85ff56425cf94384] source sha:dde79dd5044f6b5d6d9973f8f335956bfcb6fb4c
git bisect good 0ab0b76861fe450ae3ae246d85ff56425cf94384
# first bad commit: [5c14252fb0be0d2e8f8afdfc2e63525a947adce6] source sha:eae2331f83bd58bacccd898d60f6c5f54856c036
Comment 5 Xisco Faulí 2016-12-12 19:52:17 UTC
I'd assume this is related to bug 103980 as the same commit introduced both regressions. Closing this one as RESOLVED DUPLICATED

*** This bug has been marked as a duplicate of bug 103980 ***
Comment 6 Justin L 2018-07-24 09:30:17 UTC
Not a duplicate.  This one is caused because ContextualSpacing is shared with ULSpace in the internal EditEng code. If ULSpace is not defined, then it will hard-code in the docDefaults.  Related to bug 118521.

> case NS_ooxml::LN_CT_PPrBase_contextualSpacing:
>   rContext->Insert(PROP_PARA_CONTEXT_MARGIN, uno::makeAny( nIntValue != 0 ));
Comment 7 Justin L 2018-07-24 13:04:21 UTC
proposed fix https://gerrit.libreoffice.org/57914 
tdf#118521 writerfilter: ContextMargin grouped with Top/Bottom
Comment 8 Justin L 2018-07-24 18:14:46 UTC

*** This bug has been marked as a duplicate of bug 118521 ***
Comment 9 Justin L 2018-08-03 04:46:23 UTC
Fixed in 6.2 with commit 07266e2314fd19dcbf777dadd52d7b826b23c207.
tdf#118521 writerfilter: ContextMargin grouped with Top/Bottom

fixes tdf#104348, but tagging with the bug# of the initial fixes.

Internally, EditEng holds Top/Bottom/Context settings in one object, so if only one piece is set, the cloned object starts with docDefaults, so the un-initialized parts also need to be specified with the values they inherit from their style.

So this patch makes two corrections. The first is grouping ContextMargin with top/bottom. The second correction is to check the entire style-chain instead of only the direct style for the inherited property.