On Tue, Aug 21, 2007 at 09:40:49AM +0200, Leuven, E. wrote:
>
> any thoughs on this one?
>
> Edwin Leuven wrote:
> > at the moment we store line attributes in the cell *and* in the
> > column and row info.
> >
> > i am tempted to remove them from the column and row info because i do
> > not see
Martin wrote:
> Sure, but keep it in mind to avoid double work.
cleaning up of the tabular code has to be done anyway
and i have troubles enough to wrap my head around this tabular stuff crashing
on me
sigh
On Tue, 21 Aug 2007 15:21:13 +0200
"Leuven, E." <[EMAIL PROTECTED]> wrote:
> > Also, I think there's a lot of code sharing that can be done between
> > math tables and tabular. See our discussion about cell access methods to
> > Inset earlier last week (with JMarc and Alfredo).
>
> let' s worry
> Also, I think there's a lot of code sharing that can be done between
> math tables and tabular. See our discussion about cell access methods to
> Inset earlier last week (with JMarc and Alfredo).
let' s worry about that later (when the tabular code is cleaner)
Leuven, E. wrote:
Georg Baum wrote:
I don't think so. In general the tabular code is far too close to LaTeX
IMHO, and this is just one case where it shows.
i am glad you say so, it is exactly the feeling i have after staring at the
code for some time now...
Another idea would be to encapsul
Leuven, E. wrote:
Georg Baum wrote:
I don't think so. In general the tabular code is far too close to LaTeX
IMHO, and this is just one case where it shows.
i am glad you say so, it is exactly the feeling i have after staring at the
code for some time now...
Also, I think there's a lot of co
Leuven, E. wrote:
> Georg Baum wrote:
>> Another one is the "single
>> cell multicolumn" problem: The fact that you need \multicolumn if you
>> want to change the alignment or border of just one cell is a LaTeX
>> implementation issue, and the user should not need to know that. LyX
>> should creat
Georg Baum wrote:
> I don't think so. In general the tabular code is far too close to LaTeX
> IMHO, and this is just one case where it shows.
i am glad you say so, it is exactly the feeling i have after staring at the
code for some time now...
> Another one is the "single
> cell multicolumn" pro
Edwin Leuven wrote:
> at the moment we store line attributes in the cell *and* in the column
> and row info.
>
> i am tempted to remove them from the column and row info because i do
> not see what extra info they give on top of the cell attributes
>
> am i overseeing something?
I don't think s
On 8/21/07, Leuven, E. <[EMAIL PROTECTED]> wrote:
> Alfredo wrote:
> > What happends when you insert a new row, does its cells inherit
> column/row
> > attributes?
>
> inherit from ...?
>From global (i.e. non-cell specific) column/row line attributes, what else.
> > This would make sense
Alfredo wrote:
> What happends when you insert a new row, does its cells inherit column/row
> attributes?
inherit from ...?
> This would make sense. OTOH, just copying the row above would
> make also sense. ;-)
personally i don't see why i would like a copy of a previous line or the line
the cu
Leuven, E. wrote:
>
> any thoughs on this one?
>
> Edwin Leuven wrote:
>> at the moment we store line attributes in the cell *and* in the
>> column and row info.
>>
>> i am tempted to remove them from the column and row info because i do
>> not see what extra info they give on top of the cell
any thoughs on this one?
Edwin Leuven wrote:
> at the moment we store line attributes in the cell *and* in the
> column and row info.
>
> i am tempted to remove them from the column and row info because i do
> not see what extra info they give on top of the cell attributes
>
> am i overseeing
Andre Poenitz wrote:
If you have the feeling that things are simpler/less-of-a-mess
afterwards, then it doesn't sound wrong.
right
- top_line(true),
+ top_line(false),
bottom_line(false),
- left_line(true),
+ left_line(false),
right_line(fal
On Mon, Aug 20, 2007 at 04:44:16PM +0200, Leuven, E. wrote:
> hi guys,
>
> i made a start with ripping out the way merged cells are handled in
> the tabular code.
>
> atm cells can have attributes
>
> CELL_NORMAL CELL_BEGIN_OF_MULTICOLUMN CELL_PART_OF_MULTICOLUMN
>
> if a range of cells is merg
Edwin Leuven wrote:
> i think that things become a bit cleaner, there was already indexing
> going keeping track of the row/column of each cell, but in addition
> there was a cellno attribute, and this
>
> CELL_NORMAL
> CELL_BEGIN_OF_MULTICOLUMN
> CELL_PART_OF_MULTICOLUMN
>
> stuff. we can now a
Georg Baum wrote:
If you touch this then please add support for multirow-cells. It should not
be too much more effort if you rip this code apart anyway.
hi georg,
good idea. i thought of waiting with that, but i agree that it makes
sense to do it now since i am at it
I don't know. I do kno
Leuven, E. wrote:
> i basically got rid of this so that we have one cell per cell. in the cell
> we have the attribute column_span which tells us how many columns the cell
> spans.
If you touch this then please add support for multirow-cells. It should not
be too much more effort if you rip this
18 matches
Mail list logo
