RE: GUI for Lout

[Tim Churches]

Henrik,

Wouldn't it be better to use an existing, well established DTD such as DocBook 
rather than create another one specifically for Lout, and then modify existing 
conversion filters (either DSSSL for OpenJade or XSL) to emit Lout? There is a 
a DSSSL stylesheet for DocBook which emits LaTex - it might be a lot quicker 
to attack this and translate Latex markup into Lout markup. DSSSL stylesheets 
are written in a Scheme-like syntax - doesn't look too hard (famous last 
words...).

However, a direct translator in Python would also be nice. But best to use an 
existing DTD.

Tim Churches

>===== Original Message From "Henrik Martensson" <address@hidden> 
=====
>Hi,
>
>Why not use XML? It would be a fairly easy to map Lout commands to an XML
>DTD (XLout?). All that is needed then is to write a filter that converts the
>XML documents to Lout.
>
>From what I've heard, Python has excellent facilities for handling XML, so
>it would probably be a very good choice for the filter language. (Most XML
>developers are very enthusiastic about using XSLT for filtering, but XSLT is
>very poor at character conversion, and has a number of other shortcomings.)
>
>There are several advantages to using the XML2Lout approach:
>
>* Much quicker and easier to implement than to write a decent
>  Lout editor.
>
>* It would be very easy to update the "XLout" DTD and XML2Lout
>  filter when Lout is updated, a lot easier than
>  updating a Lout editor. (A well designed DTD and filter would
>  make it possible to add new commands to the DTD and have them
>  correctly converted without changing the filter at all.
>  Extending the editor functionality would then be a matter of
>  updating the DTD only. Even non-programmers can learn how to
>  do this fairly quickly.)
>
>* An entire range of editors would become available, from
>  free editors like Emacs to commercial products like XMetaL,
>  WordPerfect and ArborText Publisher, to name a few.
>
>* Other XML processing tools, like databases, translation tools
>  and browsers would be available for use.
>
>* It would be easy to write filters that transform other kinds
>  of XML documents to "XLout". This would make it possible to
>  write documents that are usable in other contexts than print
>  publishing, and still use Lout when printing.
>
>* It would be possible to use sophisticated linking technologies,
>  like XLinks and Topic Maps. (An XLink-based topic Map framework
>  for XML is under development.)
>
>
>/Henrik
>
>----- Original Message -----
>From: Steven Baker <address@hidden>
>To: <address@hidden>
>Sent: Monday, June 05, 2000 1:18 AM
>Subject: GUI for Lout
>
>
>>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.
>>
>>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?
>>
>>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.
>>
>>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.
>>
>>Tia,
>>-Steven