- From: G. Ken Holman <gkholman@CraneSoftwrights.com>
- Date: Wed, 22 Jan 2003 07:13:12 -0500
- To: XSL Editors <xsl-editors@w3.org>
- Cc: Paul Grosso <pgrosso@arbortext.com>
At 2003-01-21 14:48 -0600, Paul Grosso wrote: >Do I have your permission to forward a copy of Nikolai's email >to the public xsl-editors comments list so that we have a public >record of this issue? Paul (and others on the XSL Editors list), You have my blanket permission to quote any of my messages on XSL Editors if you think it will help forward discussions. Waiting for me to reference any particular issue may delay your work. CC'ing me will help me know that it has been done, but you don't have to wait if you think it will help. >[Alternatively, feel free to send something yourself to xsl-editors >about this.] In a very large UBL-related stylesheet laying out a paper form on a 33x17 grid, I spanned rows without heed of table-body boundaries. I assumed that multiple table bodies were merely "syntactic" methods of using different row-grouping strategies at different stages of table body building, but that regardless of which method to *specify* the cell contents, the spanned rows from cells in higher rows worked in the table as a whole, not limited to the table body in which the spanning was done. In my example, the left-most column spanned all 33 rows because it had some marginalia rotated at 90 degrees, and the top-most row spanned the remainder of the 32 columns because it had title information. This left 16 columns by 32 rows to lay out the fields of the form. I needed different row-groups because of the logistics of the source data, so I wrote three table-body constructs, one for the top 12 rows, another for the middle 8 rows, and the third for the bottom 12 rows. My intuition was that table-body constructs where merely mechanisms for expressing the contents of cells, the choice available based on the algorithms of the stylesheets, but that the table-body boundaries were "invisible" to the user, and essentially "invisible" to me the stylesheet writer. My 33-row span of my marginalia was specified in the first table-body and the other table-bodies respected that because the first table-body had sufficiently accommodated the first column of each of the rows. My stylesheet was certainly a lot easier doing it the first way ... to find common behaviour between the two implementations I had to nest a table in a table, where the outside table has the marginalia and the title, and the inside table is the 32x16 grid that I need for the form. I can see any of Nikolai's three interpretations as being acceptable, though it was more work and less intuitive to me to have to accommodate table-body borders at all. Nikolai's post cited by Paul continues below. Good luck with this one! .......................... Ken >paul > > >From: "Nikolai Grigoriev" <grig@renderx.com> > >To: <w3c-xsl-fo-sg@w3.org> > >Date: Tue, 21 Jan 2003 01:32:05 +0300 > >Subject: Spanned cells pending beyond the row group > >X-Archived-At: http://www.w3.org/mid/01a301c2c0d3$c84dce90$7f01000a@grig > > > >Hello, > > > >in a private mail, Ken Holman signalled one more FO-related issue. > > > >Situation: a fo:table-cell with @number-rows-spanned > >extends below the last fo:table-row element in a row group, > >like in the example below: > > > > <fo:table-body id="body1"> > > <fo:table-row height="2in"> > > <fo:table-cell><fo:block>A1</fo:block></fo:table-cell> > > <fo:table-cell number-rows-spanned="2"> > > <fo:block>A2</fo:block> > > </fo:table-cell> > > </fo:table-row> > > </fo:table-body> > > > > <fo:table-body id="body2"> > > <fo:table-row height="2in"> > > <fo:table-cell><fo:block>B1</fo:block></fo:table-cell> > > </fo:table-row> > > </fo:table-body> > > </fo:table> > > > >How should a formatter behave? Ken Holman could not find > >an answer in the spec, and neither could I. Alternatives > >known to me (and implementations using them): > > > >1. Let cells leak into the next row-group (Antenna House); > > > >2. Pad the row group with empty fo:table-rows (RenderX); > > > >3. Reduce @number-rows-spanned at the offending cells > >so that the cell fits completely into the existing rows. > >This is inspired by the following quote in CSS2 > >[17.5 Visual layout of table contents]: > > > >CSS> 6. A cell box cannot extend beyond the last > >CSS> row box of a table or row-group; the user agents > >CSS> must shorten it until it fits. > > > >Personally, I an inclined to prefer the third, CSS2-style option: > >in this case, we have a better alignment with HTML table model. > >IE6 and Opera 7 use this method (though Opera 6 does not). > > > >Whichever option we choose, it looks reasonable to put a notice > >to [6.7.10. fo:table-cell] or [7.26.14. "number-rows-spanned"] > >(or both). > > > >Best regards, > >Nikolai Grigoriev > >RenderX -- Upcoming hands-on in-depth Europe: February 17-21, 2003 XSLT/XPath and/or XSL-FO North America: June 16-20, 2003 G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) ISBN 0-13-065196-6 Definitive XSLT and XPath ISBN 0-13-140374-5 Definitive XSL-FO ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath ISBN 1-894049-10-1 Practical Formatting Using XSL-FO Male Breast Cancer Awareness http://www.CraneSoftwrights.com/f/bc
Received on Wednesday, 22 January 2003 13:11:52 UTC