Re: svn commit: r494416 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/Table.java

[Andreas L Delmelle <a_...@pandora.be>]

On Jan 9, 2007, at 15:22, vhennebert@apache.org wrote:

> Author: vhennebert
> Date: Tue Jan  9 06:21:59 2007
> New Revision: 494416
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=494416
> Log:
> In relaxed validation mode, it should be acceptable to have  
> fo:table-footer /after/ fo:table-body

Just a little note about this. I'm not vetoing this change but I  
would certainly not recommend it. Allowing a table-footer as last  
element in the table drastically increases the complexity of layout  
of multi-page tables.

True, in the current design, the whole table is present when layout  
beings (so that means flow.Table.tableFooter will be non-null if  
there is a footer), but consider the difficulties if we were to alter  
this interaction, and begin layout for the Table before the end of  
the table is reached. At that point, the footer might not yet be  
present, and we would again be stuck in a situation where we need to  
have the entire table in memory...

Just a thought.


Cheers,

Andreas

Re: svn commit: r494416 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/Table.java

[Vincent Hennebert <vi...@anyware-tech.com>]

Hi Andreas,

Andreas L Delmelle a écrit :
> On Jan 9, 2007, at 15:22, vhennebert@apache.org wrote:
> 
>> Author: vhennebert
>> Date: Tue Jan  9 06:21:59 2007
>> New Revision: 494416
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=494416
>> Log:
>> In relaxed validation mode, it should be acceptable to have
>> fo:table-footer /after/ fo:table-body
> 
> Just a little note about this. I'm not vetoing this change but I would
> certainly not recommend it. Allowing a table-footer as last element in
> the table drastically increases the complexity of layout of multi-page
> tables.
> 
> True, in the current design, the whole table is present when layout
> beings (so that means flow.Table.tableFooter will be non-null if there
> is a footer), but consider the difficulties if we were to alter this
> interaction, and begin layout for the Table before the end of the table
> is reached. At that point, the footer might not yet be present, and we
> would again be stuck in a situation where we need to have the entire
> table in memory...
> 
> Just a thought.

Well, personally I would probably not have changed anything if I hadn't
been asked to, you know... It seems that documents with fo:table-footer
after fo:table-body are quite common in real world cases.

Now I understand your concern. What I propose to do is the following:
1. display a warning that putting table-footer after table-body is evil,
   even in relaxed validation mode;
2. throw an error if the enclosing table has
   "table-omit-footer-at-break" = false and a table-footer is discovered
   after table-body. That's the only case where there would be a
   negative impact on performance, IIC.

I think if we choose 2. then we can forget 1.

WDYT?
Vincent