Re: wishes for lout

[P.J. Kersten]

Valeriy E. Ushakov wrote:
> 
> On Thu, Jan 15, 1998 at 05:43:33PM +0100, P.J. Kersten wrote:
> 
> > > Repeating headers are tough in general as object has no way to notice
> > > it was split into components.
> >
> > I am aware of that. That's why it's a wish. More to the point: the
> > algorithm which splits the objects _has_ notice. This is the point where
> > such a change could be adopted.
> 
> I hastened to send my reply away.  Now that I'm looking at the page 30
> of expert's guide I have to admit I was wrong.  If the galley (that is
> a symbol with `into' clause) contains an inner definition of a symbol
> named address@hidden' every @Galley symbol in the target that receives a
> component of the galley will be replaced with @Enclose @Galley.
> I.e. supplied @Enclose will have a chance to act upon each of the
> components the galley was split into.  And this is hygienic in the
> sense that @Enclose obeys usual scoping rules etc.
> 
> I'm not shure if it will help us with repeating headers because Lout
> has to resolve alignement and size constraints, but it well might
> help.  In general, use of galleys will probably help in that way or
> another.  Galleys and xrefs are *very* powerful.  Take a look at
> standard Lout packages for advanced examples.  It's somewhat hard to
> read for the first time, but it's a really good code.
> 

I too was a bit hasty. I saw @Enclose a while back, played a bit with
it, but couldn't get it to work the way I want it. My lout knowledge is
probably not sufficient enough. Although I played with lout for some
time, I still can't grasp the model in full detail. I want to, but I
don't have the *time* to do so.
But besides that, the galleys are defined *inside* the packages. If you
want to change something, you have to dive into the packages and rewrite
or add parts *within*. That is not a task for an ordinary user
(developer or not).

> >             Implementing a table as a special(=internal) object, one can
> > express it in (opt header, footer,) columns and rows. Lout can then
> > calculate and serve straddle-requests based on rows and columns instead
> > of being stuck with a almost non-related sequence of random objects
> > which can only be split and aligned.
> 
> It might look seductive, but it's a recipe for disaster.  Lout has
> warts and limitations, but the underlying objs/defs/galleys/xrefs
> model is very consistent.
> 
> Let's take a different look (of some hypothetical WYSIWYG DTP).  Let's
> start with a single cell and dissect it one cut at a time from one
> side to the opposite, effectively introducing new row or column.  If
> one wants (and one usually is) "traditional" rows or columns one has
> additional constraint that cuts must be aligned.  With this procedure
> one can construct any table with arbitrary spanning rows and columns,
> can he?
> 
> One can *not* create structures like the following one, but I think
> these are quite rare in practical applications, I even would not call
> it a table.
> 
>         +------------+-----+
>         |            |     |
>         |            |     |
>         +-----+------+     |
>         |     |      |     |
>         |     |      |     |
>         |     |------+-----+
>         |     |            |
>         |     |            |
>         +-----+------------+
> 

I don't agree. Using MifMaker I can say
        <Table> ...
           <TableColumns> n=3 ...
           <TableHeader>
                ...
           <TableBody>
             <Row> ...
               <Cell> cs=2
cell 1
               <Cell> rs=2
cell 2
             <Row>
               <Cell> rs=2
cell 3
               <Cell>
cell 4
             <Row>
               <Cell> cs=2
cell 5
          <TableFooter>
                ...
        </Table>

to produce this table. Having done this, FrameMaker is capable of
splitting the table even in the middle of a row, givven that at least
one cell contains more than one line. It thereby reprints the
tableheader and (if defined) a continuation message. Continuation of the
table is governed by the definition of the current text-flow. The second
part (or n-th part) can therefore be placed in the next column or
several pages later.

> Now reverse this process of cutting a single rectangular object and
> you will see familiar Lout concatenation that glues small cells into
> larger.  Lout can take care of alignment pretty well and perhaps some
> little PostScript magic will do borders.
> 

I agree, but the @Tab package can't handle it. Givven the (for me)
not-so-easy-to-grasp objectmodel, it would be great if it could. This
would steepen the production curve. Right now one has to invest too much
time to become 'an expert user' to do it 'the lout way', and judging
from your replies I expect that even 'expert users' see this as a
non-trivial task (I am not an expert user).

Putting it all together it would be nice if
- someone could change the @Tab package to a more capable tool able of
signaled splitting of rows, arbitrary spanning rows and columns,
repeating headers and cell backgrounds.
- If the above is not possible: lout was changed in a 'hygienic' way to
*make* it possible.

BTW, I studied the @PageBackground feature, but this is not what I want.
I want to implement multi-page forms, preferably without rebuilding the
lout-packages. Any suggestions?
Related to that: is it possible to produce overstikeable objects?

Thanks,
-- 
Pieter J. Kersten
Erasmus Universiteit Rotterdam
dir. I&A/I&S, WH2-10
Postbus 1738
3000 DR  Rotterdam
Nederland
Tel +31-10-4082599
Fax +31-10-4527236