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
DelmellePara: [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
