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



Reply via email to