Created attachment 182036 [details] Example file Attached document contains some complex nested tables. When the document is exported to PDF from the command line, the table row containing "Important information here!" disappears. 1, soffice --convert-to pdf in_056132_mod.odt 2, Open resulting in_056132_mod.pdf in PDF viewer Happens in Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 27892a5e12dada80226f778ab2bd14b1bdaab58a CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded and 7.4, but not in older. Bibisected to: https://git.libreoffice.org/core/+/e7874c936dd1ff9b3423eb7477cbee2494535176 author Michael Stahl <michael.stahl@allotropia.de> Fri Feb 11 18:28:42 2022 +0100 committer Michael Stahl <michael.stahl@allotropia.de> Mon Feb 14 11:35:59 2022 +0100 sw: layout: fix overlapped table rows in --convert-to pdf which was for bug 147358.
Created attachment 182037 [details] The example file in Writer and its CLI PDF export in Evince Does not happen if it's exported via GUI.
It does not happen, if I remove the top table with "eee sss aaa" or the section or the nested table containing the 1.. 2.. 3.. numbers.
Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 465c3ad95059f0efa13c8027f7383c4d20a5b2ff CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded Excepted result: line removed NO REPRODUSE
Confirm with Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: e46f9cc4b506c325cbe1060777bbc81fd1630f49 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3acd80a030707b3c4795c0f828f953ac0ae24d97 tdf#150616 sw: fix bad 0 height of SwTextFrame in table cell It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/dc1f177b42658a5e02a2745545dba25203a81536 tdf#150616 sw: fix bad 0 height of SwTextFrame in table cell It will be available in 7.4.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This also happens in 7.3 branch. The commit which caused this regression was also cherry-picked to 7.3 (version 7.3.2.0.0+) https://gerrit.libreoffice.org/c/core/+/129845 Revise version field to 7.3.2.2 accordingly.
forgot to set this to FIXED i'd rather not backport the fix to 7.3 shortly before EOL