Created attachment 102018 [details] Original DOC file, resulting ODT, screenshots Problem description: When importing the attached DOC file attached, the gap between the 3rd and the 4th row of the table is not respected. In the original DOC, the gap is 5 mm high. In the imported ODT, the gap is 5 cm high. Steps to reproduce: 1. Open the attached DOC. Current behavior: The gap is 5 cm high. Expected behavior: The gap height should be the same as in the original DOC file. (Previously commented in bug 80635.) Operating System: Windows 7 Version: 4.1.5.3 release
Confirmed on Linux Mint in 4.1.6 and 4.3.0. In 4.1, the space between tables shrinks, while in 4.2 and above it expands. The second table is in the correct position in 4.0.6, but the first table isnt present. This issue maybe the byproduct of the tables going over the page width mentioned in bug 80635.
the spacing is tiny since the de-floating of the table with commit 8fe8bd6c3b5b1a539b7370f8c457fa69c061d2de the 5 cm gap comes from: commit 9d981abc3f310adf9af3454dd515ea356b31d3c1 Author: Miklos Vajna <vmiklos@collabora.co.uk> AuthorDate: Mon May 26 12:04:39 2014 +0200 bnc#863018 WW8 import: fix upper margin of multi-page floating table
(This is an automated message.) It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.) Thus setting keyword "bisected".
This issue is still present in Version: 5.0.1.2 Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale: es-ES (es_ES) on Windows 7 (64-bit)
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
adding filt:doc keyword.
I'll close as a duplicate of Bug 80635. It's "SPACING not imported properly". Spacing is table spacing, i.e. position. Here it's both left and above. They can be changed manually in the 2nd table and it's correct then. Yes, one bug per report, but table spacing is one bug, and not separate for left, above... *** This bug has been marked as a duplicate of bug 80635 ***
Returning to NEW as Michael's bibisect in bug 80635 is different than his bibisect here.
Adding Cc: to Miklos Vajna
** 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
Created attachment 146446 [details] Original DOC file, without protection In Version: 6.2.0.0.alpha1+ (x64) Build ID: 4201779de7441c03fbf0fea665d17ed2328970cc There is still no gap between the 3rd and 4th row.
Created attachment 146486 [details] DOC compared MSO LO 4.2 LO 6.2+ Floating tables - wrap around. 1st table: vertical 0,01 cm relative to paragraph, move with text, same position as in MSO 2nd table: vertical 5,26 cm relative to page, position not same as in MSO
I created a stripped down version for testing: attachment 146504 [details] I also, spun off the 2 page import issue into Bug 121318
The .docx format is also affected by this bug. You can verify this with attachment 146507 [details], a stripped down version of the bugdoc saved as .docx in Word 2016.
Dear Marc PHILIPPE, 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
The gap is seen for both .doc and .docx in the latest master for 7.0. I don't have an updated bibisect to determine exactly what fixed it though.
(In reply to Justin L from comment #16) > The gap is seen for both .doc and .docx in the latest master for 7.0. I > don't have an updated bibisect to determine exactly what fixed it though. Not seen in the latest bibisect. Not seen on another computer compiling the code, or even on this computer in another build directory. No longer seen after clearing my user profile. Very strange.
Fixing this will take a lot of wizardry, to identify the location on the page where the table is in-lined, and then calculate how much margin to add to the top to push it down to the correct position. Similar feats are needed especially for left, but also for right. Then the same can be done for left/right for paragraph-anchored tables, as well as column-anchored tables. A nice try at wizardry was comment 2's commit at https://gerrit.libreoffice.org/c/core/+/9487/2/sw/source/filter/ww8/ww8par6.cxx However, it did not account for the current, inlined position and so was reverted... Identifying the current position is approximately impossible, since that depends on the layout - which of course we do not have during import.
*** Bug 94950 has been marked as a duplicate of this bug. ***
*** Bug 94955 has been marked as a duplicate of this bug. ***
> Identifying the current position is approximately impossible, since that depends on the layout - which of course we do not have during import. We already have bug 61594 for the case where floating tables can't be tweaked import-time and true layout support is needed, should we close this as a duplicate, then?
(In reply to Miklos Vajna from comment #21) > We already have bug 61594 for the case where floating tables can't be > tweaked import-time and true layout support is needed, should we close this > as a duplicate, then? I don't think we should mark it as a duplicate of that one. That one is specifically talking about tables that should or should not be floated. This bug report is talking about tables that HAVE ALREADY been inlined, but where the table isn't vertically positioned correctly. I guess you could argue that in these cases it shouldn't be inlined then. But that will be a very subjective call based on each individual document's characteristics.
Hmm right. But then this is not a regression, rather a missing functionality. Adjusting keywords accordingly. In any case, thanks for looking into this!
*** Bug 129359 has been marked as a duplicate of this bug. ***
*** Bug 131735 has been marked as a duplicate of this bug. ***
*** Bug 143743 has been marked as a duplicate of this bug. ***
*** Bug 143729 has been marked as a duplicate of this bug. ***
Probably each of the duplicates here will need to be re-assessed one by one. comment 11's GE Bilokin Nadia-fixed.doc had the first table hidden by 7.6's commit 61be351ac83acec75788d2f79a9038486163160f Author: Miklos Vajna on Thu Apr 20 08:13:12 2023 +0200 sw floattable: import floating tables from DOC as split flys by default And hidden paragraph's are likely related to the spacing difference between the tables as well. If I turn on Tools - Options - Writer - Formatting Aids - Hidden Characters, and remove the hidden paragraph, then it looks right.
The description in 28 sounds identical to https://bugs.documentfoundation.org/show_bug.cgi?id=117447
Interesting fact: in MS Word 2010 these two .doc files take up two pages, while comment 12 shows it on one page. Hmmm - even more interesting is that the PDF that MSO2010 generates all fits on one page. (In reply to Justin L from comment #28) > Probably each of the duplicates here will need to be re-assessed one by one. Done > comment 11's GE Bilokin Nadia-fixed.doc had the first table hidden Fixed The DOCX version PageBug-new.docx (comment 14) looks fine in LO - one table follows the other (and spills over onto page 2). [In MSO2010, the second table splits in two, with only the first row showing up on page one as mentioned earlier.] The DOC version PageBug.doc (comment 13) looks more or less like MSO2010 - except that the second table doesn't split into two. However, all of this multi-page stuff was split off into bug 121318 which was marked as NOTOURBUG, and indeed this sounds like a Microsoft Bug since DOC files are opened differently by the latest versions of MS Word. I'm going to mark this as FIXED, since the subject and comment 0 complaint is fixed.
FWIW, Word layout has two modes: 1) Legacy floating table layout: this is used for DOCX compat mode <= 14 and DOC/RTF. This has weird rules, e.g. if you have a floating table that would fit the body frame but you move it down a little (so it overlaps with the footer), that's OK. 2) Newer floating table layout: this is used for DOCX compat mode >= 15 (i.e. new documents in Word 2013 and newer), this works in a more sane way, i.e. overlap with footer area is never allowed. GetFlyAnchorBottom() has the details of this on our side. I'm just writing this to make sure you don't confuse yourself when you would try a compat15 DOCX in Word 2010, which is probably a non-interesting rendering.