Re: [TUHS] Re: Old troff files (1988-2007)

[Peter Yardley]

This isn’t helpful, but the .G1 .G2 look a lot like Gerber codes used in NC 
machine tools. 

Sent from my iPhone

> On 5 Oct 2024, at 1:52 pm, G. Branden Robinson <g.branden.robinson@gmail.com> 
> wrote:
> 
> Hi Doug,
> 
> At 2024-10-04T21:42:50+0000, Jacobson, Doug W [E CPE] via TUHS wrote:
>> Folks:
>> 
>> Long story short, I have a unpublished manuscript that a faculty
>> member in my department wrote late 1980's early 2000's.  He did the
>> entire thing in troff, eqn, and pic.  The faculty member is still
>> alive.  A publisher is interested in the manuscript.  I have all of
>> the source files on an old unix machine that still has troff, eqn and
>> pic.  It also has groff.  This issue is that the pic commands are
>> bracketed by .G1 and .G2 not .PS & .PE.
> 
> As others noted, those are the characteristic preprocessor tokens used
> by grap(1).
> 
> groff(1) says:
>     A free implementation of the grap preprocessor, written by Ted
>     Faber ⟨faber@lunabase.org⟩, can be found at the grap website
>     ⟨http://www.lunabase.org/~faber/Vault/software/grap/⟩.  groff
>     supports only this grap.
> 
> Distributors often have a package of Faber's grap.  I'm not aware of any
> other in circulation.  (Happy to be corrected here.)
> 
> Please contact the groff list, groff at gnu dot org, if you have any
> problems using it to format these documents and/or to note formatting
> discrepancies between Unix troff and groff.  There will likely be some.
> 
> I've noted differences between DWB troff and Heirloom troff, so using
> the latter does not guarantee identical rendering, and moreover
> DWB/System V troff has some bugs/limitations that Heirloom and/or GNU
> troffs have fixed, and some of these can affect formatting.
> 
> Here's a list from groff's tbl(1) man page, for example.
> 
>   GNU tbl enhancements
>     In addition to extensions noted above, GNU tbl removes constraints
>     endured by users of AT&T tbl.
> 
>     •  Region options can be specified in any lettercase.
> 
>     •  There is no limit on the number of columns in a table,
>        regardless of their classification, nor any limit on the number
>        of text blocks.
> 
>     •  All table rows are considered when deciding column widths, not
>        just those occurring in the first 200 input lines of a region.
>        Similarly, table continuation (.T&) tokens are recognized
>        outside a region’s first 200 input lines.
> 
>     •  Numeric and alphabetic entries may appear in the same column.
> 
>     •  Numeric and alphabetic entries may span horizontally.
> 
> One can imagine how a 200+-row table could format differently between
> DWB/System V and GNU tbl, without either being "wrong".
> 
> Regards,
> Branden