Bug 46941 - FORMATTING: Saving .doc to .docx changes placement of text inside columns.
Summary: FORMATTING: Saving .doc to .docx changes placement of text inside columns.
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.5 release
Hardware: x86-64 (AMD64) All
: high normal
Assignee: Justin L
URL:
Whiteboard: interoperability target:5.4.0 target:...
Keywords: filter:doc, filter:docx
Depends on:
Blocks: DOCX
  Show dependency treegraph
 
Reported: 2012-03-03 14:26 UTC by ale.carrazzoni
Modified: 2017-01-12 13:51 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Zip file (15.45 KB, application/zip)
2012-03-03 14:26 UTC, ale.carrazzoni
Details
rdown2.pdf: how rdown2.doc looks in Word2007 (127.22 KB, application/x-msdownload)
2016-12-09 11:04 UTC, Justin L
Details
rdown_2.odt: continuous section margins are not changed. Use this as the test document. (24.12 KB, application/vnd.oasis.opendocument.text)
2016-12-09 13:11 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ale.carrazzoni 2012-03-03 14:26:53 UTC
Created attachment 57985 [details]
Zip file

I have attached a .zip file, which includes a rdown_2.doc, and a rdown_2.docx which was created by saving the .doc file as .docx with LibreOffice 3.4.5. 

In the .doc file, on the second page, there are two columns. The left column has text, while the right one is empty. After saving the file as .docx, the two lines after the line break appear in the right column, instead of the left column. Opening the file with MS Office web apps shows the same result.

Expected result: all text should be in the left column, while the right column should be empty.
Comment 1 bfoman (inactive) 2012-08-08 10:52:04 UTC
Confirmed with:
LO 3.5.5.3 
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit
Comment 2 Joel Madero 2012-08-15 06:04:47 UTC
To me it seems like margins are changing and this is causing the problem. If you notice what starts page 2 for the .doc it's different from the .docx. This could very well be the same bug that you reported for 46490. 

For a developer working on this, please see FDO#46490 to see if these are duplicates or just related.

Confirming the bug and setting priority. Set as High due to interoperability issue and the fact that .docx is now the norm which makes this bug affect professional quality of work.
Comment 3 Jorendc 2013-12-29 18:27:39 UTC
(In reply to comment #2)
> For a developer working on this, please see FDO#46490 to see if these are
> duplicates or just related.

I guess you mean bug 46940 :).
Adding to 'See also'
Comment 4 QA Administrators 2015-04-19 03:20:12 UTC Comment hidden (obsolete)
Comment 5 Buovjaga 2015-06-15 10:40:09 UTC
Columns are on page 3 of doc (Date of Birth etc.).
Saving to .docx with the latest version of LibO makes the columns formatting disappear. All the page breaks are lost, too, making the document have 3 pages instead of 4.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 01a189abcd9a4ca472a74b3b2c000c9338fc2c91
TinderBox: Win-x86@39, Branch:master, Time: 2015-06-14_07:46:28
Locale: fi-FI (fi_FI)
Comment 6 QA Administrators 2016-09-20 10:00:43 UTC Comment hidden (obsolete)
Comment 7 ale.carrazzoni 2016-09-24 23:10:40 UTC
Looks like the bug is fixed in LO 5.2.2, though now instead of a column break there is a line break with a large font size.
Comment 8 Buovjaga 2016-09-29 10:28:01 UTC
The original .doc is rendered differently in LibreOffice 5.3 than in 3.5.
It goes to 4 pages and the columns are now on page 3.
Saving to .docx from 5.3 makes the columns disappear (but not the content.

Win 7 Pro 64-bit Version: 5.3.0.0.alpha0+
Build ID: 3d9231dd4945dcd6c3d53ba11152049d382b975f
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-09-28_02:14:14
Locale: fi-FI (fi_FI); Calc: CL
Comment 9 Justin L 2016-12-09 11:04:55 UTC
Created attachment 129422 [details]
rdown2.pdf: how rdown2.doc looks in Word2007

After "Personal Details" header, there is a continuous section break that (unnecessarily) starts a 2-column section. After the last personal detail, a new section-with-page-break starts the last (3rd) page.
Comment 10 Justin L 2016-12-09 11:55:45 UTC
(In reply to Buovjaga from comment #8)
> The original .doc is rendered differently in LibreOffice 5.3 than in 3.5.
> It goes to 4 pages and the columns are now on page 3.

rdown_2.doc became 4 pages in LO 4.4.  see bug 87764 and commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=c5ed52b1cd6f22787c94bec035ceecf9e1da3271
Comment 11 Justin L 2016-12-09 13:11:47 UTC
Created attachment 129425 [details]
rdown_2.odt: continuous section margins are not changed. Use this as the test document.

(In reply to Joel Madero from comment #2)
> To me it seems like margins are changing and this is causing the problem.

Yes, the continuous section with the columns did have different margins which complicates focusing on the description problem. So using this version of the test document will avoid that complication.

As of 5.3's https://cgit.freedesktop.org/libreoffice/core/commit/?id=7060c7b642fdc0a369505e430652ee44205e7eed the columns are working again, BUT they "evenly distribute between the columns" on import in LO (as reported in the descrioption).  Probably this is just a default setting that isn't over-ridden by anything in the import process. But it looks great in MSWord now (except for the tabbing for telephone/fax/email).
Comment 12 Commit Notification 2016-12-13 07:43:22 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ede1a83e110ce7bc7d3560f415d6269ea3feb947

tdf#46941 docx: don't balance columns before page-break-section

It will be available in 5.4.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 13 Commit Notification 2016-12-14 04:56:05 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8820ca525a40f33fbb067868bc19a944597148af&h=libreoffice-5-3

tdf#46941 docx: don't balance columns before page-break-section

It will be available in 5.3.0.1.

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 14 Justin L 2016-12-14 05:37:21 UTC
Marking as resolved - fixed.  The problem clearly stated in the description is now fixed. Any other remaining issues with this document should be created as new bugs.

backport to 5.2 has been proposed as well.
Comment 15 Buovjaga 2016-12-19 12:45:44 UTC
(In reply to ale.carrazzoni from comment #0)
> In the .doc file, on the second page, there are two columns. The left column
> has text, while the right one is empty. After saving the file as .docx, the
> two lines after the line break appear in the right column, instead of the
> left column. Opening the file with MS Office web apps shows the same result.
> 
> Expected result: all text should be in the left column, while the right
> column should be empty.

Verified this is fixed. Nothing is moved to the right. Will look into creating new reports for the other stuff.

Win 7 Pro 64-bit Version: 5.4.0.0.alpha0+
Build ID: 5903235d57acb13d9d5286d23b443a01aeab9a3c
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-19_00:08:35
Locale: fi-FI (fi_FI); Calc: group
Comment 16 Justin L 2016-12-24 18:39:14 UTC
(In reply to Justin L from comment #14)
> backport to 5.2 has been proposed as well.
Apparently I lied about this.  It hasn't been proposed yet, and probably best if it isn't to avoid unintended regressions.  The earliest it will work is 5.3.
Comment 17 Buovjaga 2017-01-12 13:51:55 UTC
Filed bug 105285 for the column jump fileopen regression.