Created attachment 59581 [details] The Word DOC On the side 3 of the Word document I miss the line 1 to 4.
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?
INVALID. No response about the requested info for over a year.
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.
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.
Ok sorry, now I understand. Confirmed:4.2.0.3:OSX then and thanks for clarifying.
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
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
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.
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
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.
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.
*** Bug 49445 has been marked as a duplicate of this bug. ***
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.
Created attachment 120995 [details] Screenshot showing diferent LO rendering My previous comment related to the changed behavior, but it's back again.
Migrating Whiteboard tags to Keywords: (possibleRegression)
(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
This document was 3 pages, but is 22 pages from LO 6.0 to LO 6.2+.
3pages -> 22 (empty pages at the end not reclaimed) Testing with Ubuntu 16.04 and bibisect-dbg-60 as well as bibisect-linux-6.0 point to committer Jan-Marek Glogowski commit d7a2fd3e8262b8897ad06f01f25f46330e050e0c tdf#109123 Change SwDocIdle base class to Idle This hides SwDocIdle from SalInstance::AnyInput( VCL_INPUT_ANY ) on Windows. Otherwise Writer assumes there is more stuff to do, as it can't know the scheduled Windows event is just for itself, resulting in a busy loop, which freezes Writer. Change-Id: I919c40e8e1673eb09a69a3084203d1c4a6ecac8a Reviewed-on: https://gerrit.libreoffice.org/40189
(In reply to Justin L from comment #18) > commit d7a2fd3e8262b8897ad06f01f25f46330e050e0c That's bug 117538
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.
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
This one would have to be a layout bug. I would guess some problem around #13. The document really hangs for a number of sections every time I scroll up to reveal that section.
Created attachment 172324 [details] The Word DOC saved in Word as DOCX Let's keep here DOCX from MSO with similar issue. Seen in 7.2+.
repro 7.6+ (even after many floating table fixes have landed).
repro 7.6+ with both DOCX and DOC. Miklos - since your mind is already in this area of tables and layout, perhaps you are interested in looking at this bug. This is NOT a floating table.