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.
Confirmed with: LO 3.5.5.3 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit
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.
(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'
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
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)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
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.
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
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.
(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
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).
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.
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.
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.
(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
(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.
Filed bug 105285 for the column jump fileopen regression.