On Mon, Sep 22, 2003 at 09:30:02AM -0400, Kuba Ober wrote:
> Obviously it's not. About the only seriously good thing about TeX, actually a
> thing that has been kept broken for ages by designers of onscreen and printed
> renderings in Windows and typical X-based systems, is that dimensions are
> like God liked them to be, namely absolute.
Indeed.
> > There are 'bracketless LISP dialects', but that's not the point. Any
> > method cleanly separating 'commands' from 'data' probably will be
> > doing fine.
>
> The only problem is that some sugar is needed, because for many typesetting
> uses most commands work on data that's very close to them.
It should not add lots of extra typing for the standard case 'almost
everything is data'.
But something similar to
\document{class=article,...}{
\section{Preface}
\math{a+b+\sin{c}+\frac{1+x}{y}}
And escaping only \openbrace{}, \backslash{} etc. should
\itemize{
\item{be parsable by a computer}
\item{writable by anyone who's seen \LaTeX{} before}
}
}
> But in general I
> see a big need for something that would offer all of TeX's functionality, a
> decent introspection (including recursive introspection) and decent syntax. I
> guess that variable catcodes are of no big use in real life (tm).
Except as a way to show off or to provide contrieved counterexamples, no...
> > The problem here is that you can't 'undo' paragraph breaking. Why? I
> > don't know. There is no theoretical technical limitation except that
> > TeX simply can't handle it.
>
> That's one side of it. Another side is the fact that box dimensions
> have to be known apriori in most cases.
That's true for width, but not necessarily for height if there's this
two-phase process 'line breaking followed by pagebreaking'... The
example would work perfectly well with such a two-phase process...
> And this doesn't even have too much to do about paragraph rebreaking.
> In a typical case of paragraph spanning two pages with differing
> column widths, you'd need to make up the box the paragraph has to fit
> in with the bottom part of it having the width of column on the next
> page, and the top part having the width of the current page's column.
> But even that is not so trivial, since you need to do that just after
> the previous paragraph has been committed to the output, and the next
> one is about to be typeset...
What's wrong with breaking the whole thing with width 10cm, shipout the
first part and put everything left back on the to-do list? Right: It's
already partially 'digested'. But nowadays there's no reason not to work
only on a single paragraphs' worth of data, we could scan the entire
document seeral times - or at least pretend we do. Every compiler does.
this when running the preprocessor...
Andre'
