https://bugs.documentfoundation.org/show_bug.cgi?id=163178
Justin L <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|[email protected] |[email protected] |desktop.org | --- Comment #4 from Justin L <[email protected]> --- repro 26.8 Normally SwFlowFrame::IsPageBreak returns false when m_rThis.IsInTab(). But in this case the table itself has the column break assigned to it. This is a rather special circumstance somehow. If there is another paragraph that starts the table, then everything is somewhat fine. But because this is the very first paragraph, and it gets split into two paragraphs, the table-making function that runs later doesn't start at the correct spot. Fun. I expect that is because lcl_endParagraphGroup assumes that the current paragraph is the one where the table might have started. And (for some unknown reason) we don't call lcl_endParagraphGroup before calling lcl_startParagraphGroup. However, we don't have this problem with page breaks. It was avoided by not allowing deferred page breaks in the first place. DomainMapper_Impl::deferBreak prevents PAGE breaks when inside of a table ever since 2013. But the same was not done for COLUMN breaks - perhaps because ww8 doesn't mention column breaks in HandlePageBreak. There is no HandleColumnBreak. However, during DOC import in SwWW8ImplReader::ReadChar we have case 0xe: // if there is only one column word treats a column break like a pagebreak. if (m_aSectionManager.CurrentSectionColCount() < 2) bParaMark = HandlePageBreakChar(); else if (!m_nInTable) // set the column break So when handling column breaks it also does nothing when m_nInTable. Thus the same logic should apply for column breaks according to DOC import as well. -- You are receiving this mail because: You are the assignee for the bug.
