various problems

[Jeff Kingston]

Jeff's reply to the combined comments of Valeriy E. Ushakov and P.J. Kersten
============================================================================

There seems to be an air of crisis in the mail which has prompted this
reply.  I don't think there is a crisis.  A lot of good work has gone
into Lout, and many worse problems have been corrected over the years
than these ones.  I'd love to think that Lout is the universal solution
to everyone's problems, but the reality is that it is untyped, it is a
batch system, it requires every galley to have a constant, fixed width,
it does not really understand non-rectangluar shapes, and its idea of
optimal document layout is basically limited to paragraphs only.  These
are much more serious problems than the ones discussed below.


Difficulty in understanding expert's guide
------------------------------------------

It would certainly benefit from a rewrite, but my time is taken up
completely by maintaining the Lout implementation.  Any volunteers?
Also, in fairness the difficulty of understanding Lout galleys
should be compared with the difficulty of understanding troff
diversions and traps, and TeX floating insertions and output
routines (or whatever they're called).  A great deal of useful
code can be written without using galleys and cross references.


Organization of standard packages
---------------------------------

The essential point seems to be that the standard packages contain a lot
of locked-away expertise which requires a great deal of expert knowledge
to understand and modify.  I could respond that TeX is far worse!  But
I'd love to hear some suggestions in this area, or pointers to systems
that are much easier to configure than Lout is.  I feel myself that some
kind of even more modular design would be good, but I don't know what.

The specific example of displays in a box could be handled by adding a
setup file parameter similar to @TitleFormat (is it?), so that one could
write

    @DisplayFormat { @Box @Body }

in the setup file.  I think Lout would be improved by dramatically
increasing the number of setup file options of this kind.  Right now it
is easy to define a @BoxedDisplay macro.


Problems with @Tab
------------------

@Tab undoubtedly has serious problems; it is the oldest and the least
revised of the standard packages.  I have previously indicated an
intention of revising it (or more probably replacing it, as @Diag
replaced @Fig).  There are three main problems:  I am short of time;
the current Lout implementation has problems with the semantics of
spanning columns and rows, which manifest themselves in the need for
the @FirstRowa etc. workaround and in failure to set some complex
tables (even though legal in @Tab) correctly; and the current Lout
interpreter has no means of expressing the spiral example

    +------------------------------------+-----------------+
    |                                    |                 |
    |             Cell 1                 |                 |
    |                                    |                 |
    +----------------+-------------------+     Cell 2      |
    |                |                   |                 |
    |                |      Cell 4       |                 |
    |                |                   |                 |
    |    Cell 3      +-------------------+-----------------+
    |                |                                     |
    |                |                Cell 5               |
    |                |                                     |
    +----------------+-------------------------------------+

in any case.  The whole "table model" needs revising.  This is not
going to happen soon.  I am not sure what "splitting of rows" means,
but cell backgrounds would be easy to add to a new package, vertical
spanning is no harder for Lout than horizontal spanning (it just
never made it into @Tab), and repeating headers (if this means running
headers) are in principle possible now by combining @Enclose with the
technique used recently to implement inline figures.


Multi-page forms
----------------

These can be done by means of definitions with a long list of named
parameters.  I have used this technique, for example, for printing
timetables using the syntax

    @TimeTable
        @MonNine { }
        @MonTen  { CS101 lecture }
        ...
        @FriFour { }

A batch of these can be made by multiple invokations of the @TimeTable
symbol separated by @NP.  I do not think the difference between "static"
(fixed size) and "dynamic" (varying size) fields is of any great importance
to Lout; @Diag, for example, offers this choice for the nodes it draws.

Form design is an inherently interactive process, like laying out diagrams.
It's naive to think that you can just say "put this under this, put this
next to this" etc., and come up with an ergonomic form.  So this is one
area where Lout will never be competitive with well designed interactive
editors.

Lout could benefit from a means of defining a sequence of things, so that
one could define a sequence of list items, or a sequence of form entries,
and have the syntax enforce things in a way that

    @NumberedList
    @LI {}
    @LI {}
    ...
    @LI {}
    @EndList

does not.  But that raises a whole new area, strong typing, which would be
great but is too late to address in Lout now.

The actual form, with its borders, background colours, etc., can be defined
using @Diag, although there is scope here for a package that includes
definitions for the kinds of things that typically appear in forms, such as
tick boxes etc.  This package would be quite easy to write on top of @Diag.

Jeff Kingston