lout-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wishes for lout


From: Valeriy E. Ushakov
Subject: Re: wishes for lout
Date: Fri, 16 Jan 1998 00:27:48 +0300

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.


>             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.

        +------------+-----+
        |            |     |
        |            |     |
        +-----+------+     |
        |     |      |     |
        |     |      |     |
        |     |------+-----+
        |     |            |
        |     |            |
        +-----+------------+     


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.



SY, Uwe
-- 
address@hidden                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen


reply via email to

[Prev in Thread] Current Thread [Next in Thread]