[Libreoffice-bugs] [Bug 121670] FILEOPEN DOCX Three type Column with Next Page Section Break created with Word isn’t added to a new page opened in Writer

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=121670

--- Comment #4 from Justin L <jluth at mail.com> ---
yuck: PropertyMap.cxx's bTreatAsContinuous is true in this case, but it
shouldn't be. Amazingly, if I remove all of the qualifications, no unit tests
fail anymore.

So the root of the problem is that because it is bTreatAsContinuous, it misses:
commit ede1a83e110ce7bc7d3560f415d6269ea3feb947
Author: Justin Luth 
Date:   Sat Dec 10 09:35:09 2016 +0300

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

This type of problem has had extreme regression tendencies, so I am
over-documenting everything here...

Some relevant commits from history to review are:
commit afc96d263959d10e457b54a574f0829d20e99df4
Author: Justin Luth 
Date:   Tue Nov 7 09:29:30 2017 +0300

    tdf#112352 ooxmlimport: ALWAYS treat 1st nextpage w/cols as cont

    fix 5.4 regression from 4605bd46984125a99b0e993b71efa6edb411699f.

[**** a key cautionary note here.  How accurate I was remains to be seen...]
    When there are columns, if a nextpage section doesn't contain any
    other "page style" details we treat it as a continuous break,
    If we don't, the column info becomes part of the style itself,
    and not just a section property.

    However, the very first section is troublesome - by definition it DOES
    contain page style details, and so if the document starts with columns,
    the default style would gain the column attribute. Usually that
    results in a mess, so lets make sure that we avoid that also in
    the case where headers/footers are defined.

The following commit might be the biggest reason why this now seems to work:
commit 4605bd46984125a99b0e993b71efa6edb411699f
Author: Justin Luth 
Date:   Thu Mar 9 18:13:50 2017 +0300

    tdf#103931 writerfilter breaktype: same for implicit and explicit

    MSWord normally does NOT specify "nextPage" for the sectionBreak,
    since that is the default type. That is imported as BreakType == -1.
    However, Writer ALWAYS exports the section type name, which of
    course is imported explicitly.
    **There is an import hack that treats the very first -1 section as
    continuous IF there are columns**. Since Writer explicitly defines
    the section type, these documents import differently.

    When Writer round-trips these types of files, they get totally
    messed up in Writer, although they look fine in Word. So, treat
    both implicit and explicit nextPage identically for
    bTreatAsContinuous during import.

[**** and a proper fix for this part is just landing in LO 6.3 *****]
    Another unit test demonstrated that headers/footers are lost when
    treating as continuous, so preventing that situation now also.

and finally the original fix to the same commit mentioned in comment 3
commit 3870c0555aa461268a6d056543f4545d562769ce
Author: Justin Luth 
Date:   Wed Sep 7 19:26:30 2016 +0300

    tdf#81345 docx import fix default page break regression

    "regression" from 4e653d15eff26aa5283d8ba20611893f4c573f57

    If there are new style elements, then don't treat a
    default break in columns as a continuous break.

    This fixes both round-tripping, and initial import of
    columns and headers on this particular document. Since
    MS and LO treat sections so differently, it is a balancing
    act of what to change.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20181221/990c2126/attachment-0001.html>