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
