Re: man: EX/EE nested within nf/fi

[G. Branden Robinson]

At 2024-06-11T19:58:51-0400, Douglas McIlroy wrote:
> > I'd structure what you have like this:
> >
> > .nf
> > .EX
> > ...
> > .EE
> > .fi
> 
> .EX/.EE is too dumb for this.  Anything between .EE and .fi will get
> filled, which is almost certainly contrary to the purpose of .nf/.fi.

You're right of course.  My second episode of cerebral flatulence in one
message!  I was fatigued after dragging draft 1 of the resurrected
London/Reiser paper over the finish line and should have taken a break
(or not procrastinated doing laundry...)

> Mandoc's diagnostic is good advice.

Not for Alex's case, I don't think.  He really does want filling off for
all of his synopsis but also wants a monospaced font for only part of
it, so that he can indent and align structure members easily (without
resorting to formatter requests).

Regards,
Branden


signature.asc
Description: PGP signature

Re: Draft v2: London and Reiser's UNIX/32V paper, reconstructed

[Oliver Corff via]

Hi Branden,

thank you very much for this effort. One question: the appearance of
your reconstruction is slightly different from the original. Your lines
contain approx. 10% more characters, in result a 10-line paragraph in
the original text is about 9 lines long in the reconstruction. May I
assume that reconstruction of appearance was not your primary objective?
Do we know about the original font metrics? What would be the parameters
to .S in order to create an exact match?

Best regards,

Oliver.


On 12/06/2024 14:52, G. Branden Robinson wrote:

Thanks to those who have already given me feedback.  The document is
already improved, and the prospects for improvements to groff mm are
coming into sharper focus.

Please find attached:

1.  A PDF of the scan of the presumptively authentic original document,
 useful for comparison to any reconstructed rendering.
2.  A PDF of my revised reconstruction.
3.  Revised mm document source corresponding to #2.
4.  A diff of changes to #3 since the first draft I sent on Monday.

Regards,
Branden

--

Dr. Oliver Corff
Wittelsbacherstr. 5A
10707 Berlin
G E R M A N Y
Tel.: +49-30-85727260
Mail:oliver.co...@email.de

Re: Draft v2: London and Reiser's UNIX/32V paper, reconstructed

[Larry McVoy]

If we're gonna get precise, is the Bell Labs logo still accessable? 
Be nice to include that.

On Wed, Jun 12, 2024 at 05:02:22PM +0200, Oliver Corff via wrote:
> Hi Branden,
> 
> thank you very much for this effort. One question: the appearance of
> your reconstruction is slightly different from the original. Your lines
> contain approx. 10% more characters, in result a 10-line paragraph in
> the original text is about 9 lines long in the reconstruction. May I
> assume that reconstruction of appearance was not your primary objective?
> Do we know about the original font metrics? What would be the parameters
> to .S in order to create an exact match?
> 
> Best regards,
> 
> Oliver.
> 
> 
> On 12/06/2024 14:52, G. Branden Robinson wrote:
> >Thanks to those who have already given me feedback.  The document is
> >already improved, and the prospects for improvements to groff mm are
> >coming into sharper focus.
> >
> >Please find attached:
> >
> >1.  A PDF of the scan of the presumptively authentic original document,
> > useful for comparison to any reconstructed rendering.
> >2.  A PDF of my revised reconstruction.
> >3.  Revised mm document source corresponding to #2.
> >4.  A diff of changes to #3 since the first draft I sent on Monday.
> >
> >Regards,
> >Branden
> --
> 
> Dr. Oliver Corff
> Wittelsbacherstr. 5A
> 10707 Berlin
> G E R M A N Y
> Tel.: +49-30-85727260
> Mail:oliver.co...@email.de

-- 
---
Larry McVoy   Retired to fishing  http://www.mcvoy.com/lm/boat

Re: Draft v2: London and Reiser's UNIX/32V paper, reconstructed

[G. Branden Robinson]

Hi Oliver & Larry,

At 2024-06-12T17:02:22+0200, Oliver Corff via wrote:
> thank you very much for this effort.

My pleasure--if I can call it a pleasure to discover defects in groff's
mm package scrambling out like roaches when the light's turned on.  :-O

> One question: the appearance of
> your reconstruction is slightly different from the original.

Oh, definitely.  Pixel-perfection is not a goal, and even if it were, I
think it would need to wait for at least a few more revisions.

> Your lines contain approx. 10% more characters, in result a 10-line
> paragraph in the original text is about 9 lines long in the
> reconstruction.

I noticed.  Also I am not certain that:

1.  groff mm and DWB 3.3 mm use the same page margins;
2.  DWB 3.3 mm and PWB (or whatever London & Reiser used) mm use the
same page margins;

Each of these present challenges for fidelity, particularly the second.

In principle, difficulties can be worked around by setting groff mm
registers that affect these parameters.

> May I assume that reconstruction of appearance was not your primary
> objective?

It was an objective, up to isomorphism^Wfont and margin issues.

> Do we know about the original font metrics?

I personally do not.  Width metrics can be obtained for the fonts used
by DWB 3.3--they're right there in the troff font description files--but
we don't even know what version of the formatting software London and
Reiser used, nor which device they typeset the document that was scanned
and made its way into Ritchie's hands.

These uncertainties pose challenges for a perfect reconstruction.

> What would be the parameters to .S in order to create an exact match?

If the fonts aren't absolutely metrically compatible, this question may
not have an answer.

I won't rule out the fun/misery of fine tuning type size and margins to
reproduce 32vscan.pdf's line and page breaks exactly; I got far closer
to this goal with Kernighan & Cherry than I had even dreamed would be
possible.

But:

Before tackling that objective I think it's important that we iron out
any "macro" issues, in multiple senses.

1.  The macro package needs to behave very nearly identically.  There's
_some_ wiggle room here; things that don't affect breaking or
adjustment decisions aren't a big deal.

2.  The document _content_ needs to be correct; no missing or extraneous
words.  Any solecisms in the original, like crowded ellipsis dots or
"incorrect" hyphen/minus substitutions, must be preserved.  We can't
expect A and B to typeset the same if A and B are not equivalent in
terms of glyph sequences sent to the output driver.

Those two matters can be attacked in parallel and they are where my
focus is right now.

At 2024-06-12T08:16:15-0700, Larry McVoy wrote:
> If we're gonna get precise, is the Bell Labs logo still accessable?

I don't know that the Labs per se _had_ a logo.[1]

But Bell did, of course, and if you format the document with DWB 3.3
troff, you get it.

https://github.com/n-t-roff/DWB3.3/

More precisely, you get the Death Star, not the Wehrmacht helmet.  The
latter is what appears in 32vscan.pdf.

> Be nice to include that.

Did its trademark ever lapse?  Present day AT&T, after numerous M&As, is
a lineal descendant of BellSouth, the absolute worst of the Baby Bells--
the least innovative, the most negligent of research, the worst at
service delivery, the nastiest at customer relations, the most likely to
perpetrate a fraud on the American court system,[2] and the most
rapacious--so naturally the most successful in our meritocratic system.

The logo is consequently not a matter I'm keen to get involved with.
But if my reconstruction makes it trivially easy for someone else to get
a replica of the paper as London and Reiser might have viewed it, with
a correct corporate logo present, I'll be a happy guy.

Regards,
Branden

[1] https://www.bell-labs.com/usr/dmr/www/

Scroll down to "History".

[2] "Phrack editor Knight Lightning, aka Craig Neidorf, was arrested,
charged with fraud and tried before a grand jury for reprinting most
of a confidential document, known as the E911 document, stolen from
the Bell South telephone company. Bell South claimed that the
confidential E911 document contained sensitive information and put
its value at $80,000. ...

The case against Mr Neidorf collapsed when it was shown that the
E911 paper could be ordered by phone from Bell South for only $13."


https://web.archive.org/web/20200301210156/http://news.bbc.co.uk/2/hi/technology/4657265.stm


signature.asc
Description: PGP signature

Re: Draft v2: London and Reiser's UNIX/32V paper, reconstructed

[Oliver Corff via]

Hi Branden,

On 12/06/2024 18:22, G. Branden Robinson wrote:

Hi Oliver & Larry,

At 2024-06-12T17:02:22+0200, Oliver Corff via wrote:

thank you very much for this effort.

My pleasure--if I can call it a pleasure to discover defects in groff's
mm package scrambling out like roaches when the light's turned on.  :-O


One question: the appearance of
your reconstruction is slightly different from the original.

Oh, definitely.  Pixel-perfection is not a goal, and even if it were, I
think it would need to wait for at least a few more revisions.

Absolutely reasonable.

Your lines contain approx. 10% more characters, in result a 10-line
paragraph in the original text is about 9 lines long in the
reconstruction.

I noticed.  Also I am not certain that:

1.  groff mm and DWB 3.3 mm use the same page margins;
2.  DWB 3.3 mm and PWB (or whatever London & Reiser used) mm use the
 same page margins;

Each of these present challenges for fidelity, particularly the second.

In principle, difficulties can be worked around by setting groff mm
registers that affect these parameters.



Do you know whether your scan is scaled 1:1? In this case only, direct
measures could be taken from the image, assuming that the paper size is
letter.




May I assume that reconstruction of appearance was not your primary
objective?

It was an objective, up to isomorphism^Wfont and margin issues.


Do we know about the original font metrics?

I personally do not.  Width metrics can be obtained for the fonts used
by DWB 3.3--they're right there in the troff font description files--but
we don't even know what version of the formatting software London and
Reiser used, nor which device they typeset the document that was scanned
and made its way into Ritchie's hands.

These uncertainties pose challenges for a perfect reconstruction.


What would be the parameters to .S in order to create an exact match?

If the fonts aren't absolutely metrically compatible, this question may
not have an answer.

I won't rule out the fun/misery of fine tuning type size and margins to
reproduce 32vscan.pdf's line and page breaks exactly; I got far closer
to this goal with Kernighan & Cherry than I had even dreamed would be
possible.

But:

Before tackling that objective I think it's important that we iron out
any "macro" issues, in multiple senses.

1.  The macro package needs to behave very nearly identically.  There's
 _some_ wiggle room here; things that don't affect breaking or
 adjustment decisions aren't a big deal.

2.  The document _content_ needs to be correct; no missing or extraneous
 words.  Any solecisms in the original, like crowded ellipsis dots or
 "incorrect" hyphen/minus substitutions, must be preserved.  We can't
 expect A and B to typeset the same if A and B are not equivalent in
 terms of glyph sequences sent to the output driver.



Which, in return, makes visual identity an ideal tool to check for
undiscovered glitches which have the potential to cause inconsistent
line breaks.

When working in a negotiation team quite a few years ago, we would take
pages of claimed-to-be identical copies or transcripts of text,
superimpose them and check them against the light of a strong lamp for
gray areas --- mismatches in print. This helped us discover a good few
issues like altered digits etc., and the method was *much* faster than
reading side by side.

Best, Oliver.

--

Dr. Oliver Corff
Mail:oliver.co...@email.de

Re: Draft v2: London and Reiser's UNIX/32V paper, reconstructed

[G. Branden Robinson]

Hi Oliver,

At 2024-06-12T22:12:34+0200, Oliver Corff via wrote:
> Absolutely reasonable.
[...]
> Do you know whether your scan is scaled 1:1? In this case only, direct
> measures could be taken from the image, assuming that the paper size
> is letter.

I attached the scan I used to my earlier email.  I think a quick glance
is enough to reveal that such hopes are much too high for this document.

The pages aren't even scanned _straight_.  This made it tedious to
repair the OCR generated from it.  The OCR engine appears to have
imposed resolutely horizontal baselines on the page images and quantized
the word position to them, which scrambled the word order with high
reliability.  I've attached the OCR text output; you may find it
amusing.

(There _was_ an "unskew" option in the OCR UI.  I clicked it.  It seems
to have done little or nothing.)

The pages also appear not to be cropped consistently, which annoys me
for another reason: that makes it impossible for me judge the sizes of
the page margins used by the formatter/macro package.

With these problems I think the geometry of the page scans is pretty far
from a rectangle with a consistent aspect ratio.

I think it's more likely than not that the paper format was U.S. letter.
If this had been a journal article, that bet would be off.

> Which, in return, makes visual identity an ideal tool to check for
> undiscovered glitches which have the potential to cause inconsistent
> line breaks.
> 
> When working in a negotiation team quite a few years ago, we would
> take pages of claimed-to-be identical copies or transcripts of text,
> superimpose them and check them against the light of a strong lamp for
> gray areas --- mismatches in print. This helped us discover a good few
> issues like altered digits etc., and the method was *much* faster than
> reading side by side.

Right.  I think I've mentioned this on the list before, but this is the
principle behind the blink comparator, the tool that helped Clyde
Tombaugh discover the dwarf planet Pluto.

And I do in fact use that technique in groff development (including
today while comparing nroff mode output for various memorandum types
between DWB 3.3 and groff).  Since I run terminals maximized to the
screen geometry anyway, such comparison is always a keyboard chord away.

I simply don't have any hope of applying the technique here.  Not unless
a much superior scan of an authenticated original document turns up.

Regards,
Branden
a itn hare th

Pate

oS ~~

ae

Case-39394-21

te ee

an ors i

date: July 7, 1978

Subject: A UNIX™ Operating System for the DEC VAX-

from: Thomas B. London.
John F. Reiser
78-1353-4

fe

™:

nh ne Bye

11/780 Computer

li

Bell Laboratories

MEMORANDUM FOR FILE

Introdaction

'

ms

1.

lee

ic digital comThe VAX-11/780 [1] is a new, general-purpose, stored-program 
electron
it provides
prices
mputer
puter manufactured by Digital Equipment Corporation. At minico
address space bound of
addresses and data which are 32 bits wide; the traditional minicomputer
the implementation of a
64K is gone. This memorandum describes the VAX-11/780 and
2 contains an overview
UNIX operating system and complete user e..vironment for it. Section
only to devotees of computer syssuitable for general consumption, details 
normally of interest
on software portability in Section
t
tem architecture appear in Section 3. The authors commen

4.

2.

Overview

Environment.

the VAXA user of UNIX and C software on the PDP-11 will find that

Nala Weta SO

a ap

apparent differences in the com11/780 provides a very similar environment. 
There are no
rily invoked directly from
customa
arc
mand language or the vast majority of programs which
hardware, except by issuing
the
the shell. A casual user probably will not be able to distinguish
the current user) or by noting that
the command “who am i” (which identifies the hardware and
is in hexadecimal rather than
one of the columns printed by the process status command ps
pointer data types all occupy 4
octal. The C language programmer will find that int, long, and

The architecture seen

is “culturally compatible” with
by the user-mode assembly-language programmer of a VAX-11
r with the PDP-11 can quickly
the PDP-11. Specific details differ, but a programmer familia
and uses

MASSBUS interfaces
understand tne differences. The VAX-11 provides UNIBUS and
the same input/output peripheral devices as a PDP-11.

virtual address space, intelliSignificant new features of the VAX-11 include an 
extended
The address space of a process is
gent console, and dramatically improved physical packaging.
divided into a large number of
divided into a few gigantic segments. Each segment is further
« viable memory management
paging
demand
small pages. Sufficient hardware exists to make
omputer through a standard
microc
LSI-11
an
strategy. All console functions are handled by
processor and can still halt,
the
from
located
ASCII terminal. The terminal may be remotely
of the VAX-1 1/780 is wel

Re: -man fails to use ANSI commands

[Anton Shepelev]

Anton Shepelev wrote to G. Branden Robinson:

> > Check your environment for variables named "GROFF_SGR"
> > (a Debianism) and "GROFF_NO_SGR".  Unset them both and
> > try "groff -man -Tutf8" again.
>
> `export | grep -i sgr' finds nothing, unfortunately.
> Where else can I look for the reason of -man treating my
> virtual terminal as a printer?

I forgot whether I reported my solution, and if I did, I do
not see my answer here, so here it is for the record.  The
culprit is:

   /usr/share/groff/site-tmac/man.local

which has the following:

   .  \" Debian: Disable the use of SGR (ANSI colour) escape sequences by
   .  \" grotty.
   .  if '\V[GROFF_SGR]'' \
   .output x X tty: sgr 0

This means that one must /set/ rather than unset GROFF_SGR
to restore the normal nroff behavior.  See also:

   

Documenting a set of functions with -man

[Anton Shepelev]

Hello, all

What is the covenstional way of documenting a set of C
functions with -man?  Have you any recommendations or
examples about typesetting function declaraions, their
return types and aruguments in a classic man-page?  The .SY
macro does not seem to work well for C, because its function
declarations start with the return type.