Only applicable to download today (1 Nov 2016) of ver 18.104.22.168. Previous version worked well. Black square only applied to color pic. Adjacent B&W pic was OK
Could you retry w 5.1.6? http://www.libreoffice.org/download/libreoffice-still/
If the problem persists please provide precise reproduce steps as in
1. open writer and select menu xyz
2. ... etc
Also please add detailed information of which OS you are running.
After doing all that set the bug back to unconfirmed.
Can you save the document with the inserted pic, rename extension to .zip, unzip it, and check if the image stored in the zip is the same as the original or not? If the image in the zip appears black as well, then this is a duplicate of bug 75788.
I downloaded ver 22.214.171.124 - same result.
However - I noted that some similar pics inserted OK. I examined the differences and found the offending pic was modified with Photoshop to 600dpi. Other pics modified by Photoshop to 300dpi inserted OK
LibreOffice seems sensitive to the photo resolution.
Any comments about where the parameters may lie between success and failure?
Thanks for input
Could you do the steps outlined in comment 2, and report back with your findings?
Is the image the same file size (in bytes/KBytes) and appearance when extracted from a saved document, or it's smaller size, and appears black?
(In reply to Aron Budea from comment #4)
> Could you do the steps outlined in comment 2, and report back with your
> Is the image the same file size (in bytes/KBytes) and appearance when
> extracted from a saved document, or it's smaller size, and appears black?
I did try the zip idea, however I had to download Winzip and then try to unzip the renamed Libre file. It gave an error message:"Cannot open - not a valid archive" Would another zip product have succeeded?
I then changed the pic file to 300dpi and it was immediately inserted correctly.
I have since tried to re-create the scenario by creating the same pic again with 600dpi. Whenever I tried to insert this 600dpi file I got various messages as I tried different times: "Bad Allocation" - program crashed Then "Image filter not found" (no crash). Only once did I get a black rectangle, which was replaced when I tried to save it by a message inside the pic area "Read Error" and the black disappeared.
The large file size or high resolution seemed to be the sticking point. There must be some boundary parameters that cause the failure. I would like to know these so I can avoid too-large files in future. The previous version was not troubled, so maybe the new version can be modified in time.
Incidentally, I am now using ver 126.96.36.199 from Libre "Still Site". My system is Windows 10 on an MSI GE70 laptop.
Thanks for giving unzipping the file a try. ODF files are supposed to be correct zipped files, I have no idea why Winzip didn't want to open it (unless something went really, really wrong during save, but then LibreOffice would complain as well later).
I tried with some random 600dpi high resolution images from the internet, but unfortunately couldn't reproduce the bug with those.
Is there a chance you could share the JPEG? Or if it's not something to be shared, alter the image to make it unrecognizable, and see if it's still imported in the document erroneously.
Created attachment 128487 [details]
600dpi jpg pic apparently causing LibreOffice to malfunction
Part of my reply to Aron Budea's request.
(In reply to Aron Budea from comment #6)
> Thanks for giving unzipping the file a try. ODF files are supposed to be
> correct zipped files, I have no idea why Winzip didn't want to open it
> (unless something went really, really wrong during save, but then
> LibreOffice would complain as well later).
> I tried with some random 600dpi high resolution images from the internet,
> but unfortunately couldn't reproduce the bug with those.
> Is there a chance you could share the JPEG? Or if it's not something to be
> shared, alter the image to make it unrecognizable, and see if it's still
> imported in the document erroneously.
I thought I had replied but cannot see it in this page. In case it got lost I shall repeat it.
I always use the DOC or DOCX format rather than the Libre ODF format. Perhaps this could explain the abberations?
I have uploaded as an attachment, the jpg 600dpi pic that seemed to cause the variety of problems, crashes and the black square. The identical pic in 300dpi format was trouble free.
(In reply to Trevor Caldwell from comment #9)
> I always use the DOC or DOCX format rather than the Libre ODF format.
DOC is not a ZIP archive, but DOCX is. It doesn't seem to be relevant in the end, I tried to reproduce the issue with the attached image, but it looks fine here (which means it doesn't get corrupted in the document).
Can you do steps 2-3 from , and see if either of those matter? (one is about resetting user profile, the other is disabling OpenGL acceleration)
Step 1 - My system showed "UI Render: GL"
Step 2: I ticked the box "Use Open GL on restart"
I restarted LibreOffice and tried to insert the 600dpi file - a black rectangle ensued.
I then went back and unticked the box to return the system to what it was.
I think I have finished for now. I will just avoid any large jpg files. Shall I change the status to "resolved" or "unconfirmed" or just leave it as "needinfo"?
thanks for your input - a pity we didn't get to resolve it, but at least I have a work-around.
After I had sent my last comment I realised I hadn't unticked the Open GL acceleration. I went back in and did that. I then successfully inserted my 600dpi file. A modicum of success?
Are there any issues I could face by leaving the acceleration unticked? Or shall I re-tick it and just avoid large insert files in future?
Great, now we know the issue is caused by OpenGL acceleration. Having it turned off should be absolutely fine, the only drawback is slower UI if there are many and/or large images in the document. That might actually be relevant, but you can judge if it's significantly slower for you now, or workable.
There are two additional steps that would be interesting:
-as there aren't going to be further updates to version 5.1, test in 5.2 (5.2.3 is the current release at the moment) to see if the bug is still there,
-if the issue still occurs, the wiki page mentions an <user profile>/cache/opengl_device.log file containing information on the graphics device, attaching it to the bug report could help us finding an environment where the bug is reproducible.
If you could do that sometimes in the future, that'd be appreciated.
Sounds like tdf#103803
Indeed it looks very similar, thanks for the notification, Tomaz.
Trevor, I'm going to assume this is the same issue as bug 103803. If you're not using Intel graphics, please reset status to UNCONFIRMED. Otherwise the fix will be available as part of v5.2.4, expected to be released sometimes between December 19-25.
*** This bug has been marked as a duplicate of bug 103803 ***