On Sep 16, 2005, at 16:31, Andreas L Delmelle wrote:
YES! Got it.
Ok, so I ended up thoroughly revising my approach, to account for the
starts-row/ends-row issue that was the topic of this thread.
One thing I also hadn't considered, but which I also succeeded in
dealing with now, is out-of-order column-numbers. The note in the Rec
about there not being a requirement for column-numbers to be
'monotonically increasing' also seems to imply that an author is
allowed, in theory, to do the following:
<fo:table>
<fo:table-column column-number="5" />
<fo:table-column column-number="2" />
<fo:table-column column-number="4" />
<fo:table-column column-number="3" />
<fo:table-column column-number="1" />
...
Admitted, I would never, ever do this myself, but it seems to be
permitted, so I thought I'd provide support for this anyway.
In the following case then
<fo:table>
<fo:table-column column-number="5" />
<fo:table-column column-number="2" />
<fo:table-column />
<fo:table-column />
<fo:table-column column-number="1" />
...
the column-numbers for the third and fourth column in the above
sequence would default to '3' and '4' respectively, just as the Rec
mandates: the column-number of the previous column plus one. (Note that
if the column-number of the second column weren't specified, this would
default to '6', and for the third and fourth, the initial values would
then become '7' and '8'...)
One more question before I can wrap this up (about tables without
explicit columns):
Should the number of implicit columns be considered body-per-body?
If not, and the table has no header, but it does have a footer, can the
first row of the footer be considered the basis for determining the
number of implicit columns?
Maybe a quite exotic case, which I personally would avoid, but you
never know...
Perhaps, this isn't even worth considering at that point. We could just
assign the column-numbers on row-per-row basis, and have layout
complain about this in case of fixed table-layout if a row that is not
the first one contains more cells than there are in the first row
(which currently already happens IIC?)
One other issue I didn't solve yet, but this was already a problem
before my modifications, is a specified column-number that is negative
or zero.
Note: one of the consequences of my modifications will be that a
zero-value will only occur in case it was explicitly specified by the
user. Again, I would personally avoid this at all costs, and make the
stylesheet such that this could never occur, but you never know...
According to the Rec, this is no real error. The column-number should,
in that case, be rounded to the nearest integer value greater than or
equal to 1 (which I personally would interpret as: the nearest
available non-occupied column-number). Currently, a PropertyException
is thrown for this in TableColumn.bind().
Now, it's a piece of cake to force the columnNumber instance variable
of the column in question, but in order to make it pass an eventual
FOTree test, this should be dealt with while creating the property
itself --so that it's already correct in the PropertyList. Maybe in
that case, I'd need to provide more than just a custom
PropertyMaker...?
Well, in order to evaluate that, it's probably best to wait until my
commit --finally-- comes through.
Cheers,
Andreas
