Bug 107861 - FILEOPEN DOC: Text Flow Break is wrongly enabled for table created in Word
Summary: FILEOPEN DOC: Text Flow Break is wrongly enabled for table created in Word
Status: RESOLVED DUPLICATE of bug 118711
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:doc
Depends on:
Blocks: DOC-Tables
  Show dependency treegraph
 
Reported: 2017-05-15 09:19 UTC by Telesto
Modified: 2022-02-08 10:00 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-05-15 09:19:30 UTC
Description:
Text Flow Break seems to be enabled by default when importing a doc containing a table

Steps to Reproduce:
1. Open attachment 74823 [details] (bug 59770)
2. Right click the table -> Table properties -> Tab textflow
3. Text Flow Break is enabled. 

Actual Results:  
Text Flow break shouldn't be enabled. The table ends up on a new paste when copy/pasting it.

Expected Results:
Text Flow break should be disabled


Reproducible: Always

User Profile Reset: No

Additional Info:
Version: 5.4.0.0.alpha1+
Build ID: 8c0be54a7da6262dffe04357121814dd22b5d7fe
CPU threads: 4; OS: Windows 6.2; UI render: default; 
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-15_01:35:45
Locale: en-US (nl_NL); Calc: single


User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Comment 1 Jacques Guilleron 2017-05-18 10:21:11 UTC
Hi Telesto,

Reproduced with
LO 5.4.0.0.alpha1+ Build ID: 034be10413ed4915090678ad4f1d48596cf5e206
CPU threads: 2; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-05-17_03:17:37
Locale: fr-FR (fr_FR); Calc: CL
and also with
LO  3.5.3.2 Version ID : 235ab8a-3802056-4a8fed3-2d66ea8-e241b80
so probably inherited from OOo.
Comment 2 QA Administrators 2018-05-19 02:35:30 UTC Comment hidden (obsolete)
Comment 3 Jacques Guilleron 2018-05-19 06:39:15 UTC
Confirmed with
LO  6.0.4.2 Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf
Threads CPU : 2; OS : Windows 6.1; UI Render : par défaut; 
Locale : fr-FR (fr_FR); Calc: CL
Comment 4 Justin L 2020-04-22 19:12:32 UTC
It sounds like it came from here, but disabling that didn't solve the problem:
// if first paragraph in table has break-before-page, transfer that setting to the table itself.
else if( false && StyleExists(m_nCurrentColl) )
{
  const SwFormat* pStyleFormat = m_vColl[m_nCurrentColl].m_pFormat;
  if( pStyleFormat && pStyleFormat->GetBreak().GetBreak() == SvxBreak::PageBefore )
      NewAttr( pStyleFormat->GetBreak() );
}

In fact, I can't find where it is coming from, but it also happens with the first paragraph int a blank document in both doc and docx. So it might be a requirement to start a document in MS formats with a pagebreak.
Comment 5 Justin L 2022-02-08 10:00:49 UTC
Fixed in LO 7.1 beta by author Justin Luth on 2021-02-26 12:24:17 +0100
commit 1c8df3e58940bf6abdbda0b2f932a5990b577fae
    tdf#118711 doc import: don't hardcode default page description

    well, at least not at the beginning of the document.

    This is a .DOC followup to the 7.1 .DOCX patch
    in commit 8787a45f9cbb5dce61b20817ef0e549b5a227a95.

*** This bug has been marked as a duplicate of bug 118711 ***