Hmm. PDF specs do not matter here. If some FO construct can't be rendered in PDF, it should be marked as so. I don't think this is the case with table borders. It is just complicated per se. The gap seems to be a miscalculation of the header height, because it is excatly the same width as the top-border. As to defining only cell borders, it is of course feasable, but you have to write separate templates for each cell -- I just took the easier way to avoid needlessly complicating the XSLT. Knowing what is going on, and what to avoid, there are multiple ways to get around the bug. As to the misalignment, it is a side-effect of the boerder-collapse. I tried "separate", as Jeremias sugested, and things got clearer.
BTW: Jeremias, are the borders realy suposed to look like +---------------------------------- | | +---+------------------------------ | | | | | | ? Shouldn't it be like this: +---------------------------------- |\ | \ | \ | +------------------------------ | | | | | | ? The latter is used by CSS, and I could not find this specific topic in the FO spec. Is this a PDF limitation? I becomes important for thick borders of different colors, when trying to simulate a 3d-effect. ( or 3-deffect :-) ============================================= Marcelo Jaccoud Amaral mailto:jaccoud [at] petrobras.com.br voice: +55 21 2534-3485 fax: +55 21 2534-1809 ============================================= There are only 10 kinds of people in the world: those who understand binary and those who don't. "Andreas Delmelle" Para: <[EMAIL PROTECTED]> <[EMAIL PROTECTED] cc: (cco: Marcelo Jaccoud Amaral/RJ/Petrobras) dora.be> Assunto: FW: FW: Spurious space between table-header and table header. 2003-06-28 09:04 Favor responder a fop-user - - - -----Original Message----- From: Andreas Delmelle [mailto:[EMAIL PROTECTED] Sent: zaterdag 28 juni 2003 0:30 To: [EMAIL PROTECTED] Subject: RE: FW: Spurious space between table-header and table header. hey waddya know... tried this : removed the border defs from the header & voila no gap and no misalignment. downside is u have to define the top & bottom borders for all cells in the row as a workaround ( 'till the row borders are implemented ) [added] anyway, i would definitely use the table-header as an element containing no border atts & leave these either in the table itself ( for outer borders) or the individual cells (in the absence of an implementation for the row borders... and come to think of it : what about column borders? - let's try ;-) ) just try to avoid, as much as possible, any borders that are defined multiple times. defining both left & right in the table (or the header) as well as in the cells seems to 'push' the extent of the left & right borders of the outer borders a little ( exactly half of the width of the inner border if i'm correct; vaguely remember reading sth about this in the pdf-filespec ). the content area rectangles for table, body and header match in width. defining border-top-* atts in table affects only the header. defined in table-header border-top-width also affects width of table-body, border-style of table-body is not explicitly set though... the content area rectangles of the cells are on the 'inside' - but what's the inside of a border of zero width? - of the table (either in the header or the body) which would explain the mysterious gap & the misalignment in this way : border-top-width from table or table-header is 'inherited' by table-body, border-top-style however, is not. => gap = border-top-width without -style :-) border-left-width from table-cell pushes the outer left border slightly, creating the misalignment that 'only' appears in the upper row (actually it happens in the second as well, which gets enlightened by adding some colour. if i am not mistaken, the same process takes place between the individual cells - - - try leaving some out, see what it does) and why don't we see the same misalignment at the bottom? because there are no explicit border-style-* atts defined for table-body, so the same is happening over there... i sincerely believe this is not a bug. it's sth pdf-related ( the way a pdf-reader is supposed to render the areas and their borders ). at best the fop-renderer could be configured to make border-left-* atts for tables override those that are set for cells in the first column of that table (border-right-* for last column, border-bottom for last row, border-top for first row), actually deleting the latter from the stream before it is piped through to fop ( which would mean compensating for the users' unwillingness to learn xsl:fo or pdf, which in its turn seems to be completely missing the point somehow - - what was that name again? ...?? ;-) ) a very intriguing brain-teaser though... my suggested solution? -> see attachment (watch diffs between borders to get an idea - tellin' u it's a drawing thing, man!) see the bottom? there's that gap again. how... clumsy of me ;-) respect ald --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
