Ok, the shock is gone. Thank you for reassuring me that you know what you do. That was my biggest concern. I'm happy that you can reuse some of my code. Finally, someone can use something I wrote to make better progress. Normally, it's the other way around. :-) So I'm wishing you the best of luck and I will assist where I can. I'm extremely excited about the prospect of having collapsing borders around. And thanks for taking this task upon you.
On 27.08.2005 00:01:47 Andreas L Delmelle wrote: > 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 ;-)) Jeremias Maerki
