Subject: Re: Topic: Tables and 1.0
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Sun May 06 2001 - 09:55:49 CDT
On Sun, 6 May 2001, Leonard Rosenthol wrote:
> At 08:17 PM 5/5/2001 +1000, Martin Sevior wrote:
> >I thought this would work via the GTK algorithim too. For selections we do
> >mapDocPositionToXY on the anchor and the same for the cursor location.
> >Then simply the grey all text in all runs between those points using
> >whatever layout code we have.
>
> That implies that the runs of the table are NOT going to be
> separate "pieces", but instead part of the main piece table. That's not
> how I thought I heard you (and Dom) professing to want to do this. I
> thought that you were looking to make each cell it's own
> "mini-document". Both are valid approaches to solving the table issue -
> but each has advantages and disadvantages. Do you know which you are
> thinking more about?
>
Hi Leonard,
Well here is my current thinking about the piecetable structure
of table.
I am not currently thinking about a mini-document. I think a table could
be represented in our piecetable as:
1. Overall sub-class of a section strux - TableStrux. It has a list of
properties describing the overall table including: Number of rows, number
of columns. Which cells span multi-rows and multi-columns. Maybe other
properties to describe if the table floats in the text or has fixed
position on a page. In addition it has an tableID number associated with
it.
2. After the Table strux entry comes the cell struxes. These have
properties like location in the table (xn - xm, yn - y-m), horizontal or
vertical size. It carries the ID associated with the table.
The cell struxes contain arbitary content. It is the job of layout engine
to fit these into a rectangular array.
3. The table is terminated with an endTable strux with match ID number to
the ID of the defining table ID. The advantage of a terminating ID is that
we can embed tables within tables this way. The GTK algorithm can
recursively layout rectangular structures.
It is the job of the layout engine to position this table on the
screen. All manipulations of the table are of course done through the
piectable to keep our unlimited undo/redo and maintain document integrity.
Paragraph level manipulations are are through the current listener scheme.
We will extend these manipulations to allow cell strux changes
(populate/change/insert/delete) these map to CallSectionLayout.cpp
and table strux changes (populate/change/insert/delete) these map to
TableSectionLayout.cpp.
Hmm I'm not sure at this point whether it is better to have the cells know
about how many rows and columns they span. It is probabally to better to
have just the TableStrux define that. Then the CellStrux is just a dumb
rectangular holder of BlockStruxes.
>
> >Actually doing things this way I think that any algorithim we use to
> >layout the containers we also allow cross cell selections.
>
> If you are not doing the "mini-document" approach, then yes, you
> should be able to do cross cell selection. However, that will mean a LOT
> more work to implement based on changes to the existing layout engine/piece
> table.
>
I think you're right but it is worth the effort.
Cheers
Martin
This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:51:03 CDT