Download it now!
Bug 132282 - FILEOPEN PPTX: Titles rendered vertically instead of horizontally
Summary: FILEOPEN PPTX: Titles rendered vertically instead of horizontally
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All All
: high major
Assignee: Xisco Faulí
URL:
Whiteboard: target:7.0.0 target:6.4.5 target:6.4.4
Keywords: bibisected, bisected, filter:pptx, regression
: 132391 (view as bug list)
Depends on:
Blocks: PPTX
  Show dependency treegraph
 
Reported: 2020-04-20 21:36 UTC by Gerald Pfeifer
Modified: 2020-05-06 08:32 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Simple PPTX document (1020.80 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2020-04-20 21:36 UTC, Gerald Pfeifer
Details
This is how it should look (33.92 KB, image/png)
2020-04-20 21:37 UTC, Gerald Pfeifer
Details
This is how it looks in LO 7.0.0.0.alpha0 (25.60 KB, image/png)
2020-04-20 21:38 UTC, Gerald Pfeifer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald Pfeifer 2020-04-20 21:36:46 UTC
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.
Comment 1 Gerald Pfeifer 2020-04-20 21:37:55 UTC
Created attachment 159772 [details]
This is how it should look
Comment 2 Gerald Pfeifer 2020-04-20 21:38:52 UTC
Created attachment 159773 [details]
This is how it looks in LO 7.0.0.0.alpha0
Comment 3 Julien Nabet 2020-04-21 09:32:31 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.
Comment 4 NISZ LibreOffice Team 2020-04-21 12:43:15 UTC
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
Comment 5 Xisco Faulí 2020-04-28 12:43:22 UTC
*** Bug 132391 has been marked as a duplicate of this bug. ***
Comment 6 Commit Notification 2020-04-28 13:51:57 UTC
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.
Comment 7 Gerald Pfeifer 2020-04-29 23:09:53 UTC
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.)
Comment 8 Xisco Faulí 2020-04-30 07:59:46 UTC
(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
Comment 9 Commit Notification 2020-05-01 15:57:45 UTC
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.
Comment 10 Commit Notification 2020-05-06 08:10:57 UTC
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.
Comment 11 Gerald Pfeifer 2020-05-06 08:26:14 UTC
(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)?
Comment 12 Xisco Faulí 2020-05-06 08:32:42 UTC
(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