On Aug 26, 2005, at 21:32, Jeremias Maerki wrote:

You got me a little shocked when I read your post.


Really? Good! Nothing personal, but I always tend to take 'shock-and-awe' to be a sign that I'm on the right track. I remember having driven Glen crazy on a few occasions, and that was precisely *because* I was right --although I was far from certain of it at the time.

Now I'm afraid I should have realized earlier on what you're up to.

Afraid? Why exactly? Because you were so enthusiastic about the possibility of collapsing borders being supported by FOP, and now you fear that this enthusiasm was misplaced (or premature)? Well, I'll do my best not to be discouraged by your fear. :-)

I hope you were able to reuse at least a bit of the code I already wrote for the collapsing
border model.

Sure. That's why that step was completed so quickly. Because there was no need to start from scratch. Resolving the border conflicts in the FOTree will take a little more time, as that approach greatly differs from your initial solution to handle it *all* in layout. Still, see my recent reply to Peter Herweg's concerns. Now, apply that to this situation: if you hadn't done that work a few months back and committed it, what I'm doing now would definitely take much longer.

As far as I can remember most of that already worked quite well (everything except element generation, I mean). The reason I stopped with the collapsing border model was my failure to come up with the right rules to handle the Knuth element generation for the cases
where headers and footers interact with body cells.

Hmm... I see what you mean, but I'm taking this step (a step back?) precisely because I strongly suspect that the rules for element generation will become more apparent if/when the layout package is made to deal *only* with the layout-specific cases.

<snip />
But I'm really concerned that you're hacking away on something for which
a fundamental problem isn't solved, yet.

Maybe so, but as I already pointed out somewhere in our discussion back then, the logic behind collapsing borders simply does not belong *in* the layout package. It only has to be *reachable* from there, in case the LM's need to resolve borders for the break/span situations. So, is this move necessary? Maybe not. I can't say. Is it desirable? IMO most definitely.

Sure, it's a risk. Maybe eventually, when having to deal with that 'fundamental' problem, I too will reach a point where I'll be inclined to give up. Then again, maybe, in the meantime some ideas will arise on how to facilitate the eventual solution. I can't predict the future with absolute certainty, but I've got a hunch... Of course, it would be presumptuous to state that I *will* make it work, so I'm not going to. What I *am* going to do is *try* to make it appear more trivial than it is now. Even if it becomes only a tiny bit more trivial, that could well turn out to give us just what we were looking for. (In the worst case, by the time I'm done, I will have gained valuable insights into the innards of the properties-, fo- and layout-packages, so *I* can't view that to be a waste of time...)

Did you verify beforehand that you understand the interactions between cells in break-conditions especially with headers and footers present? That's where I gave up back
in May [1].

I'm aware of the difficulties, but I am currently pretty convinced that, once the first part is completed --the move to the fo.flow/fo.properties packages-- this will somehow become easier to sort out. Strange as it may sound, ATM I (have to) force myself to ignore those interaction problems, as they bear no relation (yet) to what I feel needs to happen in the FOTree. Once this task is finished, layout problems will appear as exactly that: _layout_ problems. One thing I didn't mention yet is that 'moving' the logic is actually a big word, since I've yet to remove the references to it from the layout code. Currently 'copying' would perhaps better describe it. So, there's still another opportunity to bump in to ideas: when I'm forced to adapt the layout code to the new situation.

One thing's for certain: it *will* make a difference, and I can only hope the difference will turn out to be a crucial one.


Cheers,

Andreas
(with fingers crossed ;-))

Reply via email to