Apache OpenOffice (AOO) Bugzilla – Issue 119176
ERROR: "Graphic Cannot be Displayed"
Last modified: 2017-05-20 10:32:06 UTC
Created attachment 77410 [details] SVG picture results in "Graphic Cannot be Displayed" error. SVG pictures result in "Graphic Cannot be Displayed" error. We have been testing SVG image usage in Apache OpenOffice 3.4.0 and have found that WRITER will sometimes replace an SVG picture with the "Graphic Cannot be Displayed" error. As an example, we tested the desired functionality in the Master: Apache OpenOffice 3.4.0 Build ID: AOO340m1(Build:9589) - Rev 1303653 On OSX 10.6.8 Steps to reproduce: 1. Locate the desired SVG picture (we used "med_dropper.svg") 2. Open a new WRITER Text Document 3. Select Insert -> Picture -> From File... (We selected "med_dropper.svg") 4. Click Open 5. Change to a different application (we went to Safari) and use it. 6. Click back on AOO. Expected results: SVG image will display without error. Actual results: Occasionally the SVG image is replaced with the "Graphic Cannot be Displayed" error. Please Note: This BUG appears to be an inconsistent error. However, we have duplicated it with different SVG pictures and different WRITER documents. This is a CRITICAL ERROR because when the error occurs then the inserted SVG picture(s) is/are unusable (all missing SVG pictures must be reinserted). The attachment includes sample data and screenshots: The "SVG and PNG dropper 01.png" screenshot shows two pictures. The top/larger picture is an SVG picture inserted with "med_dropper.svg" and the lower/smaller picturer is a PNG picture inserted with "med_dropper.png" The "SVG and PNG dropper 02.png" screenshot shows the top/larger SVG picture replaced with the "Graphic Cannot be Displayed" error. All pictures were inserted without using the "Link" option within the "Insert picture" window. See attachment for sample documents and screenshots.
I have seen this error too with AOO r1303653 on WinXP. I have noticed, that it happens after one of the autosave actions.
ALG: Already mentioned in #119165#, could not be stable reproduced until now. Already discussed with Oliver, but nothing concrete found, checked code today, too. I did some tests and checks. It is currently unclear if it has to do with svg (there is no special handling), I asked already for trying to reproduce with other graphics, e.g. png, no infos about this yet. Also sems to be limited to Writer (which has its own graphic object). Thus it would also be interesting if it could be reproduced with DrawingLayer GraphicObject; to check create graphic in draw or impress, copy/paste to writer.
I get not only "Graphic Cannot be Displayed" but crashes. I use AOO r1303653, multilingual, on WinXP. Try this: 1. Set the option "Save AutoRecovery information every" to 1 Minutes. 2. Close. 3. Start AOO. 4. Generate textdocument. 5. Insert > Picture > choose a svg-picture (or another, I have tested wmf and gif too) 6. Click besides the picture to leave selection. 7. _Wait_ for "Save AutoRecovery". It should be the _first save_ after generating the document. Crash. Repeat 2.-7., you should get a crash often enough to reproduce. In a self compiled AOO from January, I get the following errors in Debug window, when "Save AutoRecovery" starts, but the debug build does not crash. It might be related. Error: tried to set a wrong value on the progressbar Error: OutputDevice::ImplSelectClipRegion() - can't cerate region From File c:/AOO_Jan2012git/main/vcl/source/gdi/outdev.cxx at Line 209 Error: OutputDevice::ImplSelectClipRegion() - can't cerate region From File c:/AOO_Jan2012git/main/vcl/source/gdi/outdev.cxx at Line 209
ALG: Thanks Regina, the gif and wmf shows that its the Writer graphic ogject and svg changes are okay. I will try to debug wih that extra infos tomorrow.
ALG: tried with a one week old nonpro version with some debug, could not reproduce. Installing nonpro version from yestarday...
ALG: Could not reproduce with nonpro version (Windows) on windows7. Trying a pro version...
ALG: Full mac pro version from current trunk built, could not reproduce. I inserted single svgs, single otrher graphics. I inserted 30 graphics, mixed svg and others. Autosafe on 1 minute. Closing, reloading, all works fine. CLosed, graphioc cache to one object, keep in mem to one minute, close, open again, reload document or new document, no problems.
ALG: When further experimenting with lot of mixed graphics I found one where the error happens, it's paths-data-20-f.svg. To reproduce, new writer (with 1 minute to autosafe), insert that graphic, select another app, wait for the autosafe, reactivate -> the phenomen happens. - Printing and Pdf export will show empty frame - After save/reload the graphic is back, all works well (workaround exists, no data loss when saving) - Not reproducable in Draw/Impress/Calc Looks as if the autosafe somehow changes the settings at Graphic/GraphicObject, redefining where the graphic is to be fetched from when it needs to be swapped in. On the other hand it only happens with rare, special graphic files, pointing to that basic mechanism working in principle. Need to investigate deeper...
ok, I think it is a serious issue and should be fixed asap but I don't see it as showstopper for now. no data loss and a workaround is in place as well.
We have conducted extensive testing with SVG and other picture types in Draw/Impress/Calc and have not yet seen the"Graphic Cannot be Displayed" error occur. Currently we have only seen the error occur with SVG pictures in WRITER. As we have previously reported, the error does occur with different SVG pictures and different WRITER documents. Thanks to Armin Le Grand for reporting a workaround; however would you please be more specific about how to use the workaround? To jsc@apache.org, we understand that you wish to make this BUG have "major" importance. However, we believe that this BUG has CRITICAL if not higher importance because we have found the error to be an insidious BUG that occurs without warning and can modify any and/or all SVG pictures causing a person to have to go through the entire document repeatedly to check if any SVG pictures have been replaced prior to saving to a different format or Export to PDF. If any "Graphic Cannot be Displayed" error occurs then the picture(s) must be replaced, and again all of the SVG pictures must be checked prior to saving/exporting. Kudos to everyone for the immediate and extensive testing!
ALG: Reason found: The SVG files in question do not start with a XML header ("<?xml"), but directly with an svg statement ("<svg"). I am not sure if this is a valid format for SVG files at all, but this is the reason the file type detection does not recognize the correct file type. It is already bad that the file type needs to be detected at all (it is known but the API to the filter stuff does not allow to pass it, so it is not used). I can fix it by adding a basic detection for "<svg", evtl. additionally trying if it is possible to hand over the file type somehow. Checking possibilities...
ALG: Hi rk601, the workaround is simply: When seeing 'cannot be displayed' frames, save the document and reload it (file/reload). The frames will then be filled. But this should not be necessary, I'll commit a fix ASAP.
ALG: Fixed and comitted.
ALG: FYI: - Inkscape loads files starting with '<svg', but after changing and saving they have the Xml header (as expected). - Firefox displays it, too. - Safari displays it, too. - Sent a request to some Svg specialists, lets see their comments to this format.
Thanks to Armin Le Grand for the commit and fix! Please note that typically the first line of an SVG picture contains the XML declaration, and the root element, with the SVG code, begins with the <svg> element. However, every major Web browser that we tested parses an SVG picture without the XML declaration and tens of thousands, most likely more, of SVG pictures exist that do not start with the XML declaration. For example, go to http://openclipart.org/, select a picture, click "Edit Image", and save the edited image. The new SVG picture will NOT have the XML declaration; instead it will start with <SVG... For backward compatibility and maximum usage, please continue to allow AOO to parse SVG pictures that are missing the XML declaration. Thank you in advance.