Re: [Gsoc Table Header] Deal with Broken Table

From: Simon Larochelle <larochelle.simon.1_at_gmail.com>
Date: Mon Jul 22 2013 - 23:51:17 CEST

Hi Joe,

fp_TableContainer::tweakBrokenTable and
fp_CellContainer::tweakBrokenTable are no longer needed. I modified
the table breaking code in order to get a simple criterion to
determine whether a container belongs to a broken table or not (the
top of the container must be between YBreak and YBottom (see
fp_TableContainer::isInBrokenTable)). Thus there is no longer any
reason to set a variable that indicates to which broken table a
container belongs (the setMyBrokenContainer function that used to be
called). tweakBrokenTable was also used to tweak the table boundary.
This is now properly taken care of in the wantVBreakAt functions.

fp_TableContainer::getBrokenTop is used a single time in the code in a
boolean test. So I replaced the associated variable by a boolean and
moved the function definition to the .h file. As m_bBrokenTop is
initialized to false, the tests in the old function are no longer
needed.

fp_TableContainer::adjustBrokenTables was already disabled (there is a
return statement on line 20).

Simon

On Fri, Jul 19, 2013 at 12:48 PM, joe joe <joegsoc2013@gmail.com> wrote:
> Hi Simon,
>
> Now I have merged most code from Table Header branch and start to do
> more debug to make all things stable.
>
> One thing need to check with you about some functions for "Deal with
> Broken Tables":
>
> I find that there are some important functions are deleted by you on revision:
> http://www.abisource.com/viewvc/abiword/trunk/src/text/fmt/xp/fp_TableContainer.cpp?r1=32578&r2=32579
>
> such as:
> * UT_sint32 fp_CellContainer::tweakBrokenTable(fp_TableContainer * pBroke)
> * UT_sint32 fp_TableContainer::getBrokenTop(void)
> * void fp_TableContainer::adjustBrokenTables(void)
> * UT_sint32 fp_TableContainer::tweakBrokenTable(fp_TableContainer * pBroke)
>
>
>
> Can you share me the reason that you delete the code and the logic,
> thanks a lot,
>
>
> Thanks,
> Joe
>
>
>
> On Fri, Apr 12, 2013 at 9:35 AM, joe joe <joegsoc2013@gmail.com> wrote:
>> Thanks Martin & Simon.
>>
>> I am looking into the points that you guys point out. Will proposal a
>> solution one or two days, thanks
>>
>> Joe
>>
>> On Thu, Apr 11, 2013 at 10:41 AM, Simon Larochelle
>> <larochelle.simon.1@gmail.com> wrote:
>>>
>>> Well bug 8707 is not really fixed. There is a big mess hidden behind
>>> these two bugs. The basic issue is that we select a table by defining
>>> two endpoints: the anchor and the current cursor position. Both of
>>> these points need to be valid cursor positions in the piece table
>>> (that is positions in the piece table where text could be inserted).
>>> Now to select an object (a table, a cell, a frame ...), we should have
>>> as endpoints the beginning and the end of the object (for example the
>>> fragment PTX_SectionTable and the fragment PTX_EndTable). This does
>>> not work because these endpoints are not valid cursor positions. So we
>>> use instead the nearest valid cursor positions, which causes a series
>>> of little bugs (for example if the table is at the beginning of the
>>> header, the endpoint at the beginning of the table is actually before
>>> the start of the header in the main section. That's the origin of bug
>>> 8984).
>>>
>>> A fix would be to use our multiple selection framework to select
>>> objects (the selection endpoints and the cursor are different in this
>>> selection mode, so we could use any point in the piece table as
>>> selection endpoints). However, the multiple selection framework is
>>> only partially implemented (that's the cause of the bugs seen when
>>> applying text formatting commands on a column). Fully implementing
>>> this feature will require revising every function in FV_View. So
>>> fixing these bugs is a big project.
>>>
>>>
>>> Simon
>>>
>>> On Wed, Apr 10, 2013 at 10:16 PM, Martin Edmund Sevior
>>> <martines@unimelb.edu.au> wrote:
>>>>
>>>>
>>>> Sorry, Instead of:
>>>>
>>>> "Bug 8984 is still present. I believe it occurs because the special
>>>> case code used to handle bugs at the beginning of a document doesn't
>>>> work for headers or footers."
>>>>
>>>> I should have said:
>>>>
>>>> "Bug 8984 is still present. I believe it occurs because the special
>>>> case code used to handle tables at the beginning of a document doesn't
>>>> work for headers or footers."
>>>>
>>>> Cheers
>>>>
>>>> Martin
>>>>
Received on Mon Jul 22 23:51:32 2013

This archive was generated by hypermail 2.1.8 : Mon Jul 22 2013 - 23:51:32 CEST