-----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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: maandag 30 juni 2003 14:33 > To: [EMAIL PROTECTED] > 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: > <[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] > > -----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-----
header-body-alt2.pdf
Description: Adobe PDF document
header-body-alt.fo
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
