Re: commit: Fix 7991

From: <msevior_at_physics.unimelb.edu.au>
Date: Sun Jan 02 2005 - 23:31:11 CET

>
> Hi Tomas,
>
> I'm going to disagree with you here. This is no more
> nor no less of a hack than using m_bInPara. This is,
> however, a more robust solution because m_bInPara has
> a chance of getting out of sync while this does not.
>
> I also do not believe that this is a "performance
> killer" as you suggest. Checking for the presence of
> an open block when we insert an image is *negligable*
> compared to the time we spend laying out and rendering
> the document.
>
> In short, I believe that m_bInPara is a hack. I
> believe that this is a much more correct and robust
> fix. I believe that we should remove m_bInPara and use
> this in its place. And I believe that this might even
> be an acceptable work-around for bug 6427 where I
> suggest that the PT should lazy-create sections,
> blocks, spans, etc. where it expects them but none
> exist.
>

Hi Dom,
       If I didn't agree before, I do agree now. Especially after we
implement endBlock, endSection, endHdrFtrSection struxes. The PT
appendSpan, appendObject, appendFmt methods should look to see if
the document is inside a block and if not, create a block before
appending.

(Same for insert though handling the document position is a bit trickier)

This will make writing importers much easier and fix many bugs.

Cheers

Martin

> Best,
> Dom
>
> --- Tomas Frydrych <tomasfrydrych@yahoo.co.uk> wrote:
>
>>
>>
>> Hi Robert,
>>
>> As I indicated to you on the IRC I have concerns
>> about this fix. The
>> orginal code already had a test for the presence of
>> a block via the
>> m_bInPara flag. The problem clearly is that in the
>> given case that flag
>> was set without a block being in place (i.e., it was
>> most likely not
>> reset at some point where it should have been).
>>
>> My concern is that this fix does not deal with the
>> primary reason for
>> the crash which will eventually cause crashes in
>> other places. Pretty
>> much anything we insert into a document has to be
>> preceeded by a block,
>> so this fix deals with just one special case; at the
>> sime time I do not
>> want to call _ensureInBlock() function every time we
>> at present check
>> the m_bInPara flag for performance reasons. What
>> needs to be done in the
>> first instance is to find out where that flag is set
>> from, and how we
>> get from that place to the place where we try to
>> insert our image.
>>
>> While I apprecite the work you put into it, I think
>> this should be
>> reveted and the bug reopened.
>>
>> Tomas
>>
>>
>> Robert Wilhelm wrote:
>> > Fixes 7991 (Word document with two images in
>> Header crashes abiword).
>> >
>> >
>> > New function _ensureInBlock(). Fixes 7991.
>> > CVS:
>> >
>>
> ----------------------------------------------------------------------
>> > CVS: Enter Log. Lines beginning with `CVS:' are
>> removed automatically
>> > CVS:
>> > CVS: Committing in .
>> > CVS:
>> > CVS: Modified Files:
>> > CVS: ie_imp_MsWord_97.cpp ie_imp_MsWord_97.h
>> > CVS:
>> >
>>
> ----------------------------------------------------------------------
>> >
>> >
>> >
>>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Jazz up your holiday email with celebrity designs. Learn more.
> http://celebrity.mail.yahoo.com
>
Received on Sun Jan 2 23:31:11 2005

This archive was generated by hypermail 2.1.8 : Sun Jan 02 2005 - 23:31:11 CET