Subject: Re: Table workaround
From: Mike Nordell (tamlin@algonet.se)
Date: Wed Dec 20 2000 - 01:46:12 CST
Martin Sevior wrote:
> We also have to think of attributes to define a run of text/objects in the
> piece table so that they know they're in a table.
Why??? Should really a piece of text "know" it's in a table? If so, why?
> Have you done tables before Mike?
No, and I take Shaw's (or was it Eric's) word for it that it's *very*
non-trivial, but I don't think it's 1% as hard as he tried to make it sound.
I still think it's all about making good abstrations, interfaces and
behaviours.
[...]
> This is one way of doing things. You have to make each line know where the
> cell on the previous line starts and stops.
No.
> I posted an idea along these lines a month ago but Eric shot me down with
> the counter example of a cell spanning multiple rows.
So? If one cell spawn multiple rows, that cell can *never* interfere with
the next "table-line", right? The only think here is that an fl_Line (or
fp_Line or whatever) is "just" one-line-of-text, whereas a cell can be
multiple lines of text. OK, we'll fix that one, but AFAIK it's still just
one "table-line".
> We have to handle the cases of cells spanning multiple rows and multiple
> columns
??? One cell spanning "multiple columns"? Please define "column". A table in
my interpretation starts out like (let's take a 3x3 table as an example):
+---+---+---+
+---+---+---+
+---+---+---+
+---+---+---+
but then you're allowed to make it look
+---+---+---+
+--+-----+--+
+--+-----+--+
+---+---+---+
By this definition, you would still have three logical columns, but they
would have no "keep-x-pos-with-prev-table-line" attibute set.
> but otherwise being aligned above and below. If we do it on the
> line level, lines above and below have to know where the previous cell
> starts and stops.
Depending on what type of "line" we use. But, what if we make every cell its
own "layout block"? That would be needed anyway if we are to line-break and
stuff. This would then, if properly implemented, be a complete
implementation to use for "frames".
/Mike - please don't cc
This archive was generated by hypermail 2b25 : Wed Dec 20 2000 - 01:44:27 CST