[ENH] Cassowary

Andrew C. Greenberg werdna at mucow.com
Fri May 18 14:52:07 UTC 2001


A follow-up on Knuth's glue, which defines a "springable" space between 
fixed width and fixed height blocks.  Each piece of glue can be defined 
as having a "normal" or "natural" width, and then a range of 
springability (and squeezability), which, when laid out, the extra space 
is divided in proportion to that amount.  The range can be defined 
either in fixed space units, such as inches, or in "infinite" units 
(that override all finite units with respect to springing).

This, combined with penalties for overstretching or shrinking a 
hunk-o-glue, leads to very beautifully laid out text.


On Friday, May 18, 2001, at 10:56 AM, 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
>





More information about the Squeak-dev mailing list