<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - FILEOPEN DOCX Three type Column with Next Page Section Break created with Word isn’t added to a new page opened in Writer" href="https://bugs.documentfoundation.org/show_bug.cgi?id=121670#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - FILEOPEN DOCX Three type Column with Next Page Section Break created with Word isn’t added to a new page opened in Writer" href="https://bugs.documentfoundation.org/show_bug.cgi?id=121670">bug 121670</a> from <a class="email" href="mailto:jluth@mail.com" title="Justin L <jluth@mail.com>"> Justin L</a> <pre>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 <a href="show_bug.cgi?id=121670#c3">comment 3</a> 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>