In "Auto" slide show mode (Slide Show > Slide Show Settings under Type) there is a box to set a delay time when reaching the end of a presentation before looping back to the beginning. I want to set this to 0 seconds, however when the file is opened in PowerPoint (which it frequently is - we create slideshows in PowerPoint before they're used on a digital sign system powered by LibreOffice) and saved, it defaults back to 10 seconds. Is there any way you can set the default pause time to 0 seconds please?
From the description this is NOTOURBUG - if I understand you correctly you create a slideshow in LibreOffice and set the timing to 0, you save and close it. If you reopen this slideshow in LibreOffice immediately then the timing is still 0, if you open it with PowerPoint and then save, the timing changes back to 10. Is this correct? We're not going to change the default timing to 0 - better to figure out why the timing isn't sticking - or to figure out at least if it's even our bug or not
Yes that is correct.
Yes then this is Microsoft overwriting something if you can reopen in LibreOffice and it still shows 0 - it's something about MSO screwing up the timing. Marking as NOTOURBUG. Thanks for the input - apologies that we couldn't do more.
If, from Impress, I save a presentation in .ppt format then the wait time will go back to 10 sec when I reopen it in Impress. This problem does not arise if I choose to save the file in .odp. I guess Impress is not writing the .ppt file properly?
Saving to .odp works ok. Saving to .ppt sets it to 10 sec. Saving to .pptx sets the type back to default! Win 7 64-bit Version: 4.4.0.0.alpha2+ Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827 TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08
** 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.0.4 or later) 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 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
** 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.6 or 5.2.3 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-20170103
This is definitely a bug - or maybe several bugs: 1. In ODF: since PowerPoint seems to not support the pause option in presentations, it simply ignores any value set in presentation:pause attribute [1], and doesn't write it back to ODF. But LibreOffice treats the missing attribute as its "default" 10 s, which is incompliant to the standard which requires that missing attribute be treated as if 0 s pause duration was set. 2. In external formats (namely, PPT), it introduces the (default) delay of 10 s absent in the PPT. The problem is likely remedied simply by replacing the default of 10 s by 0 s in PresentationSettings::PresentationSettings() [2]. [1] http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1417722_253892949 [2] https://opengrok.libreoffice.org/xref/core/sd/source/core/drawdoc.cxx?r=e2d2a338#97
See also bug 47365 comment 5.
https://gerrit.libreoffice.org/68190
The change in comment 10 will also change the default delay in new presentations (when no template is used) from 10 s to 0 s. I don't think it's a problematic change, but still want to inform UX people about the change.
Zero has the side effect of missing feedback at the end. Test scenario (far-fetched) is one slide where you can click to end which starts over again. Not a big deal, and we always help users with their MS issues ;-)
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/bde5a8623262e50c12a073eb5a78c95211a650a3%5E%21 tdf#61679 tdf#83247: default presentation pause should be 0 s It will be available in 6.3.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.