Re: Collapsing borders: FOTree stage -- progress update
On Sun, 28 Aug 2005 10:33 am, Manuel Mall wrote: On Sat, 27 Aug 2005 02:07 am, Andreas L Delmelle wrote: Hi all, snip/ * The first step I took was moving much of the logic that is currently in CollapsingBorderModelEyeCatching (in the layout package) to CommonBorderPaddingBackground. I must admit I know very little about collapsing borders. Therefore if my comment is useless just ignore it. Oooops - you better ignore this. Just realised that while padding and margin allow percentages border-width doesn't. So its not an issue. Sorry for the noise. Manuel I have recently worked on all this percentage stuff. This applies also to border-width specifications. I believe border-width is one of the inputs to the border collapse algorithm. Relative border-width specifications can only be resolved at layout time (with the appropriate context). This seems to indicate the border collapse algorithm (at least the parts related to border-width) can only run during layout. snip/ Cheers, Andreas Manuel
Re: Collapsing borders: FOTree stage -- progress update
On Aug 28, 2005, at 04:33, Manuel Mall wrote: I must admit I know very little about collapsing borders. Therefore if my comment is useless just ignore it. Well, I certainly don't think it's useless... I have recently worked on all this percentage stuff. This applies also to border-width specifications. I believe border-width is one of the inputs to the border collapse algorithm. Relative border-width specifications can only be resolved at layout time (with the appropriate context). This seems to indicate the border collapse algorithm (at least the parts related to border-width) can only run during layout. Not really, I think. That has been on my mind as well, but as I see it, the border-widths will always be available as Length properties (not necessarily as fixed widths, unless they were already specified in the source document as such). I don't really intend to resolve those widths yet, just determine at FOTree stage *which* border (as in: specified on *which* element) will be applicable. If they were specified as percentages, those will still need to be resolved further on. Does this address your concerns, or am I misunderstanding you here? Cheers, Andreas
Re: Collapsing borders: FOTree stage -- progress update
On Aug 28, 2005, at 14:38, Andreas L Delmelle wrote: On Aug 28, 2005, at 00:06, Jeremias Maerki wrote: AFAIK you're trying to move the pre-resolvable pieces into the FO tree while you only do the specialities in the LMs, right? Exactly. Come to think of it, maybe that last idea won't be feasible Just for the sake of completeness (since I snipped away too much of my own message :-) ) I'm talking about my own idea of storing extra BorderInfo instances. Cheers, Andreas
Re: Collapsing borders: FOTree stage -- progress update
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
Re: Collapsing borders: FOTree stage -- progress update
On Aug 27, 2005, at 09:09, Jeremias Maerki wrote: 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. :-) FWIW, I noticed that as well. So I'm wishing you the best of luck and I will assist where I can. Thanks. I already have a few remarks, but I'm not sure that you can offer assistance. This is mainly because there is an inherent difficulty in that XSL-FO 1.0 refers entirely to CSS for border-resolution rules, but CSS was written with HTML in mind... It's all so much simpler if there exists no such thing as page-breaks and you have to deal with one continuous table. Maybe this issue should be addressed at W3C? It's understandable that the XSL-FO WG wanted very much to avoid having to duplicate rules that are already defined in other Recommendations, but simply pointing to CSS, which was clearly meant for non-paginated layout, seems to leave too much room for implementation-dependent behavior... I'm wondering, for instance, whether the table's before-border specs are only relevant for the first page that is spanned by the table. For example: in case the table has a header (and omit-header-at-break=false), and the table's before-border wins, then it can still *appear* on the following pages (but that will be because it *is* the header's before-border). Another one to chew on: start from a table without header/footer which does have multiple bodies. Suppose also that there are no borders specified on any elements other than the bodies (for the sake of simplicity). Now, if it turns out that a page-break occurs right in between the two bodies, does this mean that the later body's before-border still must be collapsed with the earlier body's after-border (so in this simplified case the after-border on one page will *always* be the same as the before-border on the next)? Cheers, Andreas
Re: Collapsing borders: FOTree stage -- progress update
On 27.08.2005 21:33:44 Andreas L Delmelle wrote: On Aug 27, 2005, at 09:09, Jeremias Maerki wrote: 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. :-) FWIW, I noticed that as well. So I'm wishing you the best of luck and I will assist where I can. Thanks. I already have a few remarks, but I'm not sure that you can offer assistance. This is mainly because there is an inherent difficulty in that XSL-FO 1.0 refers entirely to CSS for border-resolution rules, but CSS was written with HTML in mind... It's all so much simpler if there exists no such thing as page-breaks and you have to deal with one continuous table. Maybe this issue should be addressed at W3C? It's understandable that the XSL-FO WG wanted very much to avoid having to duplicate rules that are already defined in other Recommendations, but simply pointing to CSS, which was clearly meant for non-paginated layout, seems to leave too much room for implementation-dependent behavior... I'm wondering, for instance, whether the table's before-border specs are only relevant for the first page that is spanned by the table. For example: in case the table has a header (and omit-header-at-break=false), and the table's before-border wins, then it can still *appear* on the following pages (but that will be because it *is* the header's before-border). No, the table only has an own border in the separate border model. In the collapsing border model only cells have borders. The FO spec is very clear on that. So it's absolutely normal that the border specified on the table-level can reappear on the following pages based on who ever wins. Another one to chew on: start from a table without header/footer which does have multiple bodies. Suppose also that there are no borders specified on any elements other than the bodies (for the sake of simplicity). Now, if it turns out that a page-break occurs right in between the two bodies, does this mean that the later body's before-border still must be collapsed with the earlier body's after-border (so in this simplified case the after-border on one page will *always* be the same as the before-border on the next)? No, I don't think so. I believe the collapsing only happens between two effectively adjacent cells, i.e., translated to one of our stages, more located in the area tree stage than in the FO tree stage, if you know what I mean. But I'm not sure here, because I think the spec is really not that clear in this little detail. But I'd also think it would be strange if the border after from the previous page would bleed over to the next page in this way. Jeremias Maerki
Re: Collapsing borders: FOTree stage -- progress update
On Aug 27, 2005, at 22:22, Jeremias Maerki wrote: On 27.08.2005 21:33:44 Andreas L Delmelle wrote: I'm wondering, for instance, whether the table's before-border specs are only relevant for the first page that is spanned by the table. For example: in case the table has a header (and omit-header-at-break=false), and the table's before-border wins, then it can still *appear* on the following pages (but that will be because it *is* the header's before-border). No, the table only has an own border in the separate border model. In the collapsing border model only cells have borders. The FO spec is very clear on that. So it's absolutely normal that the border specified on the table-level can reappear on the following pages based on who ever wins. I see. That seems to be exactly what I expected (although again, I described it in the wrong terms). To put it correctly: since the table before-border wins over header before-border, it becomes the competing border for the before-borders of the cells in the first row of the header. If all the cells in the header's first row have the same before-border, the table's before-border then becomes the before-border for all of them. Sorry for my being unclear. The question was stated in terms of the phase I'm currently working on: resolving the border-conflicts between the table and its header/footer/bodies, and those between the header/first body, body/body, last body/footer. The deeper table elements will be something for next week. snip / (so in this simplified case the after-border on one page will *always* be the same as the before-border on the next)? No, I don't think so. I believe the collapsing only happens between two effectively adjacent cells, i.e., translated to one of our stages, more located in the area tree stage than in the FO tree stage, if you know what I mean. But I'm not sure here, because I think the spec is really not that clear in this little detail. But I'd also think it would be strange if the border after from the previous page would bleed over to the next page in this way. OK, that means resolving after/before border conflicts between two bodies would need to be deferred to layout. Thanks for the useful comments. BTW: since it is my intention to facilitate the job of the layout package in this matter, I'm considering adding BorderInfo instances (although I'm not sure where exactly) that keep the resolved info to use precisely in these layout-specific cases. What I mean is: even if the FOTree lacks some of the context, there is always the fact that it is a possibility (however remote) to have a page-break between two body elements. We could say: the BorderInfo to use in 95% of the cases is the one that is immediately available in the element's CommonBorderPaddingBackground instance, in the other 5% it's another one, available 'over there' (wherever that is). Layout would then not need to re-evaluate, but pick up the width from that 'special' BorderInfo instance. Does this sound like a sane thing? Cheers, Andreas
Re: Collapsing borders: FOTree stage -- progress update
On 27.08.2005 23:19:40 Andreas L Delmelle wrote: snip/ BTW: since it is my intention to facilitate the job of the layout package in this matter, I'm considering adding BorderInfo instances (although I'm not sure where exactly) that keep the resolved info to use precisely in these layout-specific cases. What I mean is: even if the FOTree lacks some of the context, there is always the fact that it is a possibility (however remote) to have a page-break between two body elements. We could say: the BorderInfo to use in 95% of the cases is the one that is immediately available in the element's CommonBorderPaddingBackground instance, in the other 5% it's another one, available 'over there' (wherever that is). Layout would then not need to re-evaluate, but pick up the width from that 'special' BorderInfo instance. Does this sound like a sane thing? Remembering your earlier ideas for your approach, I think so, although I must say that I'm not sure if I really understand it. I keep having problems following your ideas sometimes, but that's mostly because I'm not so much the theoretical guy. AFAIK you're trying to move the pre-resolvable pieces into the FO tree while you only do the specialities in the LMs, right? Jeremias Maerki
Re: Collapsing borders: FOTree stage -- progress update
On Sat, 27 Aug 2005 02:07 am, Andreas L Delmelle wrote: Hi all, snip/ * The first step I took was moving much of the logic that is currently in CollapsingBorderModelEyeCatching (in the layout package) to CommonBorderPaddingBackground. I must admit I know very little about collapsing borders. Therefore if my comment is useless just ignore it. I have recently worked on all this percentage stuff. This applies also to border-width specifications. I believe border-width is one of the inputs to the border collapse algorithm. Relative border-width specifications can only be resolved at layout time (with the appropriate context). This seems to indicate the border collapse algorithm (at least the parts related to border-width) can only run during layout. snip/ Cheers, Andreas Manuel
