Issue 118881 - Animation not rendering properly in Impress (Build OOo340m1 for Windows)
Summary: Animation not rendering properly in Impress (Build OOo340m1 for Windows)
Alias: None
Product: Impress
Classification: Application
Component: editing (show other issues)
Version: 3.4.0 Beta (OOo)
Hardware: PC Windows XP
: P3 Blocker with 4 votes (vote)
Target Milestone: ---
Assignee: Andre
QA Contact: edoardopanfili
Keywords: needmoreinfo, regression
Depends on:
Reported: 2012-02-07 05:05 UTC by Michael
Modified: 2017-05-20 11:42 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
doudou1976: 3.4_release_blocker?


Note You need to log in before you can comment on or make changes to this issue.
Description Michael 2012-02-07 05:05:13 UTC
I've found a reproducible bug in Impress where the animation for an specific piece of text or object will not be rendered properly. In one of the error variants the user selects a text animation and when the user goes into full screen mode to watch the presentation the animation is not rendered. Even more bizarre is when the user sets text animations for two separate lines of text where only the bullet or number will be animated while the text will remain static.

The following is a video showing the issue and how is reproduced:

My system uses Windows XP SP3 and the Apache OpenOffice Beta is build OOo340m1.

Thanks for your assistance.
Comment 1 zhao xia 2012-02-27 08:06:37 UTC
I confirm I can reporudce this defect against Windows XP SP3, AOO-DEV, Rev.1240836
Also I propose this one as 3.4 release blocker as this is one key scenario for impress users
Comment 2 zhao xia 2012-02-27 11:06:29 UTC
Verify this issue against oo 3.3, this is regression against AOO 3.4
Comment 3 Andre 2012-03-01 12:25:37 UTC
Taking over.
Comment 4 Andre 2012-03-01 17:00:06 UTC
The first piece of the puzzle:
The bullets that start each paragraph are now interpreted as a single paragraph.  Therefore each paragraph is interpreted by the slideshow as two paragraphs.  As a result the association of animations to paragraphs is screwed up.

The bogus paragraph information comes from the metafile that is used by the slideshow to split text of shapes into paragraphs, lines, and words.  Whether this comes from changes to the metafile, the bullet handling, or a combination of the two is not yet clear.
Comment 5 Andre 2012-03-02 10:49:52 UTC
I have traced this bug through metafile creation and primitive decomposition to its source in the edit engine.  For bug 108052 an older behavior was reactivated that did not optimize away empty paragraphs (this is important for the slide show that uses paragraph indices to associate animations with text portions; when the indices are off, then the wrong parts of text are animated).

The downside of this fix is, that the space between bullet and text is interpreted as paragraph.  This screws up the paragraph indices and finally leads to wrong associations of animations and text portions.  Similar to the very problem that this fix makes go away.

I still have to figure out how to fix one without breaking the other.
Comment 6 Andre 2012-03-02 13:56:55 UTC
Fixed this in ImpEditEngine::Paint() by ignoring empty paragraphs that come directly after bullets.  This is kind of hackish but for a better fix one would have to really understand the edit engine.
Comment 7 Li Feng Wang 2012-09-14 09:18:28 UTC
can't open the video link,  don't know the reproduce steps to verfiy it.
Comment 8 edoardopanfili 2013-07-10 13:00:16 UTC
Verified in:

OS X 10.8.4:
AOO400m3(Build:9702)  -  Rev. 1499347
2013-07-03 14:06:53 (Wed, 03 Jul 2013)
and in
Windows 8
AOO400m3(Build:9702)  -  Rev. 1499347
2013-07-03 15:11:47 (Mi, 03 Jul 2013)

(works correctly also in 3.4.0 r 1327774)