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 ;-))
