W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2003

Re: Fwd: Spanned cells pending beyond the row group

From: G. Ken Holman <gkholman@CraneSoftwrights.com>
Date: Wed, 22 Jan 2003 07:13:12 -0500
Message-Id: <5.2.0.9.0.20030122065031.00ba81e0@pop.storm.ca>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:53 GMT