Re: GUI for Lout

[Jeffrey Howard Kingston]

On Sun, 4 Jun 2000, Steven Baker wrote:

> I am currently in the design process of a WYSIWYG editor for Lout
> which will most likely be written in Python.  I know this is
> controversial for some, but as much as I like to write my own Lout
> documents by hand, it is sometimes nicer to be able to see things
> right away and not worry about formatting---especially for shorter
> texts such as letters, or most of my homework.

Not controversial for me.

> 
> I have been mucking around the Lout code recently and seeing some of
> how it works, and I have done some looking earlier in the year as
> well...  I am wondering if there is a high-level way (perhaps via a
> simple function call, or a few in sequence) that will evaluate a Lout
> command and produce the PostScript output immediately?

Basically, Parse to get a parse tree of the user's input, followed
by SizeGalley to convert it into something ready for printing,
followed by two calls to FixAndPrint (first horizontal, second
vertical) to print the PostScript.

> Of a more important concern, are there any obstacles in the design of
> Lout that may impede my ability to evaluate Lout commands.  Basically,
> I don't want to have to rewrite a lot of the implementation for
> PostScript output, I just want to grab it.

The obstacle I see is the whole idea that you can do it in small chunks.
What about line breaks, what about page breaks, what about cross
references, what about running headers, ... ?  You might be able to
handle what I call the "functional subset" in my design paper, that is,
individual objects like

    @CurveBox { Hello world }

and the like, but this does not get you to the interesting stuff.

> For those of you that are concerned, I will probably be using Tkinter
> in Python, as the Tk Canvas widget looks as though it may be a good
> candidate to build the Lout widget on top of.  If further features are
> needed, at the expense of portability, I may use PyGTK+.
> 
> Anyways, some answers would be greatly appreciated.
> 
> Another thing I'm curious about is where the seemingly odd naming
> scheme for Lout source code files comes from?  z??.c is just a bit
> hard to remember where certain parts are found (although a simple
> Python script to extract comments here, helps!)...  It just seems odd,
> but I'm sure there's a good reason for it.

Actually, when you've worked on it for 15 years, it's not so hard to
remember the numbers; plus there is what amounts to a table of contents
inside externs.h (just search for z01.c).  I would find it harder to
remember names: was it parse.c or parser.c, was it postscript.c or ps.c,
etc.

Good luck.

Jeff Kingston