pretty printing graphs

[Bengt Richter]

On Tue, 29 Jul 2003 08:53:27 -0500, John Hunter <jdhunter at ace.bsd.uchicago.edu> wrote:

>>>>>> "Bengt" == Bengt Richter <bokr at oz.net> writes:
>
>    Bengt> How about (I added a name in the first node line for
>    Bengt> debugging, and boxing): (code follows output). Not tested
>    Bengt> much ;-)
>
>Thanks Bengt - that looks great.  You really should be on the payroll.
>
Email me for particulars on how to send money ;-))

>I won't have time until tonight to wrap my head around your code, but
>I think I'll add a to_dot method to the Node class which generates dot
>output, so I can use your ascii output for day-to-day stuff, and then
>go to dot for publication quality.
If you have an interactive window with tty font with box characters, it could
look pretty nice for "day-to-day", I think (though requiring a little more logic
for choosing boxing and connection line characters).
>
>Thanks all for the suggestions,
You're welcome. Be aware that I just copied your original post and
vimmed at it until something emerged. It's pretty brute force, recomputing
a lot, etc etc. And not very well factored. OTOH, it seems to work, within its limits ;-)
It could use some sanity checks etc. though.

BTW, also in this thread there is a version with connector lines
called pptree.py, in case that is of interest.

I think to make a real tool, I would design differently. Off hand IWT using a random access
2-dimensional mutable character array as a page "canvas" to paint on would eliminate
some of the constraints on the layout that are inherent in the way I did it in pptree.
(I.e., hierarchical box model where any box may be contain a centered smaller
box connected to one row of boxes underneath it, and any of those may similarly either
be a single box or contain a smaller top box with its row of children, etc., so each box
is only a matter of one top single box and one row of child boxes, whatever the content of
the child boxes. Then its just a matter of dealing with the different sizes.)

Also more abstract element definitions and drawing primitives could allow for subclassing
for different output media like ascii, tty/boxchars, tkinter, postscript, etc.

I'm curious as to what your actual text blocks represent...

Regards,
Bengt Richter