xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Hennebert <vincent.henneb...@anyware-tech.com>
Subject Re: svn commit: r494416 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/Table.java
Date Sun, 14 Jan 2007 15:55:44 GMT
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.


View raw message