[TUHS] V10 monk program

[arnold at skeeve.com]

Hi All.

V10 had a program called "monk" which was a "document compiler".
It produced troff and know how to run eqn, tbl, and pic and I'm
guessing also refer. It seems to have been inspired by Scribe.

The V10 files from Dan Cross have the device independent troff output
for the paper that describes monk.

G. Branden Robinson was kind enough to turn it into PostScript for me;
his story is below, forwarded by permission. I'm also attaching
the PostScript file.

I'm curious, did this see a lot of use inside Research or outside of it?
At first glance, it looks like the kind of thing that might have
caught on, especially for people who weren't already used to troff.

Thanks,

Arnold

> Date: Wed, 10 Jan 2024 12:25:53 -0600
> From: "G. Branden Robinson" <g.branden.robinson at gmail.com>
> To: Aharon Robbins <arnold at skeeve.com>
> Subject: Re: v10 ditroff output file
>
> Hi Arnold,
>
> At 2024-01-09T08:50:28+0200, Aharon Robbins wrote:
> > Hi.
> > 
> > The file of interest is attached. It's from vol2/monk in Dan Cross's
> > V10 sources in the Distributions/Research directory from TUHS.
> > 
> > If you can get postscript out of it somehow,
>
> Bad news and good news.
>
> ...unfortunately there was too much impedance mismatch with groff/grops.
>
> Some font names differ but that's not a big deal.  (Also, today I
> learned: the troff that generated this reloaded all the fonts at each
> new page.)  The troff(1) that generated this also attempted vertical
> motion before starting the first page.  That also wasn't a big deal.  I
> thought I was going to be able to text-edit my way to a solution...but
> then...
>
> grops really wants the device resolution to be 72,000 dpi, not 720, and
> we'd have to write a rescaling feature to support that.  Just editing
> the output file won't do because the file uses Kernighan's optimized,
> anonymous output command pervasively.
>
> groff_out(5):
>      ddc    Move right dd (exactly two decimal digits) basic units u,
>             then print glyph with single‐letter name c.
>
>             In groff, arbitrary syntactical space around and within this
>             command is allowed to be added.  Only when a preceding
>             command on the same line ends with an argument of variable
>             length a separating space is obligatory.  In classical
>             troff, large clusters of these and other commands were used,
>             mostly without spaces; this made such output almost
>             unreadable.
>
> So all these two-digit motions would need to become five-digit motions
> or all the glyphs would pile up on each other.  (And that's exactly what
> I happened after doing a couple of fixups and throwing gxditview(1) at
> it.)
>
> Out of curiosity, I tried DWB 3.3 troff.
>
> It did well, until the fourth page, when it fell over and produced
> PostScript that made Ghostscript very angry.
>
> So I tried Heirloom Doctools troff.
>
> 20 pages of goodness.
>
> But be advised: some sort of extension was used to embed other
> PostScript files:
>
> ./bin/dpost: can't open picture file samples/tailor.ps (line 1493) (page 2)
> ./bin/dpost: can't open picture file samples/memo.ps (line 1749) (page 3)
> ./bin/dpost: can't open picture file samples/tmbody.ps (line 2151) (page 4)
> ./bin/dpost: can't open picture file samples/tmcs.ps (line 2694) (page 5)
>
> So I went to minnie.tuhs.org to see if they were there...
>
> ...and they were.
>
> So here you go.  Renders without errors (though Heirloom is nowhere near
> as validation-happy as groff), and the output seems plausible.
>
> > I'll really appreciate it. :-)
>
> Enjoy!
>
> Regards,
> Branden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: monk.ps
Type: application/postscript
Size: 239405 bytes
Desc: not available
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20240111/f27eca97/attachment-0001.ps>