Bug Hunting Session
Bug 48378 - FILEOPEN Table in DOC loses rows over page boundary (and doesn't commence on a new page)
Summary: FILEOPEN Table in DOC loses rows over page boundary (and doesn't commence on ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.0 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: confirmed:4.2.0.3:OSX
Keywords: filter:doc, preBibisect
: 49445 (view as bug list)
Depends on:
Blocks: DOC-Tables
  Show dependency treegraph
 
Reported: 2012-04-06 04:58 UTC by suedsauerland
Modified: 2019-09-02 09:28 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
The Word DOC (219.00 KB, application/msword)
2012-04-06 04:58 UTC, suedsauerland
Details
Screenshot showing rendering under MSO2007 (40.65 KB, image/png)
2014-09-29 03:27 UTC, Owen Genat (retired)
Details
DOC edited in LOv4263 to reset table and row breaking options (137.50 KB, application/msword)
2014-09-29 03:30 UTC, Owen Genat (retired)
Details
Screenshot showing diferent LO rendering (115.49 KB, image/jpeg)
2015-12-03 14:58 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description suedsauerland 2012-04-06 04:58:48 UTC
Created attachment 59581 [details]
The Word DOC

On the side 3 of the Word document I miss the line 1 to 4.
Comment 1 leighman 2012-08-08 10:33:10 UTC
I can confirm this bug in current master branch ~3.7.

Can you provide any simpler document that demonstrates this issue or instructions to reproduce it?
Comment 2 retired 2014-01-21 10:10:44 UTC Comment hidden (obsolete)
Comment 3 retired 2014-01-21 10:11:43 UTC Comment hidden (obsolete)
Comment 4 suedsauerland 2014-01-23 17:48:37 UTC
On side 3 I missing some lines. 
Normaly the document has the line 1, 2, 3, and so on. 
When I open the DOC file I see on side 3 only the column 5,6 7 .... 35.
Comment 5 retired 2014-01-23 22:00:04 UTC Comment hidden (obsolete)
Comment 6 Jean-Baptiste Faure 2014-01-25 14:21:36 UTC
The third table should start on the top of a page. 
Workaround: insert a page break before the table or click inside the table and menu Table > Table Properties > tab Text Flow > checkbox "Break".

Best regards. JBF
Comment 7 Owen Genat (retired) 2014-09-28 10:17:49 UTC
Summary amended for clarity. There are several reports relating to DOC table handling and I am trying to determine what each report details. Issue in attached example re-confirmed under GNU/Linux using:

- v4.2.6.3 Build ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21
- v4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d
- v4.4.0.0.alpha0+ Build ID: df73f4115cfe4d07e4159adf087571687eb173ec TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-09-25_23:06:16
Comment 8 Owen Genat (retired) 2014-09-28 10:28:59 UTC
Also tested under GNU/Linux using:

- v3.3.4.1 OOO330m19 Build: 401
- v3.4.6.2 OOO340m1 Build: 602
- v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v3.6.7.2 Build ID: e183d5b
- v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a

In all versions the final table is broken over both pages (i.e. first row appears at the foot of page 2), however in v3.3 the missing rows (Lfd. Nr., 1, 2, 3, and 4) are displayed as expected. Version set to 3.4.6. PossibleRegression keyword added to whiteboard. As per comment 5 and comment 7, platform set to All/All.
Comment 9 Jean-Baptiste Faure 2014-09-28 16:50:04 UTC Comment hidden (obsolete)
Comment 10 Owen Genat (retired) 2014-09-29 03:27:18 UTC
Created attachment 107035 [details]
Screenshot showing rendering under MSO2007

(In reply to comment #9)
> In LibreOffice table has a property "Allow table to split accross pages and
> columns" See tab Text Flow in the Table Format dialog.
> The corresponding checkbox is checked for the third table; unchecking it
> fixes the problem. So the question is: is there the same table property in
> MS-Word ? And if it is the case, what is the value of this property when you
> open the file in MS-Word ?

Thanks for this line of enquiry. It only fixes the problem in terms of immediate on-screen rendering. Re-saving to DOC, closing, and re-opening (in LO) results in the same problem. Under MSO2007 the original renders as expected (refer attached screenshot). There is no equivalent table-level option in table properties in this version of MSO, only a row-level equivalent option (which is set for all but the first two rows in the table). Any row containing rotated text has this row-level option greyed out in MSO2007, which seems reasonable (although in LO it is possible to set this on rows containing rotated text).

It appears the problem is related to a combination of the row-level option and the row with rotated text. In LO unchecking the row-level and the table-level option, exiting the dialog (click OK) and then re-checking both, results in the first row (Anlage) being separated from the rest of the table, but all rows are then displayed. Re-saving to DOC, closing, and re-opening preserves this in LO (tested using v4.2.6.3, v4.3.2.2, and v4.4.0.0 2014-09-25 x86_64 deb). In MSO2007 these re-saved copies then strangely render as expected, so at least this offers a pseudo-workaround.
Comment 11 Owen Genat (retired) 2014-09-29 03:30:55 UTC
Created attachment 107036 [details]
DOC edited in LOv4263 to reset table and row breaking options

This copy renders as expected under MSO2007, but the first row (Anlage) is rendered under LOv4.2+ as separated from the rest of the table.
Comment 12 Timur 2015-08-25 17:21:07 UTC
*** Bug 49445 has been marked as a duplicate of this bug. ***
Comment 13 Timur 2015-08-25 17:48:11 UTC
Original behavior changed. All 35 rows are now displayed, but the table is cut off below item 2 on pg 3 and continues at item 3 on pg 4.

As noted, it's easy to fix with "Allow table to split accross pages and columns" via Text Flow tab in the Table Properties dialog.
The corresponding checkbox is checked for the third table; unchecking it fixes the problem. Then it can be checked back again. 
Even deleting item 3 with undo merges the table.
Re-saving to DOC, closing, and re-opening (in newer LO) doesn't repeat the same problem. 

So, I would close this as WFM and for example monitor more complex problem in Bug 62613. Or open a new bug with a proper explanation.
Comment 14 Timur 2015-12-03 14:58:43 UTC
Created attachment 120995 [details]
Screenshot showing diferent LO rendering

My previous comment related to the changed behavior, but it's back again.
Comment 15 Robinson Tryon (qubit) 2015-12-09 18:30:00 UTC Comment hidden (obsolete)
Comment 16 Justin L 2017-01-19 19:33:08 UTC
(In reply to Timur from comment #14)
> Created attachment 120995 [details]
> Screenshot showing diferent LO rendering
code pointers:
Transition from 4.4 to 5.0 was from https://cgit.freedesktop.org/libreoffice/core/commit/?id=b7fff04ad728369a09a5e1a5cfbe494cf388317b
commit b7fff04ad728369a09a5e1a5cfbe494cf388317b
Author: Caolán McNamara <caolanm@redhat.com>
CommitDate: Tue Apr 7 21:09:05 2015 +0100
        Resolves: tdf#90504 0x7 chars in .doc are not always cell/row ends

Transition from 5.0 to 5.1 was probably right around the 5.1/5.2 transition point and I don't have a bibisect for that.  Perhaps from the same bug 90504 which has some reverts going into 5.1
Comment 17 Timur 2018-07-19 10:17:41 UTC Comment hidden (obsolete)
Comment 18 Justin L 2018-07-24 18:04:22 UTC Comment hidden (obsolete)
Comment 19 Justin L 2018-07-24 18:13:00 UTC Comment hidden (obsolete)
Comment 20 Timur 2018-08-30 13:38:55 UTC
This document was 3 pages, then 22 pages from LO 6.0 to LO 6.2+, then fixed in Bug 116872 and Bug 119458 (thanks Justin). Now we are back with master to the original issue.
Comment 21 QA Administrators 2019-09-02 09:28:32 UTC
Dear suedsauerland,

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