Bug 88496 - FORMATTING Multiple row table header pushed to next page if rows do not fit (unless one sets table properties .. uncheck Repeat Heading). behavior different from MS Word
Summary: FORMATTING Multiple row table header pushed to next page if rows do not fit (...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: László Németh
URL:
Whiteboard: interoperability target:6.5.0
Keywords:
: 99559 (view as bug list)
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
 
Reported: 2015-01-16 14:22 UTC by DiegoM
Modified: 2024-05-28 23:05 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Example of described problem in 3 steps; output in .PDF for fast comparision (457.31 KB, application/zip)
2015-01-16 14:22 UTC, DiegoM
Details
Evidence of reported problem in AOO v.4.3 also - ODT format (18.66 KB, application/vnd.oasis.opendocument.text)
2015-02-25 15:30 UTC, DiegoM
Details
Evidence of reported problem in OO v.3.3 also - ODT format (18.28 KB, application/vnd.oasis.opendocument.text)
2015-02-26 16:15 UTC, DiegoM
Details
document with multi row header table (9.25 KB, application/vnd.oasis.opendocument.text)
2015-03-20 01:25 UTC, Gordo
Details
sample docs (33.07 KB, application/zip)
2015-03-31 17:16 UTC, Gordo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description DiegoM 2015-01-16 14:22:33 UTC
Created attachment 112346 [details]
Example of described problem in 3 steps; output in .PDF for fast comparision

LibreOffice does handles Header Tables in unpredictable way in specific conditions
Test bed: LibreOffice 4.3.5.2 under Win7 – Word 2007 SP3
          Libreoffice 4.2.7.2 under xUbuntu Linux

Description:
Table defined with header-rows longer than a page in two variants:
- Header N rows long on a table with M rows
- Header spans the full table

Problem: 
as soon as the contents of Header-rows make them not fit in the bottom-free page space, the table begin is pushed on a new page;
as soon as the contents of Header-rows make them not fit in the page space, part of the header and the following table-rows disappear under page-bottom. 
In the example below a 20-rows table with 10-rows header was defined, contents of first 10 rows was made higher of bottom-free page space.

As a comparision, text was saved in docx format and opened with Word 2007 SP3. This program react different: as soon as the header-rows does not fit anymore in the bottom-free page space, the header definition is preserved but neglected, and presentation is done as the table has been defined with 0-rows header.

Even more: if .odt version is opened with Word 2007, program complains “
The file <file-name> cannot be openend because there are problems with the contents. The file is corrupted and cannot be opened”, propose to recover it, if OK is pressed contens as from .DOCX is shown up.

Three steps are presented: 
1 has no header table defined
2 has 10-rows header table defined, but made such that header fits in the 1st page free space
3 has 10-rows header table defined, but made such that header dose not fit in a page space
Comment 1 DiegoM 2015-01-16 14:32:22 UTC
NOTE: is my first bug, attachments is a ZIP archive, but is wrongly tagged as text/plain
Comment 2 DiegoM 2015-01-26 18:04:32 UTC
I do confirm anomaly/bug on LO 3.6.4.3 Portable under W7.
/diego
Comment 3 tommy27 2015-01-26 19:07:03 UTC
I update the version field to 3.6.4.3 which is the first release where you reproduced the bug.

I revert status to UNCONFIRMED since status NEW has to be set only after independent confirmation by another user.
Comment 4 DiegoM 2015-02-25 15:30:15 UTC
Created attachment 113679 [details]
Evidence of reported problem in AOO v.4.3 also - ODT format

Question if probelm was present in AOO also was posed. I demonstrate that behaviour between LibO and AOO is identical.
Comment 5 DiegoM 2015-02-26 16:15:43 UTC
Created attachment 113714 [details]
Evidence of reported problem in OO v.3.3 also - ODT format

Same behaviour was checked back to OpenOffice version 3.3.0-rel18 (using winPenPack portable build).
Fact: same problematic behaviour for Table Headings was discovered in LibreOffice (v. 3 and 4), ApachOpenOffice v.4 and OpenOffice v.3.
Comment 6 Buovjaga 2015-03-03 17:01:09 UTC
Could you make some more clear reproducing steps, like numbered steps with LO_Table_Problem1.odt as the start?

In LO_Table_Problem1.odt, I went to a header row and started hitting return. I did not see any part of the table disappear or get hidden.

You could also try with LibreOffice 4.4.1.

Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists with 4.4.1. Change to RESOLVED WORKSFORME, if the problem went away.

Win 7 Pro 64-bit, LibO Version: 4.4.1.2
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI
Comment 7 Octavio Alvarez 2015-03-03 17:58:05 UTC
Yes, please, I would like to reproduce it in my computer, too. There are many settings that affect Writer behavior with regard to headers in tables so it's not clear how exactly is your document set up. Please share with us the exact steps to force the bug, starting from a clean document.
Comment 8 Gordo 2015-03-20 01:25:52 UTC
Created attachment 114200 [details]
document with multi row header table

If you look at my attachment, is this the bug?

Select table and adjust row height to be Fit to size and 0.01cm to see the table before I formatted the row height.
Comment 9 DiegoM 2015-03-31 15:55:50 UTC
Answer to  Gordo 2015-03-20 01:25:52 UTC 

No, as written is a strange behaviour more than a bug, but with nasty results.
I summarize once more.

1. open a document ODT
2. enter 1/2 page of text
3. enter a table with 20 rows, 1 o 2 column is ok
4. define the first 10 rows as header (may be from 1 to N, 10 is just for example)
5. enter text in all the rows
6. enter more text in the header rows, in a way that the sum of text DOES NOT fit in the 1/2 page you should have free after the text (see 1.)
7. as soon as the headers DOES NOT fit in the page, some paging of the table is disrupt and you do not see the last lines of header anymore.

What WORD seems to do in the same situation: as soon as recognise that the headers line dose not fit on the page portion reserved for table, it consider the table as with-no-header, even if in the definition this stays in place.

This rise a big problem: in WORD => v.2007 for the user is very easy to define a table with, say, 50 rows all in the header (just select full table and click one button on the ribbon). WORD will disregard this config and render the table as with no header at all. 
Pass this DOC at WRITER: table render will disrupt.

--- 
Hope this will be clear enough
diego
Comment 10 Gordo 2015-03-31 17:16:23 UTC
Created attachment 114503 [details]
sample docs

I have attached two documents.  The second one had a little more added to one of the headers.

You can see all the text in the table by doing Table -> Table Properties -> Text Flow -> uncheck Repeat Heading.

@Diego:  So to rephrase, LO should recognise large amounts of text in table headings, or multiple table headings with a combined large amount of text, and disable repeat headings.

Version: 4.4.1.2
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Comment 11 DiegoM 2015-03-31 21:56:49 UTC
Yes Gordo, this should mimic what WORD is doing and will solve. 

IMHO it WRITER could do better: show up a warning to the user, signaling the problem and let the user be aware. 
i.e., do not be silent, talk to the user: he/she is not a stupid beeing ;)

Tnks,
diego
Comment 12 DiegoM 2015-04-08 17:50:06 UTC
Just tested with LibreOffice v. 4.4.2 Portable under Win7 64bit.
Same behaviour as before, bug is UNSOLVED.
Comment 13 DiegoM 2015-04-08 17:55:33 UTC
Please re-read my comment "DiegoM 2015-03-31 15:55:50 UTC", as may explain how this behaviour may appear a big Bug to WORD-used users, as that product will disregard header-config if table will not fit into the page. 

I'm looking for let confirm the Bug from other users.
Comment 14 Buovjaga 2015-04-08 18:06:15 UTC
Confirmed by looking at the documents in attachment 114503 [details] and ticking/unticking the Repeat headers setting.

Lowering severity as the problem can be solved by unticking the setting: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

The summary might be worded better, but I can't think of anything atm..

Win 7 Pro 64-bit, Version: 4.4.2.2
Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6
Locale: fi_FI
Comment 15 DiegoM 2015-04-08 20:12:25 UTC
Correct: unticking setting (or changing header setting) will solve, bute the user could not guess the problem.

Actual fact:
- having text on a page before a table, when table-header does not fit on the bottom part of page, Writer push the table-start to a new page.

Suggestion: 
- add a check to se if table-header does fit in the page space; if not, just rise a warning to the user saying "table-header does not fit on page". Imho this approach should be better than the Word solution.

Lowering severity let stay the problem in place for long. Could be a very nasty one for MSOffice-to-LibreOffice migration projects, due to recent Word version behaviour (see end of comment 9).
Comment 16 DiegoM 2015-05-06 14:55:46 UTC Comment hidden (obsolete)
Comment 17 Buovjaga 2015-05-06 15:15:01 UTC Comment hidden (obsolete)
Comment 18 QA Administrators 2016-09-20 09:42:27 UTC Comment hidden (obsolete)
Comment 19 DiegoM 2016-09-20 10:51:04 UTC Comment hidden (obsolete)
Comment 20 DiegoM 2016-09-20 10:53:33 UTC Comment hidden (obsolete)
Comment 21 DiegoM 2017-08-14 08:46:13 UTC Comment hidden (obsolete)
Comment 22 DiegoM 2017-08-14 08:52:57 UTC
Reference on comment #21 to bug number was wrong; correct follows:
--
Retested Bug 88486 for version LO 5.3.5.2 64-bit on Win-7 64-bit.
Behavior originally described [DiegoM 2015-01-16 14:22:33 UTC] is full confirmed.
Comment 23 Mike Kaganski 2018-06-04 07:11:44 UTC
(In reply to DiegoM from comment #0)
> As a comparision, text was saved in docx format and opened with Word 2007
> SP3. This program react different: as soon as the header-rows does not fit
> anymore in the bottom-free page space, the header definition is preserved
> but neglected, and presentation is done as the table has been defined with
> 0-rows header.

(In reply to DiegoM from comment #9)
> What WORD seems to do in the same situation: as soon as recognise that the
> headers line dose not fit on the page portion reserved for table, it
> consider the table as with-no-header, even if in the definition this stays
> in place.
> 
> This rise a big problem: in WORD => v.2007 for the user is very easy to
> define a table with, say, 50 rows all in the header (just select full table
> and click one button on the ribbon). WORD will disregard this config and
> render the table as with no header at all. 
> Pass this DOC at WRITER: table render will disrupt.

Just a note: it's not exactly as if there's no heading rows at all. It is apparent when the table is not the topmost element on a page (e.g., some paragraph(s) above it). In this case, making more heading rows than the page's height moves the entire table to the next empty page, and only then, when even the empty page isn't enough, starts it to output rows as if there's no heading rows. In contrast, if there actually were no heading rows defined, the table would start on the page with those initial contents, and flow to the second page.
Comment 24 Mike Kaganski 2018-06-04 07:13:44 UTC

*** This bug has been marked as a duplicate of bug 58944 ***
Comment 25 László Németh 2018-12-01 10:16:15 UTC
Reopened as a general bug, according to https://bugs.documentfoundation.org/show_bug.cgi?id=58944#c30 (that issue was only for a workaround for the reported documents).
Comment 26 Commit Notification 2020-01-17 11:35:58 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f7e071a00542c414a7e9d7bcf4434d908f225e59

tdf#88496 DOCX: disable long repeating table header

It will be available in 6.5.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 27 Gabor Kelemen (allotropia) 2024-05-28 23:05:42 UTC
*** Bug 99559 has been marked as a duplicate of this bug. ***