Bug 48378 - FILEOPEN Table in DOC loses rows over page boundary (table does not commence on a new page)
Summary: FILEOPEN Table in DOC loses rows over page boundary (table does not commence ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version: 3.4.6 release
Hardware: All All
: high normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: Confirmed:4.2.0.3:OSX PossibleRegression
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-06 04:58 UTC by suedsauerland
Modified: 2014-09-29 03:30 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


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
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
Details

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 foss 2014-01-21 10:10:44 UTC
INVALID.

No response about the requested info for over a year.
Comment 3 foss 2014-01-21 10:11:43 UTC
I suggest if you still see this issue with LO 4.2.0.2 http://www.libreoffice.org/download/pre-releases/ to open a new bug report.

If you do that please use http://www.libreoffice.org/bug and make sure to provide all requested info.
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 foss 2014-01-23 22:00:04 UTC
Ok sorry, now I understand. Confirmed:4.2.0.3:OSX then and thanks for clarifying.
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 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 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
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 ?

Best regards. JBF
Comment 10 Owen Genat 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 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.