In Impress, when applying an animation to a text element, the default grouping is always one *less* than the paragraph level present in the text item. This seems likely unintentional and undesired. Example: - In Impress, select a text box with 2nd level paragraphs. - In Custom Animation, click Add Effect (+) - Click "OK" (default Entrance: Appear) - Test the animation: text will appear by 1st level paragraph grouping. - In Custom Animation, right-click element > Effect Options > Text Animation > note it is currently listed as "By 2nd level paragraphs" (despite that not actually happening). - Now click on that same "By 2nd level paragraphs" in the drop-down menu, and click "OK" - Test the animation: text will now appear correctly by 2nd level paragraph grouping. Likewise: If you have only 1st level paragraphs, then all the text will appear at once. Or if you have 3rd level paragraphs present, then the default is to appear by 2nd level paragraphs. In each case, the default "Text Animation" lists the lowest-level grouping, but the animation actually does one less than that (until one manually clicks on the same lowest-level grouping for each animation element). I'm taking a stab that this is some classic off-by-one error. I suppose that this is somewhat related to bug 48553, in that if the choice was made to switch back to "one object" by default, then this bug would be irrelevant. Personally I like defaulting to the lowest-level paragraph, as shown in the default Text Animation -- but either way, the slideshow should not perform one less level of grouping than shown in the drop-down UI on creation.
Reproduced. A bulleted list with a 1st level entry and a 2nd level entry. Effect Options > Text Animation shows "By 2nd level paragraphs". Viewing the presentation shows both of the entries at once. Going back to effect options and clicking at the "By 2nd level paragraphs" again and OK, now the entries appear in order (1st, then 2nd level entry). Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 902255645328efde34ddf62227c8278e8dd61ff0 TinderBox: Win-x86@39, Branch:master, Time: 2015-07-30_03:52:07 Locale: en-US (fi_FI)
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
This bug is still present (Version: 5.3.7.2 (x64), on Windows 7 Home Premium Service Pack 1 64-bit). Behavior seems changed from first report. Currently on creating animation, animation is always by top level, although the interface claims it is by lowest level available (whether 2nd or 3rd level paragraphs, etc.)
This bug appears to have been fixed and the text grouping now works correctly. Specifically: when adding an animation for a text element, it defaults to grouping by the first level paragraph regardless of how many levels of paragraphs are present in the text. Testing on: Version: 6.2.1.2 (x64) Build ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71 CPU threads: 12; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded