GNOME Bugzilla – Bug 546887
Gnumeric doesn't view BIFF images from excel files
Last modified: 2008-10-13 12:51:20 UTC
Please describe the problem: Python library, xlwt, creates images using BIFF form from excel 95. Gnumeric doesn't read these files. However, these files (and images) are displayed in excel. More information is available at this ticket tracking the issue for open office (has the exact same issue). https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/255876 Steps to reproduce: 1. Create a file with BIFF image. 2. 3. Actual results: Image is not displayed Expected results: Image displayed Does this happen every time? Yes Other information: I recommend downloading the test case file from here http://launchpadlibrarian.net/16626349/image.xls Notice it opens in excel showing images and does not open in gnumeric.
Also, created a thread here at python-excel mailing list which has more information about the issue. http://groups.google.com/group/python-excel/browse_thread/thread/318178d2275c1807
Reproduced with SVN trunk (revision 16797). As noted in http://qa.openoffice.org/issues/show_bug.cgi?id=61786, what we're dealing with here is files which claim to be BIFF8 but which contain image data in an older convention. As such files are produced by several independent software packages and as Excel imports the images from them, we should make our import more liberal. As a test, I changed the biff8/older branching in plugins/excel/ms-obj.c's ms_read_OBJ() errors = (c->importer->ver >= MS_BIFF_V8) ? ms_obj_read_biff8_obj (q, c, obj) : ms_obj_read_pre_biff8_obj (q, c, obj); to always take the pre_biff8 path: errors = (0 && (c->importer->ver >= MS_BIFF_V8)) ? ms_obj_read_biff8_obj (q, c, obj) : ms_obj_read_pre_biff8_obj (q, c, obj); and with this modification, the images are imported. A proper fix would involve fixing the biff v8 path to allow for images from older biff versions.
Created attachment 119039 [details] [review] Proposed patch This patch is working for me on the simple test cases I have access to. It assumes that there are no adverse side effects from first having ms_obj_read_biff8_obj have a go and, if it fails, retry with ms_obj_read_pre_biff8_obj. I haven't studied the code paths in enough detail to be sure that assumption is justified.
Comment on attachment 119039 [details] [review] Proposed patch There are two problems. 1) The record structure of OBJ is very different between the biff8 variant, and the older formats. Getting the wrong one amounts to throwing invalid data at things. 2) It looks like the distinction is clearer. Rather than being version specific it may be somewhat simpler. The enclosing MS_DRAWING... seem to provide the context.
Created attachment 119065 [details] [review] Try using escher as the differentiator This works for my samples.
Tested successfully with http://launchpadlibrarian.net/16626349/image.xls (from https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/255876) and with http://www.openoffice.org/nonav/issues/showattachment.cgi/33949/images.xls (from http://qa.openoffice.org/issues/show_bug.cgi?id=61786). I also tried a fresh test based on the perl recipe used in OOo #61786, but ran into an "Unrecognized image file format", now logged as bug #553098.
So with Jody's patch, is this set to commit to repository and close out? Sorry for not knowing gnome development procedures. Just seems like a working fix, which happened to stumble onto a new bug, #553098.
Patch will be in 1.9.3 553098 is a much broader matter.