Hans-Martin Mosner has recently released his WysiTeX (updated for
VisualWorks 5i.x). See:

	http://www.heeg.de/~hmm/projects/WysiTeX/

It works dandy.

Cheers,
Bijan Parsia.

On Fri, 18 May 2001, Alan Kay wrote:

> While all of you are thinking about this, you should also see what 
> Knuth does in TEX using "glue" which is a kind of spring .... and 
> "dynamic programming" to pull all together .... Ian Piumarta is 
> rumored to have a TEX solver in Smalltalk somewhere ...
> 
> Cheers,
> 
> Alan
> 
> ------
> At 7:52 PM -0700 5/17/01, Ned Konz wrote:
> >On Thursday 17 May 2001 19:47, Mark A. Schwenk wrote:
> >>  At 5/17/2001 07:33 PM, Ned Konz wrote:
> >>  >Can someone suggest where Cassowary might be useful for the kinds of
> >>  > drawings I've been dealing with (i.e. shapes connected with lines)?
> >>
> >>  How about automatically positioning the shapes, using the lines as springs.
> >>  You can read an object instance model from the system, generate
> >>  collaboration diagrams showing the object relationships with the layout
> >>  done by the constraint engine. And then if you wanted, you could turn off
> >>  the constraint engine (at least in localized areas) and tweak the diagram a
> >>  bit.
> >>
> >>  It could also be used in laying out network diagrams, organization charts,
> >>  parse trees, etc.
> >
> >You know, I've thought about this a bit, and it seems like it could be done
> >without having to use a constraint system.
> >
> >I imagine a process that can be run on demand to re-position shapes based on
> >their interconnections. Push a button, and things are rearranged (with,
> >perhaps, a property that could exempt certain shapes from being rearranged).
> >
> >Attaching a single ConstraintMorph to each of the movable shapes that
> >examines the connections and re-positions its constrained object would do the
> >trick. You could either leave the CM attached, or delete them after they've
> >done their job. Every step time the CM would examine the connections to its
> >constrained shape, and compute a vector that it would use to move its
> >constrained shape.
> >
> >This would occasionally lead to oscillations, but you could manually move an
> >oscillating shape to fix it.
> >
> >I can't imagine a simultaneous solution for _all_ the shapes in a big
> >drawing; you'd almost have to compute them separately anyway. In which case
> >you have got the simple case: a bunch of independent variables (the
> >connections looked at as springs) and one dependent variable (the resultant
> >vector for this step). And this doesn't require (or benefit from) a
> >constraint solver.
> >
> >Unless I'm just not seeing the benefit.
> >
> >--
> >Ned Konz
> >currently: Stanwood, WA
> >email:     ned at bike-nomad.com
> >homepage:  http://bike-nomad.com
> 
>