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.



Reply via email to