On 23.04.2006 21:21:06 Pierre-Henri Kraus wrote: <snip/> > Sorry, when I said "hacked", I thought about making sure that none of > your elements spans on two pages, I gotta admit that idea was somewhat > stupid :D
Ah, I understand now. It's probably a bit unrealistic to restrict people to elements not spanning pages. > About the collapsing border model, it sounds interesting, but so far the > only specification I found of it is the one of the CSS, is it the same ? > ( http://www.w3.org/TR/REC-CSS2/tables.html#propdef-border-collapse ) XSL-FO's collapsed border model is based on the CSS model, yes, but the FO specification has some additional info found in the text for the table formatting objects. > And what do you mean by the "reduced version" ? In the collapsed border model, neighbouring table cells interact with each other since their border specifications are merged. That alone isn't so problematic, but when table-header and table-footer elements come into play the combined border can be different depending on whether a table-cell is the first (or last) on a page and gets a different resolved border when it's adjacent to a table-header/footer cell than when it's adjacent to its normal neighbouring cell. In my analysis last year, it turned out that this can complicate Knuth element production quite a bit. The problem is that in the Knuth element model, you have to map every (!) possible break condition. You have to calculate for every break condition what the result looks like if no break happens and if a break does happen. I almost freaked out while trying to sort it out. With the reduced version I mean that you eliminate the border interaction between header/footer cells and body cells. This will still satisfy most use cases but reduces the complexity quite a bit. Please go through the extensive Wiki content on table layout which you find on http://wiki.apache.org/xmlgraphics-fop/DeveloperPages. I've written down practically everything I found out last year. Jeremias Maerki
