Created attachment 159771 [details] Simple PPTX document This is a regression between LibreOffice 6.4.3.2 and 7.0.0.0.alpha0, specifically broken in Version: 7.0.0.0.alpha0+ Build ID: 1289ef10406e00d0fc9abc5bca444d026ab21743 CPU threads: 4; OS: Linux 5.6; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master Instead of the titles in this document rendering normally (= horizontally) text flows vertically from top to bottom, also offset a bit sideways.
Created attachment 159772 [details] This is how it should look
Created attachment 159773 [details] This is how it looks in LO 7.0.0.0.alpha0
On pc Debian x86-64 with master sources updated today, I could reproduce this.
Bibisected to: https://cgit.freedesktop.org/libreoffice/core/commit/?id=69b83dc2d3014dd9b18402534e15c937dc082464 author nd101 <Fong@nd.com.cn> 2020-03-25 13:17:48 +0800 committer Michael Stahl <michael.stahl@cib.de> 2020-04-01 10:20:26 +0200 tdf#131554 placeholder iteration fails to stop when a match is found
*** Bug 132391 has been marked as a duplicate of this bug. ***
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5750be8cf82b6933cb0b44ffe5ad307da1b4a0eb tdf#132282: Revert fix for tdf#131554 It will be available in 7.0.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.
Thank you, Xisco! Given that this and bug #132391 (which appears to have the same root cause even if the failure is quite different) managed to sneak through our regression tests in the first place, shouldn't we get tests for these two? (Happy if you want to use my test cases from those two bug reports, just over my head to add those myself.)
(In reply to Gerald Pfeifer from comment #7) > Thank you, Xisco! > > Given that this and bug #132391 (which appears to have the same root cause > even if the failure is quite different) managed to sneak through our > regression > tests in the first place, shouldn't we get tests for these two? > > (Happy if you want to use my test cases from those two bug reports, just over > my head to add those myself.) Hi Gerald, actually I haven't run the interoperability test for 1 month or so. I'm rewriting it into python to make it multiprocessing and it's taking some time. I hope I'll finish it this week. See https://github.com/x1sc0/office-interoperability-tools/commits/master
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/7df4ebf9a658681d02842b14187722ae8161cd7e tdf#132282: Revert fix for tdf#131554 It will be available in 6.4.5. 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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-6-4-4": https://git.libreoffice.org/core/commit/3b9283880e8d53c5cbc0eabc1c9119ff673b422c tdf#132282: Revert fix for tdf#131554 It will be available in 6.4.4. 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.
(In reply to Xisco Faulí from comment #8: > actually I haven't run the interoperability test for 1 month or so. I'm > rewriting it into python to make it multiprocessing and it's taking some > time. I hope I'll finish it this week. Sorry, I have not been clear I'm afraid. My concern is that those two issues (this bug #132282 and bug #132391) materialized without having been caught by our testsuite. Now reverting the commit that caused both of them fixes those two issues, but is there a safety belt in place? (For example, if someone re-applied that commit, reverting the revert, would anything flag this as an issue.) Naively I would expect for there two be two testcases added, one for this bug #132282 and one for bug #132391 to tighten the net and increase our test coverage. Does this make sense (or am I missing something)?
(In reply to Gerald Pfeifer from comment #11) > (In reply to Xisco Faulí from comment #8: > > actually I haven't run the interoperability test for 1 month or so. I'm > > rewriting it into python to make it multiprocessing and it's taking some > > time. I hope I'll finish it this week. > > Sorry, I have not been clear I'm afraid. > > My concern is that those two issues (this bug #132282 and bug #132391) > materialized without having been caught by our testsuite. > > Now reverting the commit that caused both of them fixes those two issues, > but is there a safety belt in place? (For example, if someone re-applied > that commit, reverting the revert, would anything flag this as an issue.) > > Naively I would expect for there two be two testcases added, one for this > bug #132282 and one for bug #132391 to tighten the net and increase our > test coverage. > > Does this make sense (or am I missing something)? Hi Gerald, If you see my commit < https://git.libreoffice.org/core/+/5750be8cf82b6933cb0b44ffe5ad307da1b4a0eb%5E%21 >, I reverted the code added in https://git.libreoffice.org/core/+/69b83dc2d3014dd9b18402534e15c937dc082464%5E%21/ but not its unittest. Besides, I added a new unittest for this ticket, so now there are 2 unittests, one for this issue and one for bug 131554. See https://opengrok.libreoffice.org/xref/core/sd/qa/unit/export-tests-ooxml2.cxx?r=ed8152b1#2816