Re: [Groff] [off] micro-typography

[Thomas Baruchel]

On Tue, Feb 12, 2002 at 10:27:22PM +0100, Werner LEMBERG wrote:
> > What we are saying wouldn't be a revolution: groff already has
> > preprocessors, postprocessors, why not a new dynamical processor
> > that could interact with groff ?
> 
> It's not clear to me what you want to achieve.  Can you give some
> concrete examples, possibly with a syntax you have in mind?

I mean something like that. By mentioning a special option in command
line: 
  groff -[something] file > file.ps
groff would launch a processor in memory and open a socket between it
and troff. Then the troff code could contain some scripts parts,
which would be communicated to the processor through the socket. The
processor could itself need some more information. For instance, let's
imagine the script is a micro-typography script needing the length of
the string 'Hello, world' (in current font, current size). Then the
processor could use the socket to ask troff more information (of
course the most basic information would be the content of a register).
At the end it could send back to troff what it has to format as if
it were in the input file. A very simple protocol would be needed,
for instance:

troff -> processor
==================
EVALUATE ... END \" send the script to the processor
                    wait for instructions or 'CONTINUE'
ANSWER ... END   \" send an answer (always a string, because troff
                    often play on the confusion between number/string
and why not:
CODE ... END     \" send as an answer a bit of troff internal output code
                    (some like it); in fact send the content of a diversion
                    in troff internal code as a single infinite pseudo-page
                    starting at the top of it:   .sp |0u
etc.

processor->troff
================
EXECUTE ... END \" take ... as input code
ASK .l END      \" ask for the content of .l register
                   (and wait for 'ANSWER ... END')
DIVERT x END    \" content of the x diversion (wait for CODE ... END)
CONTINUE        \" troff can go further in the input file
etc.

The user could then play with ASK/EXECUTE, like today but computing
the information in a much powerful manner. In fact the processor by
itslef could be a mere interface to any other language. Then some
volunteers could write various 'doors' for their favorite languages.
For instance, I love Scheme. Why not imagine a small 'Scheme gate'
functioning like that:

input -- troff -- standard interface -- Scheme gate -- Scheme implementation

The idea is that the Scheme gate would be written for a specific
implementation, by knowing exactly how it works, then being able to
keep it open, defining new functions like:

(get-register 'x)
(width "Hello, world")
etc.

Of course, the INTERCAL lover could write his own INTERCAL door,
and the FORTRAN fanatic would do the same ;-)

I think that the client/server model is the best because it is
much less heavy than the 'system call' model.
(I don't like the idea of opening a Scheme sessions 250 times
in two minutes; besides the same session could keep in
memory global variables that can help for good typography:
when was the last time we put a floating object at the top of
a page? Construction of a global array in order to make an index,
a table of contents, etc.)

-- 
'\   (define Thomas_Baruchel
  \    ((lambda (k) (k k))
  /\     (call-with-current-continuation
 /  \      (lambda (k) (k k)))))                          baruchel @ usa , net