Re: Disable 900 penalty when not all cells have contributed in tables?
Thanks for all your feedbacks. Hearing no objections, I’ll then commit the change in the next days. Vincent Vincent Hennebert wrote: > Hi, > > The title may be a little cryptic for those who aren’t familiar with the > table layout code :-\ But basically it corresponds to the following: > > When a row starts at the bottom of a page, there may not be enough > remaining room to allow every cell to put a part of its content: > > | Cell 1 | | > > - Page break --- > > | | This text doesn’t fit | > | | on the previous page | > > > Currently, a 900 penalty is assigned to such a break possibility, to > avoid as much as possible this situation from occurring. > > However, it doesn’t completely prevent it, as we have seen recently on > fop-users. My proposal is to forbid it, as anyway the output is so ugly > that one would probably prefer some extra blank space at the bottom of > the page instead. > > Is there anyone against me applying this change? > > Thanks, > Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
Re: Disable 900 penalty when not all cells have contributed in tables?
Vincent, > > both of them I'd prefer to see split onto two pages. So imo a high > > penalty is better > That will still be possible with the infinite penalty (assuming your > "1.5 pages" contain enough break possibilities in between). The rule > here is only to make sure that every column contributes at least the > content before the first break possibility (for each column) to a row > before the row is considered breakable. In this case +1, I can't think of any other cases where this could fail. > > > When a row starts at the bottom of a page, there may not be enough > > > remaining room to allow every cell to put a part of its content: > > > > > > | Cell 1 | | > > > > > > - Page break --- > > > > > > | | This text doesn’t fit | > > > | | on the previous page | > > > > > > Max
Re: Disable 900 penalty when not all cells have contributed in tables?
On 09.01.2008 16:19:33 Max Berger wrote: > Vincent, > > please consider the case where a table cell is long, or even longer than > a page. In this case it should break it anyways. Also, consider these > cases: > > ++ > | 0.25 pages | > ++ > | 1.5 pages | > ++ > | 0.25 pages | > ++ > > > +---+ > | 0.5 pages | > +---+ > | 0.9 pages | > +---+ > | 0.5 pages | > +---+ > > both of them I'd prefer to see split onto two pages. So imo a high > penalty is better That will still be possible with the infinite penalty (assuming your "1.5 pages" contain enough break possibilities in between). The rule here is only to make sure that every column contributes at least the content before the first break possibility (for each column) to a row before the row is considered breakable. > btw: does the fop spec not specify that a table should be closed when > broken? e.g. Assuming you're talking about table borders, that depends on the ".conditionality" component on the border. > > +-+ > | much| > | content | > +-+ > > to: > > +-+ > | much| > +-+ > pagebreak > +-+ > | content | > +-+ > > ? > > just my 2 cts. > > Max > > On Mit, 2008-01-09 at 14:27 +, Vincent Hennebert wrote: > > Hi, > > > > The title may be a little cryptic for those who aren’t familiar with the > > table layout code :-\ But basically it corresponds to the following: > > > > When a row starts at the bottom of a page, there may not be enough > > remaining room to allow every cell to put a part of its content: > > > > | Cell 1 | | > > > > - Page break --- > > > > | | This text doesn’t fit | > > | | on the previous page | > > > > > > Currently, a 900 penalty is assigned to such a break possibility, to > > avoid as much as possible this situation from occurring. > > > > However, it doesn’t completely prevent it, as we have seen recently on > > fop-users. My proposal is to forbid it, as anyway the output is so ugly > > that one would probably prefer some extra blank space at the bottom of > > the page instead. > > > > Is there anyone against me applying this change? > > > > Thanks, > > Vincent > > > > Jeremias Maerki
Re: Disable 900 penalty when not all cells have contributed in tables?
+1 I guess it makes sense. On 09.01.2008 15:27:29 Vincent Hennebert wrote: > Hi, > > The title may be a little cryptic for those who aren’t familiar with the > table layout code :-\ But basically it corresponds to the following: > > When a row starts at the bottom of a page, there may not be enough > remaining room to allow every cell to put a part of its content: > > | Cell 1 | | > > - Page break --- > > | | This text doesn’t fit | > | | on the previous page | > > > Currently, a 900 penalty is assigned to such a break possibility, to > avoid as much as possible this situation from occurring. > > However, it doesn’t completely prevent it, as we have seen recently on > fop-users. My proposal is to forbid it, as anyway the output is so ugly > that one would probably prefer some extra blank space at the bottom of > the page instead. > > Is there anyone against me applying this change? > > Thanks, > Vincent > > > -- > Vincent HennebertAnyware Technologies > http://people.apache.org/~vhennebert http://www.anyware-tech.com > Apache FOP Committer FOP Development/Consulting Jeremias Maerki
Re: Disable 900 penalty when not all cells have contributed in tables?
On Jan 9, 2008, at 18:59, Jay Bryant wrote: Hi Jay, My opinion doesn't count, but I'm for it. Just wondering: What do you mean by "doesn't count"? You are a committer, so your opinion most definitely counts here... :-) Cheers Andreas
Re: Disable 900 penalty when not all cells have contributed in tables?
On Jan 9, 2008, at 15:27, Vincent Hennebert wrote: Hi Vincent, Currently, a 900 penalty is assigned to such a break possibility, to avoid as much as possible this situation from occurring. However, it doesn’t completely prevent it, as we have seen recently on fop-users. My proposal is to forbid it, as anyway the output is so ugly that one would probably prefer some extra blank space at the bottom of the page instead. Is there anyone against me applying this change? Absolutely no objection from me. Cheers Andreas
Re: Disable 900 penalty when not all cells have contributed in tables?
My opinion doesn't count, but I'm for it. For me and my customers, a cell that begins on one page and ends on another is never desirable. Jay Bryant Bryant Communication Services http://www.bryantcs.com/
Re: Disable 900 penalty when not all cells have contributed in tables?
Hi Max, Max Berger wrote: > Vincent, > > please consider the case where a table cell is long, or even longer than > a page. In this case it should break it anyways. Also, consider these > cases: Well this is a different issue. The fact that at least the beginning of each cell should be present on the first page wouldn’t prevent cells from being broken over several pages. Unless a cell contains one big unbreakable content, but this is a degenerate case. And the output will still look better if the contents of the other cells are on the same page as this big one. Follow me? Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
Re: Disable 900 penalty when not all cells have contributed in tables?
Vincent, please consider the case where a table cell is long, or even longer than a page. In this case it should break it anyways. Also, consider these cases: ++ | 0.25 pages | ++ | 1.5 pages | ++ | 0.25 pages | ++ +---+ | 0.5 pages | +---+ | 0.9 pages | +---+ | 0.5 pages | +---+ both of them I'd prefer to see split onto two pages. So imo a high penalty is better btw: does the fop spec not specify that a table should be closed when broken? e.g. +-+ | much| | content | +-+ to: +-+ | much| +-+ pagebreak +-+ | content | +-+ ? just my 2 cts. Max On Mit, 2008-01-09 at 14:27 +, Vincent Hennebert wrote: > Hi, > > The title may be a little cryptic for those who aren’t familiar with the > table layout code :-\ But basically it corresponds to the following: > > When a row starts at the bottom of a page, there may not be enough > remaining room to allow every cell to put a part of its content: > > | Cell 1 | | > > - Page break --- > > | | This text doesn’t fit | > | | on the previous page | > > > Currently, a 900 penalty is assigned to such a break possibility, to > avoid as much as possible this situation from occurring. > > However, it doesn’t completely prevent it, as we have seen recently on > fop-users. My proposal is to forbid it, as anyway the output is so ugly > that one would probably prefer some extra blank space at the bottom of > the page instead. > > Is there anyone against me applying this change? > > Thanks, > Vincent > >
Disable 900 penalty when not all cells have contributed in tables?
Hi, The title may be a little cryptic for those who aren’t familiar with the table layout code :-\ But basically it corresponds to the following: When a row starts at the bottom of a page, there may not be enough remaining room to allow every cell to put a part of its content: | Cell 1 | | - Page break --- | | This text doesn’t fit | | | on the previous page | Currently, a 900 penalty is assigned to such a break possibility, to avoid as much as possible this situation from occurring. However, it doesn’t completely prevent it, as we have seen recently on fop-users. My proposal is to forbid it, as anyway the output is so ugly that one would probably prefer some extra blank space at the bottom of the page instead. Is there anyone against me applying this change? Thanks, Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
