WIP: tables

[Jeremias Maerki <de...@greenmail.ch>]

Luca mentioned that he has been working on lists. So after the branch is
now in place and some basic features are working I'll be working on
resurrecting table support now. JFYI.

Jeremias Maerki

Re: WIP: tables

[Chris Bowditch <bo...@hotmail.com>]

Jeremias Maerki wrote:

> Don't worry, I'm not trying to solve auto table layout. Take line-height
> on a block or block-progression-dimension on an external-graphic, for
> example. Both support min/opt/max values which means that the generated
> vboxes can (theoretically) get stretch and shrink, too. I don't think we
> have code for this, yet, but still the page breaking algorithm can work
> with it (or rather with appended special glue elements). Of course, in
> an initial implementation we would probably not take this into account
> (for table cells) but I want to think about it because it may tell me if
> there's a better approach to take than the one I'm currently favoring.
> My post is almost ready so I can explain in detail...

I see now. Thanks for taking the time to clarify this for me.

Chris

Re: WIP: tables

[Jeremias Maerki <de...@greenmail.ch>]

Don't worry, I'm not trying to solve auto table layout. Take line-height
on a block or block-progression-dimension on an external-graphic, for
example. Both support min/opt/max values which means that the generated
vboxes can (theoretically) get stretch and shrink, too. I don't think we
have code for this, yet, but still the page breaking algorithm can work
with it (or rather with appended special glue elements). Of course, in
an initial implementation we would probably not take this into account
(for table cells) but I want to think about it because it may tell me if
there's a better approach to take than the one I'm currently favoring.
My post is almost ready so I can explain in detail...

On 22.03.2005 10:50:39 Chris Bowditch wrote:
> Jeremias Maerki wrote:
> 
> > Thanks. But well, I've just realized that I neglected a certain aspect
> > of table layout in my preparations which turns out not to be so simple.
> > Some might have seen my notes on the Wiki about breaking cells [1]. This
> > was done while I was still thinking in terms of the old approach. Now
> > with the Knuth element lists the problem presents itself in a different
> > look. We've got to build a combined Knuth element list for a table row
> > from element lists of the individual cells. Turns out to be relatively
> > straight-forward if you only deal with fixed width boxes and normal
> > penalties. As soon as stretch/shrink flows into the equation things look
> > like they can get real messy. I'm currently preparing two different
> > approaches for discussion (will appear on [1]). I wonder how Luca
> > handled lists which is a similar problem.
> 
> Please excuse my ignorance, but why do you need to take cells that 
> shrink/stretch into the equation? Are you trying to allow for auto table 
> layout?? IMHO for a first release auto table layout is a bridge too far.
> 
> Chris
> 
> 



Jeremias Maerki

Re: WIP: tables

[Chris Bowditch <bo...@hotmail.com>]

Jeremias Maerki wrote:

> Thanks. But well, I've just realized that I neglected a certain aspect
> of table layout in my preparations which turns out not to be so simple.
> Some might have seen my notes on the Wiki about breaking cells [1]. This
> was done while I was still thinking in terms of the old approach. Now
> with the Knuth element lists the problem presents itself in a different
> look. We've got to build a combined Knuth element list for a table row
> from element lists of the individual cells. Turns out to be relatively
> straight-forward if you only deal with fixed width boxes and normal
> penalties. As soon as stretch/shrink flows into the equation things look
> like they can get real messy. I'm currently preparing two different
> approaches for discussion (will appear on [1]). I wonder how Luca
> handled lists which is a similar problem.

Please excuse my ignorance, but why do you need to take cells that 
shrink/stretch into the equation? Are you trying to allow for auto table 
layout?? IMHO for a first release auto table layout is a bridge too far.

Chris

Re: WIP: tables

[Jeremias Maerki <de...@greenmail.ch>]

Thanks. But well, I've just realized that I neglected a certain aspect
of table layout in my preparations which turns out not to be so simple.
Some might have seen my notes on the Wiki about breaking cells [1]. This
was done while I was still thinking in terms of the old approach. Now
with the Knuth element lists the problem presents itself in a different
look. We've got to build a combined Knuth element list for a table row
from element lists of the individual cells. Turns out to be relatively
straight-forward if you only deal with fixed width boxes and normal
penalties. As soon as stretch/shrink flows into the equation things look
like they can get real messy. I'm currently preparing two different
approaches for discussion (will appear on [1]). I wonder how Luca
handled lists which is a similar problem.

[1] http://wiki.apache.org/xmlgraphics-fop/TableLayout


On 22.03.2005 09:53:33 Chris Bowditch wrote:
> Jeremias Maerki wrote:
> 
> > Luca mentioned that he has been working on lists. So after the branch is
> > now in place and some basic features are working I'll be working on
> > resurrecting table support now. JFYI.
> 
> Thanks for letting us know Jeremias. Good luck.
> 
> Chris



Jeremias Maerki

Re: WIP: tables

[Chris Bowditch <bo...@hotmail.com>]

Jeremias Maerki wrote:

> Luca mentioned that he has been working on lists. So after the branch is
> now in place and some basic features are working I'll be working on
> resurrecting table support now. JFYI.

Thanks for letting us know Jeremias. Good luck.

Chris