Hi Del, indeed Sven is our expert for these nasty things. As he just returned from vacation he will need some time to catch up. Please stay tuned.
Best regards, Mathias Del Merritt wrote: > 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] > -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[email protected]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
