On 6-Apr-2009, Del Merritt wrote:
OK - I'm back. Took a while, but here's something I came across with
the help of gdb:
DEV300_m43's svx/source/msfilter/msdffimp.cxx at line 6353, "rst >>
nBLIPPos;" is giving back 4294967295 (aka, 0xFFFFFFFF) the second and
subsequent times through the loop. This doesn't sound right. Stepping
through and into the twisty guts of SvStream::Read() and friends shows
that the page of cached data does have 0xFFFFFFFF. Unfortunately the
caller, SvxMSDffManager::GetDrawingGroupContainerData(), stuffs that
"signed" quantity into an unsigned, and doesn't seem to guard against
it in any way.
Suggestions? Better place to post this or person to whom to direct it?
I've dug a bit further. Following the description at:
http://chicago.sourceforge.net/devel/docs/escher/index.html
and using my editor in "hexl" mode, I get a list of BLIPs (aka, FSBEs)
that looks like this (best viewed in a fixed-width font):
Common record type image ID tag
BLIP Reference File Misc.
header
size Count offset
5200 07f0 24000000 0505 e62290a89dad63a39b1a7f438d2b9310 ff00
7be10200 01000000 2a220000 00000000
5200 07f0 24000000 0505 082ff85372932323f206a79bb94b0f61 ff00
b7f60100 00000000 ffffffff 00000000
6200 07f0 24000000 0606 7b1f51495870795a2d2b0a3026a742b4 ff00
db130100 00000000 ffffffff 00000000
6200 07f0 24000000 0606 a00663cabce3802731480022f5d1c6ef ff00
6ee60000 00000000 ffffffff 00000000
5200 07f0 24000000 0505 26ee244b826180dfdae5e6385aebd870 ff00
71d90100 00000000 ffffffff 00000000
6200 07f0 24000000 0606 6c0f5735838bf954bbff6205b183ed42 ff00
c6130100 00000000 2ff20700 00000000
5200 07f0 24000000 0505 89b862fd80cc022763eda1017177be9b ff00
1e560000 00000000 ffffffff 00000000
5200 07f0 24000000 0505 37274a39b1fd73edef6c50d4f69b2a3d ff00
b3520200 00000000 ffffffff 00000000
5200 07f0 24000000 0505 174b7f9ccf7511056651fd3889c38f26 ff00
fb5d0200 01000000 a5030300 00000000
5200 07f0 24000000 0505 c20f41ac2bd09212c0c3b12b588393f7 ff00
d9740400 01000000 a0610500 00000000
5200 07f0 24000000 0505 d236c5950705fd4a969b1a73358cf792 ff00
e5f40400 01000000 79d60900 00000000
5200 07f0 24000000 0505 f5dd3f6581e6e7e5178361f832f86a52 ff00
7ee00200 01000000 5ecb0e00 00000000
5200 07f0 24000000 0505 7bc7f17aaa63d40d5029fef16a23356a ff00
bfaa0000 01000000 dcab1100 00000000
6200 07f0 24000000 0606 c4b7e916ea9e174e5a9728b374856983 ff00
80460000 00000000 ffffffff 00000000
5200 07f0 24000000 0505 70af3e4e82be1c7832e2c1b717c7277f ff00
2c720100 00000000 ffffffff 00000000
8000 1af1 20000000
7dffff0063b1ff00ffd5dc00c074fe00542f9d00ffff6700cdf5ff00afc2ff00
The aforementioned code in svx/source/msfilter/msdffimp.cxx's
GetDrawingGroupContainerData() ignores the reference count field when it
is inserting BLIPs. But if I modify the code around line 6355 thus:
if( bOk )
{
rSt.SeekRel( nSkipBLIPLen );
rSt >> nBLIPLen;
rSt.SeekRel( nSkipBLIPPos ); // Note: this seek
skips the ref count field
rSt >> nBLIPPos; // see data above, nBLIPPos is -1
when ref count == 0
bOk = rSt.GetError() == 0 && nBLIPPos != 0xffffffff;
// test for -1
nLength -= nSkipBLIPLen+ 4 + nSkipBLIPPos + 4;
}
things don't behave any better. In fact, the images I want don't
display at all.
Of course, this could be a red herring. Any pointers as to where to
pick up a proper trail are appreciated. I'd really be interested in a
pointer to where the images gets flowed with the text, since the bugs
I'm trying to fix have to do with odd layout (when compared with the
document as viewed in M$ Wurd).
Thanks,
-Del
p.s. - sj added to CC at the suggestion of caolan over on
#dev.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
