GNOME Bugzilla – Bug 490584
Gnumeric doesn't render bitmap images from an Excel file correctly
Last modified: 2008-11-09 18:16:09 UTC
This is a minor issue that I noticed when testing the Perl module Spreadsheet::WriteExcel with Gnumeric. How to reproduce this. 1. Create a small bitmap*. For example a 3x5 24 bit bitmap in solid red. 2. Create a new workbook in Excel (97 or later). 3. Import the image into the worksheet. 4. Save the file. 5. Open it in Gnumeric. 6. Verify that the image isn't displayed correctly. *Excel will convert large bitmap images to PNG while reading so the image must be small. I haven't tried to debug this in Gnumeric in any way but the following is a guess at what might be the problem. Here is a dump of the MSODRAWINGGROUP for a 3x5 24 bit bitmap in solid red. [MSODRAWINGGROUP] (Record = 0x00EB, Length = 0x011B, 283) EB 00 1B 01 0F 00 00 F0 13 01 00 00 00 00 06 F0 |................| 18 00 00 00 02 04 00 00 02 00 00 00 02 00 00 00 |................| 01 00 00 00 01 00 00 00 02 00 00 00 1F 00 01 F0 |................| B9 00 00 00 72 00 07 F0 B1 00 00 00 07 07 79 A1 |....r.........y.| B1 89 16 5B F8 09 BE C1 21 2D 95 37 06 FD FF 00 |...[....!-.7....| 8D 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 |................| 90 7A 1F F0 85 00 00 00 01 37 21 0A 19 E4 8B 8C |.z.......7!.....| 14 74 A6 CA 53 D0 8B 89 79 A1 B1 89 16 5B F8 09 |.t..S...y....[..| BE C1 21 2D 95 37 06 FD FF 28 00 00 00 03 00 00 |..!-.7...(......| 00 05 00 00 00 01 00 18 00 00 00 00 00 3C 00 00 |.............<..| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00 00 00 FF 00 00 FF 00 00 FF 00 00 00 00 00 FF |................| 00 00 FF 00 00 FF 00 00 00 00 00 FF 00 00 FF 00 |................| 00 FF 00 00 00 00 00 FF 00 00 FF 00 00 FF 00 00 |................| 00 00 00 FF 00 00 FF 00 00 FF 00 00 00 33 00 0B |.............3..| F0 12 00 00 00 BF 00 08 00 08 00 81 01 09 00 00 |................| 08 C0 01 40 00 00 08 40 00 1E F1 10 00 00 00 0D |...@...@........| 00 00 08 0C 00 00 08 17 00 00 08 F7 00 00 10 |............... | 0 Record = 0x00EB 235 2 Length = 0x011B 283 DggContainer (0xF000) ======================= 4 Header = 0x000F 15 0-3 version = 1111 15 4-15 instance = 000000000000 0 6 Type (DggContainer) = 0xF000 61440 8 Length = 0x00000113 275 Dgg (0xF006) ======================= 12 Header = 0x0000 0 0-3 version = 0000 0 4-15 instance = 000000000000 0 14 Type (Dgg) = 0xF006 61446 16 Length = 0x00000018 24 20 spidMax = 0x00000402 1026 24 cidcl = 0x00000002 2 28 cspSaved = 0x00000002 2 32 cdgSaved = 0x00000001 1 36 dgid 1 = 0x00000001 1 40 cspidCur 1 = 0x00000002 2 BstoreContainer (0xF001) ======================= 44 Header = 0x001F 31 0-3 version = 1111 15 4-15 instance = 100000000000 1 46 Type (BstoreContainer) = 0xF001 61441 48 Length = 0x000000B9 185 BlipStoreEntry (0xF007) ======================= 52 Header = 0x0072 114 0-3 version = 0100 2 4-15 instance = 111000000000 7 54 Type (BlipStoreEntry) = 0xF007 61447 56 Length = 0x000000B1 177 60 Win32 = 0x07 7 61 Mac = 0x07 7 62 Uid 1 = 79A1B189165BF809BEC1212D953706FD 78 Tag = 0x00FF 255 80 Size = 0x0000008D 141 84 Ref count = 0x00000001 1 88 File Offset = 0x00000000 0 92 Usage = 0x00 0 93 Name length = 0x00 0 94 Unused = 0x00 0 95 Unused = 0x00 0 Blip DIB (0xF01F) ======================= 96 Header = 0x7A90 31376 0-3 version = 0000 0 4-15 instance = 100101011110 1961 98 Type (Blip DIB) = 0xF01F 61471 100 Length = 0x00000085 133 104 Uid 2 = 0137210A19E48B8C1474A6CA53D08B89 120 Uid 1 = 79A1B189165BF809BEC1212D953706FD 137 Tag = 0xFF 255 + Data = 28 00 00 00 03 00 00 00 05 00 00 00 01 00 18 00 00 00 00 00 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF 00 00 FF 00 00 FF 00 00 00 00 00 FF 00 00 FF 00 00 FF 00 00 00 00 00 FF 00 00 FF 00 00 FF 00 00 00 00 00 FF 00 00 FF 00 00 FF 00 00 00 00 00 FF 00 00 FF 00 00 FF 00 00 00 Opt (0xF00B) ======================= 237 Header = 0x0033 51 0-3 version = 1100 3 4-15 instance = 110000000000 3 239 Type (Opt) = 0xF00B 61451 241 Length = 0x00000012 18 245 Key = 0x00BF 191 Text -> fFitTextToShape 247 Value = 0x00080008 524296 251 Key = 0x0181 385 Fill Style -> fillColor 253 Value = 0x08000009 134217737 257 Key = 0x01C0 448 Line Style -> lineColor 259 Value = 0x08000040 134217792 SplitMenuColors (0xF11E) ======================= 263 Header = 0x0040 64 0-3 version = 0000 0 4-15 instance = 001000000000 4 265 Type (SplitMenuColors) = 0xF11E 61726 267 Length = 0x00000010 16 + Data = 0D 00 00 08 0C 00 00 08 17 00 00 08 F7 00 00 10 Note that the Blip DIB is different from that of a PNG or JPG in that it contains 2 UID checksums. UID1 is for the original image and UID2 is for the image as stored (with the 14 byte header removed). The presence of the second UID is indicated by a flag in the Blip DIB instance. This is referred to, albeit fairly opaquely, in the Escher docs as follows: /* The primary UID - this defaults to 0, in which case the primary ID is that of the internal data. NOTE!: The primary UID is only saved to disk if (blip_instance ^ blip_signature == 1). Blip_instance is MSOFBH.inst and blip_signature is one of the values defined in MSOBI */ In the above example we can see that 1961 ^ 1960 (for msoblipDIB) == 1. My guess is that Gnumeric may not be taking the second UID into account. Either way it is a fairly minor bug since Excel rarely produces files with embedded bitmaps. Let me know if you need any further information. John. --
Could you create a test file, please?
Created attachment 97983 [details] Excel file with embedded bitmap Example Excel 97 file with embedded 3x5 solid red 24bit bitmap. Note the binary structure in this file is slightly different than the one shown above. John. --
Created attachment 97984 [details] Screenshot of the attached file in Excel
Created attachment 97985 [details] Screenshot of the attached file in Gnumeric
** (lt-gnumeric:3065): WARNING **: Unrecognized image file format What you get is an image with a bluish background and a pile of coloured question marks. That is what we use when we do not understand the image format. At size 3x5, it looks like a solid rectangle.
Ah, ok. Then please close/reject this as you please. John. --
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 553098 ***