<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Some animated gif files do not loop infinitely when inserted in the presentation" href="https://bugs.documentfoundation.org/show_bug.cgi?id=90262#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Some animated gif files do not loop infinitely when inserted in the presentation" href="https://bugs.documentfoundation.org/show_bug.cgi?id=90262">bug 90262</a> from <a class="email" href="mailto:alexhfromnorthholland@gmail.com" title="Alex H. <alexhfromnorthholland@gmail.com>"> Alex H.</a> <pre>The CERN download links no longer work, but I can confirm that for the April 2015 attachment, Impress loops only once. (This is with a self-built 6.1.0.0.alpha0+ on Windows 10.) However, I have reason to believe that that GIF does not comply with the standard. I don't know how authoritative this is, but on <a href="http://giflib.sourceforge.net/whatsinagif/bits_and_bytes.html">http://giflib.sourceforge.net/whatsinagif/bits_and_bytes.html</a> it says: "The Netscape 2.0 looping block must appear immediately after the global color table of the logical screen descriptor." That is not the case with this GIF; the Netscape extension appears much later. In the reader (libo-core\vcl\source\filter\igif\gifread.cxx), there is this: if( aAnimation.Count() == 1 ) { aAnimation.SetDisplaySizePixel( Size( nGlobalWidth, nGlobalHeight ) ); aAnimation.SetLoopCount( nLoops ); } so what happens is that nLoops is processed only when the bitmap for the first animation frame is created. For this GIF, nLoops is the default 1 at this point, because the Netscape extension has not been seen yet. I can confirm, on the other hand, that Firefox 57.0.3 does loop infinitely here, so perhaps LibreOffice is wrong. Again, I'm not sure about what the standard requires.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>