Apache OpenOffice (AOO) Bugzilla – Issue 106063
Broken ChemSketch-BMP file import.
Last modified: 2017-05-20 10:35:25 UTC
When *.BMP file is imported using menu "Insert->Picture->From file" in aplication: -Writer -Impress -Calc -Draw The distortion of inserted image occur. Please look into attachement for more info.. In application: -PowerPoint 2007 -IrfanViev 4.25 -etc.. Sample image is imported or displayed correctly. Sample *.BMP image generated in program: ACD/Labs Chemsketch 12.0
Created attachment 65461 [details] Video file with reproduction of bug.
Created attachment 65462 [details] Sample ODP files
Created attachment 65463 [details] Sample BMP files
It seems to be a special problem with bmp-files exported from ChemSketch. I see the same error with other pictures exported from ChemSketch (free education version from www.acdlabs.com) The picture looks as if it is cut vertically and the parts are put wrongly together. I have used OOo3.2Beta
Reproducible. Reassigned.
Still Reproducible with server installation of "AOO 4.1.0-Dev – English UI / English locale - [AOO410m1(Build:9750) - Rev. 1554003 - 2014-01-06]" on German WIN7 Home Premium (64bit)", own separate user profile. Additional Info: ---------------- (a) This is not a particular Impress problem, same in Writer, Calc, ... (b) Not a special OO problem, similar in SoftMaker FreeOffice, LibreOffice 4.1.3, Lotus Symphony Release 3.0.1 Revision 20120110.2000 (c) I confirm Regina's results (d) Looks ok in Irfan Viw, Gimp, WIN Files Explorer preview, Calligra (Words), Seamonkey Browser (e) Already reproducible with Pre-3.4.0 (DEV300m60, OOo 1.1.5), but because of crippled Version selector (Bug 123063) no useful info can be contributed
Created attachment 82274 [details] Screenshots
The attached bmp file in comment 3 has Windows bitmap type header (40 bytes). And data size for each pixel is 32bit, in general, in this kindo of case, no color palette is there after the file header. The file header indicates 256 colors (8 bit colors) are there in the color palette that uses 1024 bytes length. It seems the inserted image on the Writer document is starting with 256 pixel position. Therefore, the color palette length seems mishandled. But in most case, no color plette is used for 32 bit color bitmap file.
(In reply to hanya from comment #8) I am trying to get contact with ACD/Labs concerning "Bug 92524 - Chemsketch ole-objects (chemical structures) inserted from file shown as placeholder", may be the will be interested to discuss this problem here, too.
Comment 8 is wrong. The problem is not reading the pixel data before the correct position, but the skipping another bytes for the pallet. The offset to the pixel data is read from the file header and it is passed to ImplReadDIBBody function (in vcl/source/gdi/dibtools.cxx). Before reading pixel data by calling ImplReadDIBBits function, the position in the SvStream is changed if the offset is provided. In ImplReadDIBBits function, near the following comment, additional seek is done for skipping the palette. > // true color DIB's can have a (optimization) palette In the case of the attached bitmap file, additional 1024(256 colors) bytes are skipped. And bytes data is read from the wrong position.
Created attachment 82283 [details] Patch to avoid additional seek in ImplReadDIBBits for over 8 bit depth with palette ImplReadDIBBits function is called only from ImplReadDIBBody function. And just before calltin ImplReadDIBBits function, the position in the stream is moved to the offset position that starts the data, it is there after the palette. Therefore ImplReadDIBBits function should not try to skip the palette that already skipped by the caller function.
"hanya" committed SVN revision 1560262 into trunk: #i106063# avoid additional seek for true color DIB
Fixed on trunk.
verified on windows7 on AOO410m15(Build:9761) - Rev. 1583666 2014-04-01 13:53:14 (Di, 01 Apr 2014)