Created attachment 72382 [details] test document Find attached a document. The document is rendered wrong. Checked with Google docs the document has three pages only. But libre office shows a mess.
LibO sees first 34 table rows as table heading (i think there is no table heading to be repeated at all), I believe this table problem causes the page number problem. AOOo 3.4.1 shows the same problem, so I think this problem is inherited from OOo. @Laubrino: Please find out an contribute info concerning your - LibO Version, localization, UI language - OS Version, localization, UI language Are you sure that you have permission to publish that document here?
LibreOffice version 3.6.3. We use it in headless mode, so I'm not sure about localization/language. Tested on Windows 7. Godd question, we have permission to publish the document. Thank you
Confirmed with: LO 4.2.0.0.alfa0 Build ID: 2013-06-24 own debug build Windows 7 Professional SP1 64 bit Word 2010 - 5 pages document. LO - 28 pages document, where only 1st page is displayed... 26 times. No other pages available.
This issue is still reproducible with: - Libreoffice 4.1.5.3 Build ID: 1c1366bba2ba2b554cd2ca4d87c06da81c05d24 - Libreoffice 4.2.2.1 Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f - Libreoffice 4.3.0.0.alpha0 Build ID: b6a43bcbbf9e9a5655fd36fd4c8ef72d585f67b0
** 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 (4.4.2 or later) 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
Word viewer shows 5 pages and LibO 28. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 3ecef8cedb215e49237a11607197edc91639bfcd TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-19_23:16:58 Locale: fi-FI (fi_FI)
** 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
Reproducible with: Version: 5.4.0.0.alpha0+ Build ID: a9f56091b6422ec8c42f09b8472200ae4ab12548 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-12-05_23:12:26 Locale: nl-NL (nl_NL); Calc: CL
Extract the document.xml from the test document, examine the file we can see that <tblHeader/> for all the rows were set, this matches description of Comment 9 of issue 88496, quoted below: "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." Either this issue depends on 88496 or one of them is duplicate.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still buggy in LO 6.1 alpha1.
Created attachment 142050 [details] Sample DOCX Attaching a minimal sample. The table should continue on the next page, but is truncated instead.
Created attachment 142051 [details] Sample ODT (created in Word) ODT saved in Word behaves the same.
*** Bug 64264 has been marked as a duplicate of this bug. ***
*** Bug 88496 has been marked as a duplicate of this bug. ***
This is not a filter deficiency; so removing the keyword.
There's no need to use Word to reproduce. Steps: 1. Create a new text document in Writer. 2. Add a table (Table->Insert Table...; Ctrl+F12) with 100 rows and 99 heading rows (the dialog doesn't allow to set the heading rows number equal or greater than total number of rows). This creates a table which goes outside the page, and an "empty" second page is shown (with the single mandatory paragraph after the table). 3. In table properties (Table->Properties...), Text Flow tab, reduce the heading row count to 98. This makes the table to take two pages, each one having the table heading rows visible and going outside the page (apparent if you put some text to cells), with third "empty" page. What happens is the layout code doesn't split the table by heading rows; instead, it keeps outputting heading rows (going outside of the page in the process) and one normal row, then it is able to split table, which it does (going to the next page); there, it first outputs the 98 heading rows (again, going outside of the page) and one normal row.
As noted in bug 88496 https://bugs.documentfoundation.org/show_bug.cgi?id=88496#c9 pass 7. : To get the error condition is enough to produce a table where the header does not fit on the [first] page.
https://gerrit.libreoffice.org/55302
Not strictly related to DOC(X) formats, see comment 16 and comment 17, adjusting respective fields accordingly.
(temporary) workaround: https://gerrit.libreoffice.org/#/c/60689/
Description of the suggested (temporary) workaround: tdf#58944 DOCX import: workaround for hidden table headers Repeating table headers consisted of more than 10 table rows switch off table header repetition during DOCX table import to fix non-visible table content and broken tables. Repeating header lines are not visible in MSO, if there is no space for them. OOXML (and ODF) standards don't specify this exception, and unfortunately, it's easy to create tables with invisible repeating headers in MSO, resulting OOXML files with non-standardized layout. To show the same or a similar layout in LibreOffice (instead of a broken table with invisible content), we use a reasonable 10-row limit to apply header repetition, as a workaround. Later it's still possible to switch on header repetition or create a better compatible repeating table header in Writer for (pretty unlikely) tables with really repeating headers consisted of more than 10 table rows. Note: This workaround could help to create standard and more portable OOXML files in a mixed environment.
More information: MS Word has got a serious problem with the isolated rows with repeating header properties, and it seems, the suggested "solution" (for example, https://www.itsupportguides.com/knowledge-base/office-2013/word-2013-table-repeat-header-row-not-working/) is to remove the isolation by setting all previous table rows to table headers. I was able to create tables with non-working and non-modifiable tblHeader settings easily in MSO 2016 by concatenating tables with repeating tables, and it seems for me, it's hard to do the same magic (in fact, bad layout) in LO. For example, the second page of the table of one of our original documents has no repeating header in MSO because of the isolated tblHeader, but the other pages of the same table have no such problem. Removing the isolated tblHeader by LO import/export fixes the missing header problem in MSO.
László Németh committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=110781a3a27dffe9e6690839bdce993796a08331 tdf#58944 DOCX import: workaround for hidden table headers It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 145506 [details] test document saved in MSO as PDF (In reply to Buovjaga from comment #6) > Word viewer shows 5 pages and LibO 5.1 28 pages for attachment 72382 [details] PDF from MSO attached. It's 5 pages after the fix. OK. (It's 2007 DOCX and if resaved in MSO 2013 it wrongfully shows 6 pages but LO shows 5). (In reply to Aron Budea from comment #12) > Created attachment 142050 [details] > Attaching a sample DOCX. The table should continue on the next page, but is truncated instead. Used to be 3 pages in LO with truncated table on 2nd and after the fix it's 2 pages, table on 1st continuing on 2nd. MSO shows 3 pages, table starting on 2nd. I guess this fix also solved attachment 63889 [details] from bug 51785 and attachment 68489 [details] from Bug 55917 (same file). Table height is different (another issue) but it doesn't hang anymore. Please correct if I'm wrong. Also fixed attachment 138683 [details] from bug 114715, now 2 pages. (In reply to Mike Kaganski from comment #15) > *** Bug 88496 has been marked as a duplicate of this bug. *** I don't see how this is a duplicate. This one is about DOCX and that one about LO logic if table-header does fit in the page space.
*** Bug 51785 has been marked as a duplicate of this bug. ***
*** Bug 55917 has been marked as a duplicate of this bug. ***
*** Bug 114715 has been marked as a duplicate of this bug. ***
(In reply to Timur from comment #25) > (In reply to Mike Kaganski from comment #15) > > *** Bug 88496 has been marked as a duplicate of this bug. *** > I don't see how this is a duplicate. This one is about DOCX and that one > about LO logic if table-header does fit in the page space. Well - these *are* the duplicates; it's just the patch from comment 24 does a workaround specific for DOCX, by modifying the document's information, keeping old problem for other formats (DOC and ODF), instead of changing Writer layout logic to behave properly in that case...
But shouldn't than this one be for workaround and Bug 88496 kept open for full Writer layout logic? That makes sense from bug handling perspective.
(In reply to Timur from comment #30) If you want to close this bug, then definitely.
László, is the work here done or you intend to go on? Please comment that: you close this one as fixed and backport to 6.1 and that we open Bug 88496 or you will deal with issues from Bug 88496?
Timur, Mike: I've added a better explanation to the fix: https://gerrit.libreoffice.org/#/c/64388/1/writerfilter/source/dmapper/DomainMapperTableManager.cxx, continuing its backport, closing this issue, reopening the suggested one. Thanks for your help and suggestion!
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/b1dd670876cfdd3522de546e6eb4925bcde35a6b%5E%21 tdf#58944: comment DOCX table header row limit better It will be available in 6.3.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.