On Mar 19, 2007, at 15:01, Vincent Hennebert wrote:
<snip />
We could mimic the HTML specification to a certain extent, that is:
- if table-columns are specified, they fix the number of columns
and any
row having more columns would be considered erroneous;
- otherwise, I see two possibilities:
- either we use the row which has the most columns; this would have
a potentially heavy impact on memory consumption since the table
would have to be read in its entirety. IIC that's already the case
today, but if we are to implement some producer-consumer model
as we
recently discussed about this will become noticeable. But that
would
be a nice-to-have for users who don't care about memory
consumption
or for simple tables. All the more than if they do care, they
would
just have to add fo:table-columns objects.
- or we do as currently, that is rely on the first rows of each
table-header/footer/body. But then we would have to take only the
first table-body into account, to avoid a bad impact on memory.
I'm personally in favor of the first solution, because it provides
means
to satisfy everyone: speed as well as flexibility.
The first solution seems acceptable to me, for fixed-layout. In
theory, it /could/ happen that the first row of the body/header/
footer has more cells than there are explicit columns, but I think we
can safely assume that to be an anomaly rather than the author's
intent. The message being: either use implicit or explicit columns,
but a mixture should be avoided.
For auto-layout, however, I even think that the maximum number of
columns could vary between one page and the next... but we're still
far from having auto-layout completely implemented, so we'll cross
that bridge once we get there.
Cheers,
Andreas
