RE: table rows in a galley

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

Thank you all for your help. I have a table built now out of primitives
(I grabbed the code for drawing rules from tblf) where you can say
something like

@MyTbl {
                  @Row named1 { foo } named2 { foo }
      /rowpadding @Row named1 { bar } named2 { baz }
}

and you get the header row and a bunch of defaults that I set, for free.
 
This whole @MyTbl is passed as a named parameter to my report layout
function, which places it in a @Tbl cell that takes up about half the
page, so none of this is happening with galleys. It all looks perfect -
until you put too many rows in it. Then it blows up horribly.

The report presently has four panes: a header row, a diagram and a table
side-by-side, and comments on the bottom. I think I need to make those
out of primitives with galley targets instead of @Tbl cells, scrap
@MyTbl, and send a @Tbl into one of them; then it can wrap to its
heart's content. 

But I still won't get to specify half of the parameters and body of that
@Tbl in my include file, and only the data in the document. Some of what
@Tbl deems content, I deem structure in the context of this report
(i.e., the fact that there's a @Tbl right there, it has this many
columns, it has a row at the top with these titles in bold, and some
rules are drawn), and I'm trying to separate my idea of structure from
my idea of content very strictly, so that the document itself contains
only the data that goes into the report, and the look and arrangement of
that data is entirely up to Lout. Like CSS, but with galleys and
coolness.

 
> -----Original Message-----
> From: address@hidden [mailto:lout-users-
> address@hidden On Behalf Of Jeff Kingston
> Sent: Tuesday, October 07, 2008 5:55 PM
> To: address@hidden
> Subject: Re: table rows in a galley
> 
> > But when I make a galley inside the table, things I send to
> > the galley don't have access to the scope of the table: for
> > example, @Rowa is undefined or misspelt.
> 
> Even worse (if I understand what you are trying to do correctly),
> every galley has a single column mark, and so you can't pass a
> table row, which has several column marks, through a galley;
> or rather, you can, but what comes out the other end has a
> single column mark and will be treated as a single column.
> Uwe already pointed this out, and he also wrote:
> 
> > I have a vague feeling that you are not splitting responsibilities
> > between the generating program and lout quite right and that makes
> > you write lout code that is more complex than necessary.
> 
> I agree with his comment.  If you are generating the Lout source with
> a program then you probably don't need a layer of your own definitions
> at all; just go ahead and generate the tables you need.
> 
> Definitions with parameters are much easier to work with than galleys,
> and they are often the best way to separate format from content.  Make
> a definition with one parameter for each distinct element of content,
> and a body containing all the layout.  When the content is an
arbitrary
> number of table rows and columns, you have to do something to indicate
> within the content where the column and row breaks are.  Here is an
> example using / and | (see the Expert's Guide) rather than @Tbl:
> 
>     def @Seasons
>       right body
>     {
>         Winter | Spring | Summer | Autumn
>         /
>         body
>     }
> 
> and then you can write
> 
>     @Seasons
>     {
>         Skiing | Floods | Droughts | More droughts
>       /
>       Cold | Wet | Hot | Less hot
>     }
> 
> which would make a table with four columns and three rows.  The
> value of "body" can have any number of column and row marks, and
> these will be merged correctly with column and row marks at the
> point where "body" is used inside the definition of @Seasons.
> Using Lout primitives avoids the scoping problems with @Tbl.
> 
> Jeff