Bug 146917 - FILESAVE DOCX: Direct formatting is applied to paragraph thus negative first line indent is lost
Summary: FILESAVE DOCX: Direct formatting is applied to paragraph thus negative first ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.2.0.0 alpha1+
Hardware: All All
: medium normal
Assignee: Vasily Melenchuk (CIB)
URL:
Whiteboard: target:7.4.0 target:7.3.1
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: DOCX-Bullet-Number-Outline-Lists
  Show dependency treegraph
 
Reported: 2022-01-22 09:44 UTC by Kevin Suo
Modified: 2023-02-07 16:08 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
testFirstLineIndent.odt (37.34 KB, application/vnd.oasis.opendocument.text)
2022-01-22 09:44 UTC, Kevin Suo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Suo 2022-01-22 09:44:23 UTC
Created attachment 177700 [details]
testFirstLineIndent.odt

In the attached test odt file, the paragraph "FIELD NUMBER 1.0" and "FIELD NUMBER 2.0" has paragraph style "Field Number" applied, which has a first line indent of -5cm and a "before text" indent of 5cm. There is a tab stop after the ":".  There is no direct formatting on any part of the text, as can be observed from the "Styles Inspector" sidebar deck.

When this document is exported to DOCX, the *direct* formatting of "Para First Line Indent" (with the value 0) is applied two these two paragraphs, thus the format has changed.

Steps to Reproduce:
1. Open the attached odt and save as DOCX.
2. Reopen the saved DOCX.

Current Result:
The paragraph "FIELD NUMBER 1.0" and "FIELD NUMBER 2.0" has direct formatting applied which set the first line indent to 0. As a result, the first line goes to the 5cm position rather than in the -5+5=0cm position.

Expected Result:
The paragraph "FIELD NUMBER 1.0" and "FIELD NUMBER 2.0" should use the para style "Field Number", without any direct formatting.

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: e8b45704fc8d41a42d2272cb14bb40ee59516768
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN
Build Platform: Fedora34@X64, Branch:master, bibisect-linux-64-7.4-CN
Calc: threaded
Fedora 34, gnome x11.
Comment 1 Kevin Suo 2022-01-22 10:11:29 UTC
This is a regression.
Bibisected to range: 08e99279226206db8ce83cdebc4cf2994739e90b..a312837a1a4d0b9628d5c587c8ab5ec68179a051

$ git log --pretty=reference 08e99279226206db8ce83cdebc4cf2994739e90b..a312837a1a4d0b9628d5c587c8ab5ec68179a051
a312837a1a4d (tdf#137314 apply conversion from vml angle unit 'fd', 2021-05-24)
76ae0359f35b (sw: prefix members of SwApplet_Impl, SwFltAnchor, SwFltControlStack and ..., 2021-05-25)
a02d9e8de07d (Fix typo, 2021-05-24)
02181b90af46 (Removed 1/2, 1/4, 3/4, and 0.5 from autocorr/lang/ja/DocumentList.xml, 2021-05-23)

Whereas 76ae0359f35b seems to be related to this bug.

commit 76ae0359f35baeb4f8adf1d121c0f974c9024997
Author: Miklos Vajna
Date:   Tue May 25 08:50:42 2021 +0200

    sw: prefix members of SwApplet_Impl, SwFltAnchor, SwFltControlStack and SwFltRedline

Adding Miklos Vajna to cc: could you please take a look?
Comment 2 Miklos Vajna 2022-01-24 08:58:21 UTC
I think that's not a correct conclusion. Here is what I tried:

1) Clone the linux-64-7.2 bibisect repo.

2) Check out bd4b5b0faf3850b5f5e2e7713504a9cb640941a1 to include the above core.git 76ae0359f35baeb4f8adf1d121c0f974c9024997 commit.

3) Observe the output from the above bugdoc.

4) git checkout HEAD^ to exclude the above core.git commit.

5) Observe that the output for the above bugdoc is unchanged.

Which is not too surprising, the above core.git commit is a mechanical refactor, unlikely to result in anything that is possible to observe by a user.

Any reason you don't bisect to an exact commit using the linux-64-7.2 bibisect repo, rather just to a range and then guess?
Comment 3 Kevin Suo 2022-01-24 09:18:37 UTC
> Any reason you don't bisect to an exact commit using the linux-64-7.2 bibisect repo, rather just to a range and then guess?

Because the linux-64-7.2 bibisect repo is too large and my download speed in China from the TDF server is only < 50KB/s, and is very likly lose connection even at 99.9% procgress.

I then remove the bibisected keyword and add bibisectRequest keyword.
Comment 4 Timur 2022-01-25 09:18:54 UTC
Saved DOCX opens OK without indent in MSO, problem is with RT open in LO. 

Lin 7.2:
commit 5ed5823edba7015e3f40368a226f96b1f4eecd39
Date:   Tue May 25 11:47:22 2021 +0200
    source a4e7df83fcac6c68f110f89f41d5eb623038410e
    pre 4632f935951584826d18f04939cf6c809fd370cc
author	Vasily Melenchuk <vasily.melenchuk@cib.de>	2021-05-19
tdf#132752: docx import: improvements for first line indent in lists

CC: Vasily, please see.
Comment 5 Gabor Kelemen (allotropia) 2022-02-03 12:19:19 UTC
Adding Cc: to Vasily Melenchuk
so this shows up on the radar.
Comment 6 Vasily Melenchuk (CIB) 2022-02-09 07:00:03 UTC
Yeah, this is regression of mine patch.

Disabling for numbering in style is not so simple and straightforward as I implemented in that patch.
Comment 7 Commit Notification 2022-02-11 00:16:41 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/96e1be11540bada172fbdbfbbe3f9b7dc3e58462

tdf#146917: docx import: better support for style with num reset

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2022-02-11 09:43:03 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/a1ee86ebe1f3106d9601c989e4feeacfc1941331

tdf#146917: docx import: better support for style with num reset

It will be available in 7.3.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.