RE: a DSSSL typesetter

["Frank A. Christoph" <christo@xxxxxxxxxxxxxxxxxx>]

>   Actually, I'm not so convinced that TeX and PostScript are that far
>apart.  It's true that TeX knows far more (as PostScript, by it's
>essential nature, knows basically nothing) about typesetting, but
>that's simply because it was programmed with that knowledge.  The
>question is really whether PostScript has the guts to elegantly and
>efficiently handle the processing tasks needed to implement the
>typesetting process.  I've looked a bit at TeX's general strategy for
>typesetting (the "box and glue" idea), and I can't see implementing
>something like that in PostScript as being that difficult.  Of course,
>there's got to be more to it than that, but...


By the usual Turing completeness argument, it's not hard to see that
anything you can do in TeX, you can do in PostScript.  The real issue is,
_where_ you do it: on the computer, or at the printer?  As anyone who was
had experience producing PostScript code before knows, the trick is to do as
much computation as possible on the host machine, and then send the
smallest, least computationally-intensive result possible to the PS file or
printer.  (Rather like partial evaluation in a functional language---the PS
file is the residual program.)  The reason is not only that PS interpreters
are slow and low on memory, but also the fact that you can obtain greater
guarantees about the resulting document if you do as much computation as
possible as early as possible.  For example, TeX tells you when you have
dangling references (to labels), it tells you when it can't find an external
input file, it tells you when there is an error in the macros, it tells you
when a line is overfull, etc.  So you can take corrective action before you
actually send the thing to a printer.

--FC



 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist