On 16.09.2005 11:43:37 Andreas L Delmelle wrote:
> 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...

Absolutely no resentment here. I'm sorry for sending the wrong signals.
I simply realized that I was not clear enough that the stuff I wrote is
just my opinion. Stuff like that always happens if I don't want to lose
too much time. Sigh.

A fact is that I'm relatively tired. I've spent a lot of time on FOP and
on mailing lists lately and it can wear you out. A long time I made
myself think I had to chime in everywhere to make sure things are
running smoothly, but I'm quite happy to see that things have started to
run by themselves lately. It looks like my mission (and that of my
sponsor) to kickstart FOP again was a success. I will probably dial down
my efforts on FOP just a little bit when the first release is out. Don't
worry: no plans to go a away!

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

Solved yes, but it's not clear if that interpretation was right. Maybe
I'm indeed wrong.

> 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?

Yes, sure, but the problem is that in this case I think it's no error.
I wonder what the others think about this. No other comments so far. 
:-( Everyone is probably avoiding another nasty thread. *bg*

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

That's always dangerous IMO. We should always be focused on the user.

> The question remains: how many times does that happen in reality? Do 
> you, personally, use starts-row/ends-row very frequently? 

No. I always use table-row.

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

Yes, please. I think the idea behind the two properties was really
simplifying the task for stylesheet developers so they can easily build
up tables. Nobody will ever explicitely write a "false" value for the
two properties into his stylesheet. He will only set a "true" value when
he knows that he needs to start (or end) a row (depending on the
stylesheet logic).

Glen would say we should contact the FO WG for a clarification.

Jeremias Maerki

Reply via email to