>FEATURE REQUEST FOP: It would be nice if there is an alternative to the >'border-collapse="separate" considering the linewidth of >overlapping borders. Think of an "border-collapse='xxx'" where the >xxx garantuees that when borders of table cells are overlapping, >only a single line is drawn.
Dunno for sure if this would be a feature to add to FOP. Seems more like sth that would need to be foreseen in the FO-spec, if it isn't already (? sure going to look it up if I find some time ) Anyway, I remember a thread on this list ( 'bout 2 months ago, link below ) that started with someone pointing out a mysterious gap turning up in his target pdf ( some nitwit persisted that this had sth to do with the pdf-spec :) ). The whole discussion got me thinking about the remark by Jeremias Maerki that 'Borders are non-trivial'. Somehow this made more sense to me if one keeps in mind that the FO is parsed through SAX, which means sequential reading of the tags and their corresponding atts, which would mean that borders set as attributes for a given table are processed first ( so, actually the total width of the table at that time would not take into account the header/footer- or cell-borders ) and the deeper elements ( header/footer, cell ) are calculated later on, which might explain the slight displacement of the outer table-borders. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]& msgNo=7627 One valid workaround for me, seemed to be to define 9 template-<fo:table-cell>s ( 9 possible cell-positions / border-combinations ) in a separate xslt and then calling these templates from within the base-fo:xslt. Perhaps such a construct could help you out here ( & on numerous future occasions ) Cheerz, ald --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
