On Sep 15, 2005, at 16:05, Jeremias Maerki wrote:
Ok, let me then explicitely state that my previous mail contained my
interpretation and no facts. IMO there are certain gaps and
in the spec and I tried to take my own expectations and create an
interpretation that makes sense.
I could be wrong about this, but I seem to be detecting a hint of
resentment here. If so, and if this was caused in any way by something
I said, or my unfortunate way of putting it, please note that the 'No
offence' part was to be taken literally, really...
As for myself, well, I'm quite used to people resenting it when they
are confronted with facts that deviate from what they'd like to
Maybe it has to do with the fact that, from your POV, I'm bothering you
with a minor issue, since it is "already solved". True enough, it
works, but IMO the place where this is dealt with is wrong. The
layout-engine should be able to depend on the initial values for
column-number instead of having to determine them itself. From the POV
of layout, your interpretation doesn't pose much of a problem, because
by that time the table's tree-structure is already fully known.
I'm concerned with providing the correct initial values for the FObj
*as* they are added to the tree. This has an advantage, since
overlapping cells (an error according to the Rec) will be caught
*before* layout begins for that page-sequence (more or less in the
spirit of validation of the tree).
(Besides that: providing these column-numbers in the FOTree is vital
for my collapsing-border strategy, so I fear I'm not completely
objective here ;-))
Let me just say that I would really,
really hate to receive an error message because I didn't specify an
ends-row="true" on the cell preceding the one I specified a
Fair enough, but I feel compelled to add that personally, I just
really, really hate to receive *any* error message whatsoever. I am
reasonable enough, though, not to expect FOP --or any application for
that matter-- to compensate for my own deficiencies, whether it be
typos, laziness or plain stupidity. The line has to be drawn somewhere.
If you'd really hate to receive an error message, then don't do it.
It's as simple as that. You'll receive that error message once, and
you'll immediately know how to avoid it the next time, no?
Still, I've postponed my commit, trying to come up with ways to
accommodate you, but I'm having a bit of difficulty to reconcile
determining the correct initial values for the column-number property
with ignoring the initial values for other related properties (here:
Allow me to explain:
For tables with cells as direct descendants of the table-body, my
strategy depended on the value of the ends-row property to reset the
TableBody's columnIndex to the first non-occupied column-number so that
it is correct by the time the property system has to provide the
default for the next TableCell. Made perfect sense to me...
One idea I considered is adding a check to see whether the maximum
number of columns has been exceeded when increasing the columnIndex.
Things I don't really like about this:
a) this would mean adding yet another instance variable to the Table or
TableBody to keep track of the columnCount, since there is no guarantee
that the table will have explicit columns (minor inconvenience)
b) if the table doesn't have explicit columns, this could pose problems
for the first row, since that's where that maximum column-number will
have to be determined (so, this maximum will be exceeded for every
cell) (difficult problem from the POV of the FOTree)
c) even if I do get it to work, this would still break in case a given
row doesn't have as many cells (including column-spans) as there are
columns, and the mentioned contradiction between ends-row/starts-row
occurs (difficult problem from the POV of the FOTree)
So, I'm still wondering whether it wouldn't be more convenient --from
the POV of the implementor, not the user-- to simply consider it an
The question remains: how many times does that happen in reality? Do
you, personally, use starts-row/ends-row very frequently? Well, I don't
--since I was a 0.20.5 user, which didn't provide this functionality--,
but when I do, I would tend to balance out starts-row/ends-row (because
that is my interpretation of the Rec)
All things considered, we definitely could be relaxing/forgiving for
the case where a cell has an explicit ends-row="true" and the next cell
lacks an explicit starts-row="true"... I see no problem with that. On
the contrary, this would be dealt with automatically. If you'd really,
really hate to receive an error message in *that* case, you're really,
really going to love this.