Re: wishes for lout

[Valeriy E. Ushakov]

On Fri, Jan 16, 1998 at 10:32:02AM +0100, P.J. Kersten wrote:

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

Hmm, but one is supposed to learn the language/system one's going to
use, isn't he?  It's true that Lout looks unusual after *roff or TeX
just like Lisp or ML looks unusual after C or Perl.  But if you choose
Lout as a tool for your project you implicitly agree to master the
system (if you haven't already).  If you discover that the tool you've
chosen is inappropriate (for example because it's hard to master
quickly), choose a different one.  You make decisions.

If you need a solution that you have to implement quickly and you
can't do it with Lout because you need some time to master advanced
Lout features - it's neither your fault, nor Lout's.


> But besides that,

You miss some important things:

> galleys are defined *inside* the packages

Strictly speaking, there are *NO* packages in Lout.  @DocumentLayout is
a symbol just like any other.  Yes it happens to export all the fancy
stuff like pages, list, displays and in your document setup you import
this stuff with @Use, it doesn't make it any different from any other
symbol.

Galleys are just symbols as well.  Nothing prevents you from defining
galleys (symbols with `into' clause) and targets (symbols with @Galley
inside) if you need them.  Check my solution to "classified pages"
<URL:http://www.ptc.spbu.ru/mail-archives/lout/0138.html> that is
based on galleys and xrefs (and even abuse page footers to place some
receptive symbols at the appropriate place on the page; hack, hack :).
The code in the message is nothing but mydefs.lt file verbatim.


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

If you want to add parts "within" you use `extend' clause.  All
standard document types are written in this way!  E.g.

    extend @DocumentLayout
    export @Report @Abstract @Section @Appendix
    def @ReportLayout
      ....

Changing something in `dl' is not straightforward, but I think it's ok
for developer to make a copy of `dl' and modify it according to his
needs. `dl' does a good job for standard document types, but it's not
meant to be the universal solution.  Check `tl' (toy layout), it's 104
lines total including big blurb at the top and the basic page layout
occupies only two screens!

> I don't agree. Using MifMaker I can say

Can you please fill my tempalte with cell content, so that I can be
shure I understand what is meant by that code?  You can probably send
it to me directly, not to the list.


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

Yes, @Tab is not perfect.  Typesetting tables is hard in general.  I
never really studied this area, but I read here and there words like
"CALS table model" (DocBook), "HTML table model", that table model,
this table model.  The words "table model" makes me think that people
has different ideas on how table structure is to be described.


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

Agreed, a better @Tab is desirable.  But again, it's for human users,
so it has to have nice friendly syntax.  If you want to produce tables
automatically, your best bet is to write specialized tables package
and use it as a target it in your application.


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

Sorry.  What do you mean by multi-page forms?


> Related to that: is it possible to produce overstikeable objects?

The basic answer is 0io gaps.  Take a look at @OverStrike in the `dl'
for a higher level solution.


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