You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by ja...@petrobras.com.br on 2003/06/30 14:32:30 UTC
Corner drawing (Was: Spurious space between table-header and table header.)
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: <fo...@xml.apache.org>
<a_l.delmelle@pan 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:a_l.delmelle@pandora.be]
Sent: zaterdag 28 juni 2003 0:30
To: fop-user@xml.apache.org
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: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org
Re: Corner drawing (Was: Spurious space between table-header and table header.)
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 30.06.2003 14:32:30 jaccoud wrote:
> BTW: Jeremias, are the borders realy suposed to look like
> +----------------------------------
> |
> |
> +---+------------------------------
> | |
> | |
> | |
>
> ?
>
> Shouldn't it be like this:
>
> +----------------------------------
> |\
> | \
> | \
> | +------------------------------
> | |
> | |
> | |
>
> ?
I don't know. There are people around more knowledgable about the XSL-FO
specs who can probably answer that.
> The latter is used by CSS, and I could not find this specific topic in the
> FO spec.
Neither could I. But XSL-FO often refers to CSS. So maybe you're right.
> Is this a PDF limitation? I becomes important for thick borders of
> different colors, when trying to simulate a 3d-effect. ( or 3-deffect :-)
Not a PDF limitation. More an implementation detail. Something that
eventually needs to be fixed, maybe.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org
RE: Spurious space between table-header and table header
Posted by Andreas Delmelle <a_...@pandora.be>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
well, you're certainly a stubborn one (if you don't mind me saying
so... :-))
perhaps not meant in that way, but the phrase 'PDF specs do not
matter here'
seems to me to be a bit too ... strong? anyway, it's not because some
construct can be rendered in PDF that it will necessarily follow the
behavior
the FO spec prescribes in that case. PDF has its own rules, and I
would
be the last person in the world to claim that I know them all by
heart
( 978 pages is a bit discouraging for linear reading... )
Fact of the matter is you're always dealing with two specs here and I
personally believe that adhering too much to one of the two in this
case is asking for 'trouble' ( in the sense that your result might
just
not be the one you expected )
I hope you don't mind ( too much ) that I thought your borders were
kind of
clumsily defined in the .fo. Either specify the border-width
explicitly for both header &
body, or define it once, for the whole table. But why would you
define the
border-width for the header and rely upon the renderer to guess what
[d]effect
you're trying to achieve?
The gap is NOT a miscalculation of the header height, but I must
admit it
might be a bug ( although it makes perfect sense to me that certain
border settings
specified in the header instead of in the table itself, affect the
border of the table-body
since both header & body are situated at the same level within the
table;
see my clumsy example - if you remove the top-border from the header,
the gap
disappears. Put a bottom-border in the header and the 'gap' will
reappear at the
bottom of the table - which becomes visible if you define the outer
left & right
borders as attributes of the table itself. I, myself, know too little
about the FO-spec
to judge whether it is 'correct' that the top-border of table &
table-header are
one and the same. Same goes for the table & table-body's
bottom-border, but
from the experience I gathered nosing around in the relevant specs &
the fop
source, I'm thinking that it's a result of the way the abstract
rectangles
are calculated...
Hmmm, seems like the offset of the top of the content area rectangle
of the
body is defined as the height of the row measured from ... the inside
of your
1.25mm border, leaving room for another possible 1.25 ( was it
supposed to be
zero? where did it say so? )
The 'gap' is actually a part of the table border, created
unintentionally by
putting the width specification at a perfectly valid, though
confusing place...
As I said, it might be considered a bug, but if and only if it is
definitely
NOT FO-compliant that the width of the border is propagated whilst
the style is not.
see attached FO/PDF combo for a perfectly valid solution that will
give you
the intended results without the use of any XSLT
[Another question that springs to mind is how, for instance the AWT
or
PS Renderers deal with this ... same thing. So not PDF-related after
all...
sorry, my mistake... :-( ]
greetz,
ald
> -----Original Message-----
> From: jaccoud@petrobras.com.br [mailto:jaccoud@petrobras.com.br]
> Sent: maandag 30 juni 2003 14:33
> To: fop-user@xml.apache.org
> Subject: Corner drawing (Was: Spurious space between table-header
> and table header.)
>
>
>
> 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:
> <fo...@xml.apache.org>
> <a_l.delmelle@pan 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:a_l.delmelle@pandora.be]
> Sent: zaterdag 28 juni 2003 0:30
> To: fop-user@xml.apache.org
> 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: fop-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: fop-user-help@xml.apache.org
>
>
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPwG43NBw/OvTa+XUEQJ8GwCff/Krlm818jhw/8tHzh3rYue+y/wAoKpx
knUBjZpXlcNvUbhrfZTfAFV2
=TOAn
-----END PGP SIGNATURE-----