On Sep 15, 2005, at 16:05, Jeremias Maerki wrote:

Jeremias,

Ok, let me then explicitely state that my previous mail contained my own interpretation and no facts. IMO there are certain gaps and inaccuracies
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 hear/see *sigh*

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
starts-row="true" on.

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: ends-row).

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 error.

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.


Cheers,

Andreas

Reply via email to