Created attachment 95142 [details] Image reproducing the issue This is an issue reported to a local users forum and reproduced with various versions of most users. To reproduce: 1. create a new Writer document 2. intert the attached file into the document. Expected result: a document showing that imagee. Actual result: a document with a black square. Various tweaks to the image will render it usable. Not exactly sure which.
Reproducible, tested using Mac OSX 10.9 with LibreOffice Version: 4.2.2.1 Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f
Also reproducible tested using Mac OSX 10.9 with LibreOffice Version: 4.1.5.3 Build ID: 1c1366bba2ba2b554cd2ca4d87c06da81c05d24
Reproducible under Fedora with 4.2.1 build from libreoffice.org, but not with the build from Fedora repositories (of the same version). One difference that I see is that the former was built with '--without-system-jpeg', see http://opengrok.libreoffice.org/xref/core/distro-configs/LibreOfficeLinux.conf#10.
Created attachment 111044 [details] Another image triggering the bug (in .zip file)
Every program of the suite (Writer, Draw, Calc, Impress...)is not able to open this image correctly, but only a black square appears. I am experiencing the same issue on Libreoffice 4.3.4.1 on Windows 8.1 x64. I have attached another image triggering the bug (in a zip file). If the image is opened with an image editor and saved again, the newly created image is opened correctly, so it's something specific to the format of these images.
still reproducible under Win8.1 x64 using LibO 4.4.3.2 and recent 5.1.0.0 alpha daily build it seems a very old regression... I can reproduce it too on LibO 3.5.0 but not in LibO 3.4.6
(In reply to Maxim Monastirsky from comment #3) > Reproducible under Fedora with 4.2.1 build from libreoffice.org, but not > with the build from Fedora repositories (of the same version). > > One difference that I see is that the former was built with > '--without-system-jpeg', see > http://opengrok.libreoffice.org/xref/core/distro-configs/LibreOfficeLinux. > conf#10. It also does not occur with the LibreOffice version shipped with Debian Jessie (Version: 4.3.3.2, Build ID: 430m0(Build:2)) bibisect result (using the bibisect-43all repository): 5da527e58c09a5e88e94b73289c2cc15c32b851e is the first bad commit commit 5da527e58c09a5e88e94b73289c2cc15c32b851e Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue Apr 24 20:01:19 2012 +0200 source-hash-9a8d7e2a3f41f9e1c39c5634714a3a2b21776670 commit 9a8d7e2a3f41f9e1c39c5634714a3a2b21776670 Author: Luboš Luňák <l.lunak@suse.cz> AuthorDate: Thu Dec 8 16:33:22 2011 +0100 Commit: Luboš Luňák <l.lunak@suse.cz> CommitDate: Thu Dec 8 16:36:19 2011 +0100 add docx starmath testing documents It's simply a bunch of documents with various math features in them. It'd be nice to have an automated test built on top of them that checks the formula is the same (roughly, in the meaning, it can't be precise because import adds e.g. extra {}'s) after an export+import roundtrip. :100644 100644 70dfab35f16f30a2c2b97a32e92f6ebff188f4a4 ea95fe97e43b16b1fdb7ca5cff03bfb2dd94f21b M autogen.log :100644 100644 57029d0a394a4ec9f3cdc15a71cbaec65c90a55f f4d33ca8c705b891284fd45b42723573d5b777ec M ccache.log :100644 100644 288e6c9cf04b39bd7c342c2214d1934df0abfd89 00467179a23368572a5fe6d5a81cfa7a286ddf16 M commitmsg :100644 100644 0a7e1faf4c31b2d58fc5a86b7131a2cc9a9899d9 e8662d50fcf81076ca9917c1820bbbbdb03782d2 M dev-install.log :100644 100644 0e2d907381ecc68712660a9dcf633d0c2ec9080a f1be889d147387181bc9a11a18e62efadb66d430 M make.log :040000 040000 528453660be68a258459036a41ffb5c7e3cf8046 4405e99f642f7be21ed5711f128078a02d987d6d M opt --- $ git bisect log # bad: [a71a4447320f177181c9cff9f7c6fd93802cbd8e] source-hash-9afb6e1e38c362a768e8e981f7b03cf8bcaf22cf # good: [cf86b7f14a98d2d81a5cd93507acb35ff6775d8b] source-hash-85c6244b85b29c1d2bb9d89b62e9512dd65378b5 git bisect start 'last36onmaster' 'last35onmaster' # bad: [5071c2206541a2db45ead3ead86da2de873fa2c2] source-hash-b36a42fb831b853120928e05dcf322898a92a731 git bisect bad 5071c2206541a2db45ead3ead86da2de873fa2c2 # bad: [e1ed92feeeb51078dcf7ab6d30e080321609049d] source-hash-ba8918aebd2b9f030e0fd684accc9bf21bd1eac3 git bisect bad e1ed92feeeb51078dcf7ab6d30e080321609049d # bad: [c2511d0f8524babacf90c6c2060a66fc2c8ac919] source-hash-4eedf5dc54ab19af39d7033462421082d1abb86d git bisect bad c2511d0f8524babacf90c6c2060a66fc2c8ac919 # bad: [d202b17d88ecb0b608d81518624021c832c7dfdb] source-hash-ce97851773a06103504972eb2771eecd7dd81e36 git bisect bad d202b17d88ecb0b608d81518624021c832c7dfdb # bad: [0641af017cb9ec5ecca3eb879dded60fadf3ac78] source-hash-a1b970a10e00b34ab6d8608cb02247b8f0195573 git bisect bad 0641af017cb9ec5ecca3eb879dded60fadf3ac78 # bad: [5da527e58c09a5e88e94b73289c2cc15c32b851e] source-hash-9a8d7e2a3f41f9e1c39c5634714a3a2b21776670 git bisect bad 5da527e58c09a5e88e94b73289c2cc15c32b851e # first bad commit: [5da527e58c09a5e88e94b73289c2cc15c32b851e] source-hash-9a8d7e2a3f41f9e1c39c5634714a3a2b21776670
Similar bug in Draw, persisting into 5.0.1.2. I have scads of draw files I can't use because of this bug. I reported it a year ago, but was unable to provide examples because of file size issues.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
The original 879888-byte JPEG is truncated to 57344 bytes upon insertion.
*** Bug 95431 has been marked as a duplicate of this bug. ***
@Tomaž, The two JPEG images here and the one in dupe bug 95431 are all manifesting the same way. On insert or open into any module, the first lines of the image are brought in, and then the rest goes bad--and the entire image shows up black on canvas. Looking at the image recorded into a saved ODF archive's Pictures directory you can see the first lines of the raster before they are cut off. I tried several times, but I could not get any kind of stack trace as the the image is imported without any error I could track, and I tried to follow it with Process Monitor but could not isolate the insert image--but something does seem wrong in importing these three JPEGs. Any time to look at it?
If I remove the configure flag --with-jpeg8 from our embedded libjpeg then this image works, with it in place again it doesn't work. Which is a little odd so there's something about jpeg8 support in libjpeg-turbo/libjpeg8 which causes this.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0c1fdff3efbb16836d679923828ebd7dda03b937 Resolves: tdf#75788 build jpeg-turbo without --with-jpeg8 It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bfc270b86bb74a087c09caf318d5a4d1a38afa0f&h=libreoffice-5-4 Resolves: tdf#75788 build jpeg-turbo without --with-jpeg8 It will be available in 5.4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.