You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Alex Sanderson <al...@duke-interactive.com> on 2000/11/29 16:11:23 UTC
Re: TableCell or TableRow Larger than a page( bug fix )
Hi Hani,
I have just been testing out your patch. It is excellent thank you. I have noticed a problem with tables inside tables.
I hope this works :)
|-----------------------------------------------|
| Parent Table |
| |-------------------------------------------| |
| | Parent Row1 | |
| ||-------------------| |-------------------|| |
| || Table 1 | | Table 2 || |
| |||--------|--------|| ||-------|---------||| |
| ||| t1c1 | t1c2 || || t2c1 | t2c2 ||| |
| |||--------|--------|| ||-------|---------||| |
| ||-------------------| |-------------------|| |
| |-------------------------------------------| |
| |
|-----------------------------------------------|
If t2c2 is too big, the table breaking algorithm puts it on the next page.
Instead of putting the whole of the parent table row on the next page it
just puts t2c2 on the next page and continues with table2 there. t2c1 is left
on the first page, I think it should follow to the second page. Also I think that
the whole of the parent row should start on the next page.
Thanks again for the patch it has really saved me.
Alex
Re: TableCell or TableRow Larger than a page( bug fix )
Posted by Corinna Hischke <co...@infix.de>.
Hi Keiron
>
> I was talking about the strange behaviour in the attached examples.
>
> I think I am mainly considering situations where none of a cell can be
> placed in the first page so that the cell starts on the next page and
> other cells are placed on the next page that don't need to be.
> I'm not saying that all of the row needs to be on the page, just the
> start of all the cells in the row.
>
With the examples, I got your point:
In your first example, the col 3 of row 2 is put on the second page,
while col 2 of row 2 is on the first page. In my opion, this output
may be possible with display-align of the third column set to "after".
As this is not the case in your example, I would consider this a bug.
> the keep-together says
> "A keep-together condition is satisfied if all areas generated and
> returned by the formatting object are descendants of a single
> context-area."
> So this could be applying to the areas returned by each cell, meaning
> that the contents of any cells cannot go over a page.
>
Generally I agree. To put it more precise:
1. The cells of a row with keep-together condition should first of all
be kept on one page.
2. If that condition cannot be met, the row should be split. How this
may be done depends on keep and break conditions of the cells.
3. If the row is split, all cells with the display-align "before" should
start on the first page.
Cells that are aligned to the bottom of the row must end on the page,
where the tallest cell ends.
- Corinna
Re: TableCell or TableRow Larger than a page( bug fix )
Posted by Keiron Liddle <ke...@aftexsw.com>.
I was talking about the strange behaviour in the attached examples.
I think I am mainly considering situations where none of a cell can be
placed in the first page so that the cell starts on the next page and
other cells are placed on the next page that don't need to be.
I'm not saying that all of the row needs to be on the page, just the
start of all the cells in the row.
the keep-together says
"A keep-together condition is satisfied if all areas generated and
returned by the formatting object are descendants of a single
context-area."
So this could be applying to the areas returned by each cell, meaning
that the contents of any cells cannot go over a page.
Corinna Hischke wrote:
> Hi all,
>
> Karen suggested a solution which is fully spec-aware (as far as I can
> tell) and conforms to user expectations as well. I strongly support
> that, especially her two-step-approach:
>
> 1. Try to satisfy requirements specified by properties.
>
> 2. Deliberately give up certain constraints if a sensible solution
> cannot be found otherwise (e.g. splitting content is preferable to
> losing content).
>
> As regards Keiron's argument that complete rows should always appear
> on the same page because otherwise we would in effect have two rows: I
> don't agree for two reasons.
>
> 1. If we applied that argument consistently, we could not split
> anything. Splitting a table would in effect create two tables.
> Splitting a block would in effect create two blocks. I guess this
> is not a 'clear indication of voter intent' ;-).
Thats like saying that if we have an fo:block with text that changes font
size mid sentence it ok to be like so
---------------------------------------------
text text text text text text text text text
text text text text
--------------- page break ---------------
text text text text text
text text text text text text text text text
text text text text
---------------------------------------------
Hence the two lines where there should be one.
>
>
> 2. The table row property 'keep-together' would be meaningless.
>
> - Corinna
Re: TableCell or TableRow Larger than a page( bug fix )
Posted by Corinna Hischke <co...@infix.de>.
Hi all,
Karen suggested a solution which is fully spec-aware (as far as I can
tell) and conforms to user expectations as well. I strongly support
that, especially her two-step-approach:
1. Try to satisfy requirements specified by properties.
2. Deliberately give up certain constraints if a sensible solution
cannot be found otherwise (e.g. splitting content is preferable to
losing content).
As regards Keiron's argument that complete rows should always appear
on the same page because otherwise we would in effect have two rows: I
don't agree for two reasons.
1. If we applied that argument consistently, we could not split
anything. Splitting a table would in effect create two tables.
Splitting a block would in effect create two blocks. I guess this
is not a 'clear indication of voter intent' ;-).
2. The table row property 'keep-together' would be meaningless.
- Corinna
Re: TableCell or TableRow Larger than a page( bug fix )
Posted by Carlos Villegas <ca...@uniscope.co.jp>.
Chris Ryland wrote:
>
> ----- Original Message -----
> From: "Karen Lease" <kl...@club-internet.fr>
> To: <fo...@xml.apache.org>
> Sent: Thursday, November 30, 2000 6:33 PM
> Subject: Re: TableCell or TableRow Larger than a page( bug fix )
>
> > Here is my contribution to the brainstorm.
> [...]
> > Otherwise, try to layout the row in the current area. If any cell is too
> > big to fit in the space remaining, then we must decide whether to split
> > the row or whether to move the whole row to the next page. If the row
> > has a keep-together property which of "always", we push it to the next
> > page, unless the cell is too big to fit there either. In that case, we
> > must break the row.
> > Also, if this row has a keep-with-previous or the preceding row has a
> > keep-with-next, this may lead us to put the preceding row or rows on the
> > next page too. Same case, if the previous row has a spanning cell into
> > this row.
> [...]
>
> All good thoughts, but how do you break a row if there are widely varying
> baseline, vertical justifications, etc.? I.e., just finding a common
> breakpoint for all cells might be a hard challenge. And what do you do with
> a vertically centered cell in a broken row?
Probably for this reason, programs like FrameMaker never try to break a
row,
it simply overflows out of the flow area if it doesn't fit in the page.
Carlos
Re: TableCell or TableRow Larger than a page( bug fix )
Posted by Chris Ryland <cp...@emsoftware.com>.
----- Original Message -----
From: "Karen Lease" <kl...@club-internet.fr>
To: <fo...@xml.apache.org>
Sent: Thursday, November 30, 2000 6:33 PM
Subject: Re: TableCell or TableRow Larger than a page( bug fix )
> Here is my contribution to the brainstorm.
[...]
> Otherwise, try to layout the row in the current area. If any cell is too
> big to fit in the space remaining, then we must decide whether to split
> the row or whether to move the whole row to the next page. If the row
> has a keep-together property which of "always", we push it to the next
> page, unless the cell is too big to fit there either. In that case, we
> must break the row.
> Also, if this row has a keep-with-previous or the preceding row has a
> keep-with-next, this may lead us to put the preceding row or rows on the
> next page too. Same case, if the previous row has a spanning cell into
> this row.
[...]
All good thoughts, but how do you break a row if there are widely varying
baseline, vertical justifications, etc.? I.e., just finding a common
breakpoint for all cells might be a hard challenge. And what do you do with
a vertically centered cell in a broken row?
Cheers!
Chris Ryland, President * Em Software, Inc. * www.emsoftware.com
Re: TableCell or TableRow Larger than a page( bug fix )
Posted by Karen Lease <kl...@club-internet.fr>.
Here is my contribution to the brainstorm.
There are several properties that can influence how to compose table
rows.
These are keeps (keep-together, keep-with-previous, keep-with-next) and
breaks
(break-before/after), and also vertical cell spans. Keeps and breaks are
only taken into account on rows or table-body objects, not on individual
cells.
There are also height (block-progression-dimension) constraints possible
on rows or cells.
Most traditional page layout programs will try to keep entire rows
together on the same page (or in the same column) if that is possible.
That is, they behave as though rows had an implicit
keep-together="always" attribute, and will only break a row if it
contains a cell that is larger than the longest available region. The
XSL FO spec says nothing about this, and the global default for all keep
properties is "auto", meaning there is no keep constraint.
I see the algorithm as being something like this:
If a row has a break-before property other than "auto", or if the
previous row had a break-after property other than auto AND there is no
spanning cell from a previous row, then this row is forced to the next
column/page etc.
Note: the spanning cell limitation is explicit in the description of the
break properties in the latest XSL CR:
"This property has no effect when it appears on an fo:table-row
formatting object in which there is any row spanning occurring that
includes both the current
fo:table-row and the previous one." (7.18.1, 7.18.2)
Otherwise, try to layout the row in the current area. If any cell is too
big to fit in the space remaining, then we must decide whether to split
the row or whether to move the whole row to the next page. If the row
has a keep-together property which of "always", we push it to the next
page, unless the cell is too big to fit there either. In that case, we
must break the row.
Also, if this row has a keep-with-previous or the preceding row has a
keep-with-next, this may lead us to put the preceding row or rows on the
next page too. Same case, if the previous row has a spanning cell into
this row.
Note too, that when we have headers and footers, those should normally
be placed on each segment of a table (there's actually a property which
controls whether or not they are omitted on "middle" segments. But if
they are present, then we should compose at least the header, the footer
and the minimum unbreakable set of rows in the same area!
On the other hand, we don't want to leave pages mostly empty, or wind up
not being able to compose the rows on the next page either. So an
intelligent page layout system always makes some decisions about which
keep constraints to violate. The XSL spec doesn't get down to that level
of detail. It does give weights to keeps properties, so that a system
can try to choose the better solution.
If we do have to break a row, then I think part of each cell is composed
in the first area. Only the cell or cells whose content won't fit should
be split over several areas. Here is a simple example.
------------------------------------------------------------------------
here is a little text | Here is a lot of text in the second cell.
in the first cell. END | Here is a lot of text in the next cell.
| Here is a lot of text in the next cell.
------------------------------------------------------------------------
on the next page....
------------------------------------------------------------------------
| Here is a lot of text in the next cell.
| Here is a lot of text in the next cell.
| Here is a lot of text in the next cell.
| Here is a lot of text in the next cell.
| etc....
------------------------------------------------------------------------
An alternative to breaking a row which is too big to fig on any page is
to clip it or to overflow it. This can also happen if the stylesheet
specifies a fixed height for the table cell or row and the content won't
fit in that height. But this is generally not what users want.
Regards,
Karen
Hani Elabed wrote:
>
> Chris, Scott, Alex, and Steven(both), and Eric S. I guess,
> oh what the heck and of course the BigKahunahs(Arved and Fotis)
> and All of you out there I guess,
>
> Point well taken, I am guilty of not being
> very familiar with "keep together/keep with next".
> Could you elaborate what is your understanding
> of how they should work based on different senarios??
>
> For example would the "keep together/keep with next"
> be a property of TableRow or TableCell??
>
> And what would happen if "keep together/keep with next"
> are turned are set for a parent table and not so
> for a child table, or the reverse??
>
> I am trying to have all of us
> brainstorm this out if you will...
>
> Thanks in advance to all for your input.
>
> Hani Elabed
>
> Chris Ryland wrote:
> >
> > Shouldn't table row breaking pay attention to the union/intersection of all
> > the "keep together/keep with next" properties of the row's cells, rather
> > than inventing a new property?
> >
> > Cheers!
> > Chris Ryland, President * Em Software, Inc. * www.emsoftware.com
> > ----- Original Message -----
> > From: "Hani Elabed" <ha...@mail.elabed.net>
> > To: <fo...@xml.apache.org>
> > Cc: "hani" <ha...@mail.elabed.net>; "hani.elabed"
> > <ha...@courts.state.wi.us>; "ken mckelvey"
> > <ke...@courts.state.wi.us>; "vicky daniels"
> > <vi...@courts.state.wi.us>
> > Sent: Wednesday, November 29, 2000 2:43 PM
> > Subject: Re: TableCell or TableRow Larger than a page( bug fix )
> >
> > >
> > > And the question is do we need to add a property
> > > to the TableRow that specifies the percentage of the
> > > bottom of the page body below which we should not
> > > start a new row, but rather go to the next page
> > > and start there. Of course if that row is bigger
> > > than the next page, we need to lay it out anyway or
> > > fire an exception...
Re: TableCell or TableRow Larger than a page( bug fix )
Posted by Hani Elabed <ha...@elabed.net>.
Chris, Scott, Alex, and Steven(both), and Eric S. I guess,
oh what the heck and of course the BigKahunahs(Arved and Fotis)
and All of you out there I guess,
Point well taken, I am guilty of not being
very familiar with "keep together/keep with next".
Could you elaborate what is your understanding
of how they should work based on different senarios??
For example would the "keep together/keep with next"
be a property of TableRow or TableCell??
And what would happen if "keep together/keep with next"
are turned are set for a parent table and not so
for a child table, or the reverse??
I am trying to have all of us
brainstorm this out if you will...
Thanks in advance to all for your input.
Hani Elabed
Chris Ryland wrote:
>
> Shouldn't table row breaking pay attention to the union/intersection of all
> the "keep together/keep with next" properties of the row's cells, rather
> than inventing a new property?
>
> Cheers!
> Chris Ryland, President * Em Software, Inc. * www.emsoftware.com
> ----- Original Message -----
> From: "Hani Elabed" <ha...@mail.elabed.net>
> To: <fo...@xml.apache.org>
> Cc: "hani" <ha...@mail.elabed.net>; "hani.elabed"
> <ha...@courts.state.wi.us>; "ken mckelvey"
> <ke...@courts.state.wi.us>; "vicky daniels"
> <vi...@courts.state.wi.us>
> Sent: Wednesday, November 29, 2000 2:43 PM
> Subject: Re: TableCell or TableRow Larger than a page( bug fix )
>
> >
> > And the question is do we need to add a property
> > to the TableRow that specifies the percentage of the
> > bottom of the page body below which we should not
> > start a new row, but rather go to the next page
> > and start there. Of course if that row is bigger
> > than the next page, we need to lay it out anyway or
> > fire an exception...
Re: TableCell or TableRow Larger than a page( bug fix )
Posted by Chris Ryland <cp...@emsoftware.com>.
Shouldn't table row breaking pay attention to the union/intersection of all
the "keep together/keep with next" properties of the row's cells, rather
than inventing a new property?
Cheers!
Chris Ryland, President * Em Software, Inc. * www.emsoftware.com
----- Original Message -----
From: "Hani Elabed" <ha...@mail.elabed.net>
To: <fo...@xml.apache.org>
Cc: "hani" <ha...@mail.elabed.net>; "hani.elabed"
<ha...@courts.state.wi.us>; "ken mckelvey"
<ke...@courts.state.wi.us>; "vicky daniels"
<vi...@courts.state.wi.us>
Sent: Wednesday, November 29, 2000 2:43 PM
Subject: Re: TableCell or TableRow Larger than a page( bug fix )
>
> And the question is do we need to add a property
> to the TableRow that specifies the percentage of the
> bottom of the page body below which we should not
> start a new row, but rather go to the next page
> and start there. Of course if that row is bigger
> than the next page, we need to lay it out anyway or
> fire an exception...
Re: TableCell or TableRow Larger than a page( bug fix )
Posted by Hani Elabed <ha...@elabed.net>.
Greetings.
the decision of weather to take the whole row
to the next page or to just start laying it out
on the spot is a matter of perspective...
We found out that it is more usefull to us to start laying
it out because we did not want to waste page space.
And this is what caused the infinite loop bug in the
first place.
If that row was bigger than this page, it is most likely
bigger than the next page... So rather than dealing with
this kind of decision making, we decided to start laying it
out immediately..
Of course we can all agree on a certain criteria...
For example, if the row at hand is on the bottom 10%(or some%)
of the body of the page, then move that whole row
to the next page... I am guilty here of NOT having
read the W3C specs.. so any guidance will be appreciated...
And the question is do we need to add a property
to the TableRow that specifies the percentage of the
bottom of the page body below which we should not
start a new row, but rather go to the next page
and start there. Of course if that row is bigger
than the next page, we need to lay it out anyway or
fire an exception...
Your guidance is appreciated, for now I will
postponne Alex Sanderson's suggestion below
until I hear from all.
Hani
PS: Alex, Arved, Fotis, Eric, Steve, or Keiron.
Can somebody commit the changes I have
made so far, they provide a better solution
than what is currently on the CVS ??
Alex Sanderson wrote:
>Hi Hani,
>
>I have just been testing out your patch. It is excellent thank you.
>I have noticed a problem with tables inside tables.
>
>I hope this works :)
>|-----------------------------------------------|
>| Parent Table |
>| |-------------------------------------------| |
>| | Parent Row1 | |
>| ||-------------------| |-------------------|| |
>| || Table 1 | | Table 2 || |
>| |||--------|--------|| ||-------|---------||| |
>| ||| t1c1 | t1c2 || || t2c1 | t2c2 ||| |
>| |||--------|--------|| ||-------|---------||| |
>| ||-------------------| |-------------------|| |
>| |-------------------------------------------| |
>| |
>|-----------------------------------------------|
>
>If t2c2 is too big, the table breaking algorithm puts it on the next page.
>Instead of putting the whole of the parent table row on the next page it
>just puts t2c2 on the next page and continues with table2 there. t2c1 is left
>on the first page, I think it should follow to the second page. Also I think that
>the whole of the parent row should start on the next page.
>
>Thanks again for the patch it has really saved me.
>Alex