Created attachment 161260 [details] ColumnBreak.odt: save as .docx format - get page-break LibreOffice basically ignores a column break setting if there are no columns. However, in DOCX they are treated as page-breaks. So export should just avoid writing out a column break when it is not in a column. This does NOT affect DOC or RTF - only DOCX (tested with MS Office 2003).
This is almost certainly why only DOCX is affected: LO 4.3 commit d747d0fc3b3e9c02a2eaa5b4a03c6905a68663d0 Author: Miklos Vajna on Thu Feb 13 15:25:44 2014 +0100 DOC/RTF export: fix handling of column breaks when there is only one column The first real part of commit 4d5c193b2fd38c6cab049fcb97189462fff0fddb (INTEGRATION: CWS limerickfilterteam08 (1.64.6); FILE MERGED, 2003-09-01) tweaked the DOC export, so that in case there is only one column, the column break is not exported: this way the Writer and Word layout matches, because Word handles that situation by handling the break as a page one, but Writer layout ignores it. On import, the DOC filter changes a column break to a page break in that situation, so visually the roundtrip is OK. The RTF filter does the same: the tokenizer turns a column break into a page one if necessary, and on export then we can ignore such a column break. However, the DOCX filter is different: there we don't tweak the column break on import, so we want to keep it on export as well. (A perfect solution for this would be one more layout compat option, then filters can stop tweaking the break types.) The "a perfect solution for this would be one more layout compat option" was implemented in LO 5.2.2 with the two patches for bug 76349. Since the import for DOCX has NOT tweaked the column break, and the UI views the imported DOCX column break as a page break, it will NOT be correct to simply ignore the column break in this situation - otherwise DOCX files will lose visual page-breaks. Proposed fix at https://gerrit.libreoffice.org/c/core/+/94799
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3fb424b4326cff4f810fb24977e387bdb9e5a34e tdf#133370 docx export: don't export unseen columnbreak It will be available in 7.0.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.
I'm interested in trying out the daily build with the fix but I have a few questions: 1) Will installing the daily build remove my installed release build? (I can only dare try it if I can run both.) 2) How can I know whether a daily build contains the fix I want to test? 3) How do I know where to fix the daily build with the fix? Will it be under the libreoffice-6-3 directory or the libreoffice-6-4, or the master? Or maybe even somewhere else not listed in the daily builds, like https://downloadarchive.documentfoundation.org/libreoffice/old/7.0.0.0.alpha1/deb/x86_64/LibreOfficeDev_7.0.0.0.alpha1_Linux_x86-64_deb.tar.gz
Daily builds can be found here: https://dev-builds.libreoffice.org/daily/master/current.html Some instructions for parallel installation: https://wiki.documentfoundation.org/Installing_in_parallel/Linux
Thanks. So it will appear in the master/ directory. And I can just untar then dpkg-deb into /opt. But how do I know if the fix for 133370 has been included? Is there a changelist or list of bugs fixed, that's auto-generated and placed somewhere to match the build?
(In reply to Telesto from comment #4) > Daily builds can be found here: > https://dev-builds.libreoffice.org/daily/master/current.html The column after the "time of creation" contains a hash number of the last change. Click on that hash number to see a list of all of the changes (the git log) included in the build.
Perfect, thanks! I see it's time sorted too, which is great, and I can easily search in the page for the first several letters of the patch (3fb42). I'll keep an eye on it. Thanks again!
I looked into Linux-rpm_deb-x86_64@86-TDF-dbg 2020-05-29 14:50:09 8581d88 and saw that it included the fix. But I gather the file https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF-dbg/2020-05-29_10.56.19/master_dbg~2020-05-29_10.56.19_LibreOfficeDev_7.1.0.0.alpha0_Linux_x86-64_archive.tar.gz isn't what I wanted, since I was after the .deb files. I've tried running the soffice script from inside that directory, and opening my book. It's just running at 100% CPU though with nothing visible happening. No, it's used 32mins of CPU time without prdoucing any visible result. I think I'm doing the wrong thing. Maybe the .deb files will be available tomorrow.
I used the Debian alpha release of 7.1.0.0 and can confirm the bug has been resolved. Thank you, this is saving me hours of my work, which is important given my deadline is later today. Great work, thank you!
I did notice two unrelated problems - the alpha version crashed a LOT when doing innocuous things like closing a document - a document selected for opening wouldn't open the first time - an empty window would load up (waiting for something to happen didn't help); if you opened the doc a second time it would then open a fresh document window and load into that. When finished with that document, closing it then made the first empty document window complete loading. On one occasion I ended up with the same document open in two different Writer windows, both active. (I didn't dare touch one of them.) I'm pretty sure you know about those issues, and that they're unrelated to this bug report. I just thought I'd mention it in case. The crash reporter seemed to generate crash reports for each crash, but it never notified me of a crash report's location (e.g. an older URL like crashreport.libreoffice.org/stats/crash_details/a75f47a1-a9e3-45cf-ad0b-5fb719f8ed94 ) (I think I had about 20-30 crashes over an intense 8hr work session.)