Bug 133370 - DOCX FILESAVE: Don't export column break in non-column situations, since Word treats as pagebreak.
Summary: DOCX FILESAVE: Don't export column break in non-column situations, since Word...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:7.0.0
Keywords: bibisected, regression
Depends on:
Blocks:
 
Reported: 2020-05-25 12:16 UTC by Justin L
Modified: 2020-06-01 06:08 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
ColumnBreak.odt: save as .docx format - get page-break (10.87 KB, application/vnd.oasis.opendocument.text)
2020-05-25 12:16 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin L 2020-05-25 12:16:56 UTC
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).
Comment 1 Justin L 2020-05-25 16:18:23 UTC
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
Comment 2 Commit Notification 2020-05-27 07:08:40 UTC
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.
Comment 3 Luke Kendall 2020-05-27 14:11:14 UTC
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
Comment 4 Telesto 2020-05-27 17:38:36 UTC
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
Comment 5 Luke Kendall 2020-05-28 04:02:04 UTC
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?
Comment 6 Justin L 2020-05-28 04:22:46 UTC
(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.
Comment 7 Luke Kendall 2020-05-28 04:37:16 UTC
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!
Comment 8 Luke Kendall 2020-05-29 16:12:15 UTC
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.
Comment 9 Luke Kendall 2020-05-30 14:31:57 UTC
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!
Comment 10 Luke Kendall 2020-06-01 06:08:53 UTC
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.)