Open 3 pages DOCX attachment 71442 [details]. It's 2007 DOCX but same if resaved in MSO. LO opens 4 pages because 2nd page table is split to 3rd page. Upon click in title "Spørsmål for alle typer eiendommer", it comes back to 3 pages.
Bibisect in 6.0 for table split - click in title couldn't fix there. e5593290e3759d5cbe51a6a349d459651e3e6e81 is the first bad commit Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Jul 13 02:04:23 2017 +0200 source 25445d24cfa87522ee4c47e4aa7e6e816cdc9a36 previous source 87633bd4e3a1b37ccfe1ddf18f1f178b07092a0d commit 25445d24cfa87522ee4c47e4aa7e6e816cdc9a36 [log] author Miklos Vajna <vmiklos@collabora.co.uk> Tue Jul 11 12:44:56 2017 +0200 committer Miklos Vajna <vmiklos@collabora.co.uk> Tue Jul 11 15:23:58 2017 +0200 tree b4b88a2fb5c52f6a98fc527f1b65c41e0c7cb582 parent 87633bd4e3a1b37ccfe1ddf18f1f178b07092a0d [diff] tdf#109063 DOCX import: consider wrap space for multi-page floattables freedesktop.org doesn't work to check if this is really the only commit, but let's assume it is, I provided also the previous commit. CC: Miklos.
Another bibisect in 6.3 again for new table split, except this time click in title somehow joins the table. 4ea1db013d4b402c56758acc00182cf2702d31c0 is the first changed commit Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Sep 26 02:58:11 2019 +0200 source b0c5bc47d0d170df1384dd48cee9291ce6044083 previous source 92267cdb1a45e1f40199136849feb692f7e06d0e author Justin Luth <justin_luth@sil.org> 2019-09-24 19:39:29 +0300 committer Xisco Faulí <xiscofauli@libreoffice.org> 2019-09-25 11:56:54 +0200 commit b0c5bc47d0d170df1384dd48cee9291ce6044083 (patch) tree 280e4bbbeb3306c9c36a62e9c756a151c5e77766 parent 92267cdb1a45e1f40199136849feb692f7e06d0e (diff) Revert "tdf#117988 writerfilter: IgnoreTabsAndBlanksForLineCalculation" This reverts LO 6.2 commit 49ddaad2f3ba4e17e1e41e94824fb94468d2b680. tdf#127617 proves it simply was not the correct solution. CC: Justin. So, we have two great devs ("usual suspects") here in this mess.
This will be some kind of layout bug. Both of these commits will just have helped this particular docx trigger a certain condition that doesn't flow well. Neither one of these is truly a regression. I don't notice anything particularly strange about this table/surrounding parargraphs. There are no "keep with next paragraphs" involved. The only strange thing is the first and last row are combined columns (gridSpan) - which I would expect to be irrelevant. A few judiciously placed page break would have helped this document immensely. And whatever is happening with those as-character shapes probably isn't helping either.
Not sure if bug 128437 (or duplicates are somehow related). Some behavior, different bibisect results. Maybe because of DOCX <-> ODT?
Dear Timur, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Solved. Verified with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 35787e07b7e83f7dcaa0c67830fcb4eded49c71f CPU threads: 4; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Fixed with source c31267e23603c77e3a3335fa431bb9b74448d5b2 author Mike Kaganski <mike.kaganski@collabora.com> Sat Jan 21 2023 +0300 tdf#153128: do not increase line height, when ignoring whitespace I do not set duplicate as it did not look the same, this one was table.