Created attachment 141879 [details] sample doc Steps to reproduce: 1. Open attached document 2. Check the floating table on the bottom Observed behaviour: it's displayed in the middle of the page, while it should be displayed on the bottom Reproduced in Version: 6.1.0.0.alpha1+ Build ID: f1579d3d6c5f5f3a651825e035b93bee7a4f43c6 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Regression introduced by: author Mike Kaganski <mike.kaganski@collabora.com> 2018-02-07 01:03:32 +0300 committer Mike Kaganski <mike.kaganski@collabora.com> 2018-02-07 07:23:57 +0100 commit 76d6fcd05c630a928dd3bd028d560792d9c904ca (patch) tree 06bf8a8b6b8e48a0511d0f99bd2930baa77aba84 parent 9751a273747a2a6ba80c8b2e6012d788eee7c461 (diff) tdf#114217: Consider relative width when importing floating table Unit test included Bisected with: bibisect-linux64-6.1 Adding Cc: to Mike Kaganski
Created attachment 141880 [details] comparison MSO 2010 and LibreOffice 6.1
** 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
Bug still manifests with: Version: 6.2.3.2 Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk3; Locale: he-IL (en_IL); UI-Language: en-US
This looks like a somewhat unique version of bug 80717
Perhaps it is best to just not inline a table positioned "at bottom".
(In reply to Justin L from comment #6) > Perhaps it is best to just not inline a table positioned "at bottom". or maybe even generally positioned relative not to paragraph, but to page margins...
No repro in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5cd9de202765e243e41416802f3e4486b8a96f16 CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL threaded bottom table is in bottom part of page now closed as WFM
(In reply to Roman Kuznetsov from comment #8) Did something get relevant get committed recently? Since with a 7.6 build from March 2023, I'm still seeing the bug manifest.
(In reply to Eyal Rozenberg from comment #9) Of course - the massive amount of change seen at https://gerrit.libreoffice.org/q/owner:vmiklos%2540collabora.com+sw+floattable and https://gerrit.libreoffice.org/q/owner:vmiklos%2540collabora.com+sw+floatable with the recent commits from April enabling this stuff by default.
Seen from: author Miklos Vajna <vmiklos@collabora.com> 2023-04-12 08:13:07 +0200 committer Miklos Vajna <vmiklos@collabora.com> 2023-04-12 09:12:17 +0200 commit ce3308a926f036b87515b8cd97d2b197063dc77a (patch) tdf#61594 sw floattable: import floating tables as split flys by default Fixed with: commit d477fa8ac1b0d3ee81427217bbb5950278ab16db [log] author Miklos Vajna <vmiklos@collabora.com> Fri Mar 17 14:00:17 2023 +0100 committer Miklos Vajna <vmiklos@collabora.com> Fri Mar 17 14:10:34 2023 +0000 tree eff80bbdb718f81b11e0c7eb5c96dbf2f96508df parent 57914a4084da9107ec6815b1916a4be117c400bf [diff] sw floattable: unconditionally map <w:tblpPr> to SwFormatFlySplit Fix the problem by never going via m_aPendingFloatingTables in the SW_FORCE_FLY_SPLIT=1 case, since that was only a workaround for layout limitations. This conditionally reverts commit 78d1f1c2835b9fae0f91ed771fc1d594c7817502 (fdo#68607 bnc#816593 DomainMapperTableHandler: don't always start a frame, 2013-09-03). Also add a SwModelTestBase::FlySplitGuard, so it's just a one-liner change to test the SW_FORCE_FLY_SPLIT=1 case from cppunit. The goal is to have this on by default once it's mature enough.