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
NOTE: is my first bug, attachments is a ZIP archive, but is wrongly tagged as text/plain
I do confirm anomaly/bug on LO 3.6.4.3 Portable under W7. /diego
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.
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.
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.
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
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.
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.
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
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
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
Just tested with LibreOffice v. 4.4.2 Portable under Win7 64bit. Same behaviour as before, bug is UNSOLVED.
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.
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
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).
Sorry mstahl, I did not understand what did you mean with this two attachments: mstahl 2015-05-05 22:03:19 UTC Attachment #113679 [details] Attachment mime type application/octet-stream application/vnd.oasis.opendocument.text mstahl 2015-05-05 22:03:29 UTC Attachment #113714 [details] Attachment mime type application/octet-stream application/vnd.oasis.opendocument.text May you please explain that?
(In reply to DiegoM from comment #16) > Sorry mstahl, I did not understand what did you mean with this two > attachments: > > mstahl 2015-05-05 22:03:19 UTC Attachment #113679 [details] Attachment > mime type application/octet-stream application/vnd.oasis.opendocument.text > mstahl 2015-05-05 22:03:29 UTC Attachment #113714 [details] Attachment > mime type application/octet-stream application/vnd.oasis.opendocument.text > > May you please explain that? He just changed the mime type to be correct.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
As requested via comment #18, I confirm the bug behaviour after testing with LO v.5.2.1.2 Portable under W7 64 bit. Nothing is changed, bug 100% in place. --- diego
addition to #19: as reported in bug header, regression was already tested.
Retested Bug 88487 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.
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.
(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.
*** This bug has been marked as a duplicate of bug 58944 ***
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).
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.