At 2024-03-19T18:28:13+0000, Lennart Jablonka wrote: > Quoth G. Branden Robinson: > > > And the page numbers reset at the start of each section. Which > > > they shouldn’t do—the book is one unit; it should get its own page > > > numbers. And in other books, you don’t usually see page numbers > > > per chapter. > > > > This was a bug in me, not in groff. I forgot to specify `-rC1` when > > generating the PDF. Include it, and one gets 160 pages (using U.S. > > letter paper) numbered consecutively. > > How come that is not the default?
Historical inertia, most likely. Seventh Edition Unix man(7) didn't
offer an alternative.
groff_man(7):
History
M. Douglas McIlroy ⟨m.douglas.mcil...@dartmouth.edu⟩ designed,
implemented, and documented the AT&T man macros for Unix Version 7
(1979) and employed them to edit the first volume of its
Programmer’s Manual, a compilation of all man pages supplied by the
system. ...
... SunOS 2.0 (1985) recognized C, D, P, and X registers. ...
James Clark implemented the foregoing features in early versions of
groff. ...
> > > (“Section” being an older term for “man pages,” if memory serves
> > > right.)
> >
> > Not as far as I know. I use the term "document" when it's important
> > to distinguish between a coherent chunk of man(7) or mdoc(7) with
> > one `TH` or `Dd` call, respectively, and the face of a (perhaps
> > digitally) printed "leaf".
>
> The v7 Introduction indeed calls 1, 2, … 8 “sections” and sh(1) and
> the like “entries.” But v7 man(1) says:
>
> > NAME
> > man - print sections of this manual
> >
> > SYNOPSIS
> > man [ option ... ] [ chapter ] title ...
> >
> > DESCRIPTION
> > Man locates and prints the section of this manual named
> > title in the specified chapter. (In this context, the word
Well indeed it does.
But there is much about this 1979 man page I would quibble with, mainly
on terminological grounds. man(7) enjoyed tremendous success and its
users strained the macro language and its semantics at every boundary.
> > ... The chapter number does not need
> > a letter suffix. If no chapter is specified, the whole
> > manual is searched for title and all occurrences of it are
> > printed.
Alex Colomar lobbied for a resurrection of this also-vanished
terminology. I have a bit of sympathy for that proposal, because
"section" is overloaded (differently) both in Doug's usage and modern
convention.
> > The page numbers of each entry start at 1; it is infeasible to
> > number consecutively the pages of a document like this that is
> > republished in many variant forms.
>
> Huh. I don’t agree.
Some historical facts to note are that back then, (1) a Unix
installation might not have had disk space for all of the man pages plus
all of the cat pages. So some of the "on-line" man pages might have
lived only "off-line", which they (2) often did anyway--witness Holt,
Reinhart, and Winston's professionally bound and commercially sold copies
the Seventh Edition manual--but moreover, it was common practice to
maintain big binders containing Unix documentation on a bench in a lab
or terminal room. Frequently, the leaves of man pages were n-hole
punched to permit update of "the manual" in line with the software load
of the local Unix host(s). I trust it is obvious that a strictly
increasing numbering scheme would not long survive such updates.[1]
> Also a good point, though not what I meant. I think Courier itself is
> an ugly type face.
[...]
> Sure, but it would be a win already to replace Courier by a different
> fixed-width type face. But that’s site-local configuration, I guess.
>
> It would be better still to replace Courier by a non-fixed-width type
> face, because we really don’t need to emulate the nonsense typewriters
> do in print.
[...]
> I do object to Courier in displays. Courier is ugly. Ugly, ugly,
> ugly. Even under the fixed-width type faces, there are nice-looking
> ones. Courier is not one of those. Courier is ugly.
There is a major _technical_ problem with doing this, setting aside its
advisability.
No _standard_ PostScript or PDF font family _apart_ from Courier is
monospaced.
Plenty exist, but groff can't assume that _any_ of them are installed.
This is something you're going to have to take care of locally and
customize for the foreseeable future. I can see about en-knobbing it
for groff man(7) and mdoc(7), of course.
At 2024-03-19T14:47:38-0500, Dave Kemper wrote:
> True if it were emulating only typewriters, but fixed-width fonts are
> still very common in terminal emulators. So a font that emulates that
> aspect of characters to be typed at the terminal is a helpful cue to
> readers. (Not a defense of Courier itself, but of monospace fonts in
> certain contexts.)
I happen to agree with this. I have a mild distaste for Courier per se,
one that is probably conditioned by bad experiences long ago with
Microsoft systems where Courier roman was the typeface you got in a GUI
when something had gone wrong. I came it associate with dumbness and
failure. 1990s Microsoft systems copiously possessed those attributes.
But on the other hand I use a strongly serifed typewriter-looking font
(GNU FreeFont's FreeMono) for my xterms that I suspect many casual
readers would struggle to distinguish from Courier.
At 2024-03-19T19:59:58+0000, Lennart Jablonka wrote:
> Right. We can emulate the nonsense typewriter /emulators/ do. I do
> think that we shouldn’t do that, either.
I would not describe character-cell video terminals as "typewriter
emulators" precisely because they don't emulate typewriters well in
certain respects. The most obvious of these is that CCVTs, if you will,
don't overstrike. This fact has led to a passionate and bloody campaign
of calumny against grotty(1) and groff developers by people ignorant of
the fact that it's an accident of history (and casualty of AT&T's
rent-seeking and monopolistic behavior) that Unix nroff never got
rewritten by anyone as a terminfo or even termcap application. When the
great Unix bifurcation happened immediately after Seventh Edition, nroff
talked mainly to Teletype Model 37 paper terminals and daisy-wheel
printers (referred to in V7 non-generically as "Diablo" devices).
At that point termcap was (A) a Berkeley CSRG thing exclusively and (B)
not even called termcap yet, but "termlib". The CSRG didn't bother
patching nroff at any later point, and in fact they seem to have stopped
touching anything about *roff that bore an AT&T copyright notice after
4.2BSD (1983). Meanwhile, the AT&T USG (commercial Unix) hired the
termcap developer away from the CSRG to develop an incompatible (but
more capable) alternative called terminfo. Nobody at USG ever updated
nroff to work with terminfo, either. I have to guess that doing so was
judged to be insufficiently profitable, and video terminals emulated
typewriters well enough for unserious work like formatting man pages on
a screen. If you wanted real documentation, you paid the USG for
printed manuals, which justified the huge fees by occupying many
shelf-feet of space.
Back in the cradle, at the Bell Labs CSRC, the team famously pursued a
human-computer interface gambit, skipping over so-called "glass TTYs"
altogether, leapfrogging from paper terminals to a Xerox PARC-esque
portrait-mode green screen graphical terminal with mouse called,
variously, the "Jerq", the "Blit", and "DMD 5620". In the Eighth
Edition Unix manual you can read much about the intended interface to
this device. Rob Pike's fingerprints coated this system thoroughly.
All of this meant that the technology that ultimately prevailed, the
more-or-less ECMA-48 video terminal emulator, had no advocate in nroff
development for a decade. It remained fundamentally under-utilized by
nroff for over 40 years. Arguably, James Clark neglected it too, but I
don't blame him--during the most likely period for him to have done so
(1990-1995) the AT&T/BSD termcap/terminfo war was still raging, as was
the actual USL v. BSDI lawsuit for most of that time, and it would not
have been at all clear what the best way forward was. It would (should)
have been obvious that terminfo was the superior API, but it was larger,
harder to implement, and its published standard would still have been
held hostage behind massive fees for access. Someone at GNU wrote a
termcap library that didn't fail, but was orphaned immediately and
permanently, as if the very process of writing it killed its creator.
And then just as the smoke might have started to clear around 1995, the
likely site of a free terminfo implementation, the ncurses library,
suffered a bitter control dispute that once again took years to settle
out,[2] apparently once one of the parties came to believe he'd be an
overnight millionaire[3] and consequently developed an elevated
perspective about material reality (and, I believe, a sudden sensitivity
to the prospect of civil damages in a copyright infringement case
brought by X/Open, Sun Microsystems, or another System V vendor[4]).
But by then, James Clark was long gone from groff development.
And that, in something a bit larger than a nutshell, is why things suck.
Except for the bit about only one monospaced font family--that's a
simple case of Adobe knowing what is best for you, perhaps after its CEO
and those of a few major digital font vendors enjoyed a friendly
eighteen holes at Pebble Beach or Cypress Point.
That is why I value and appreciate your patch to make grotty a
terminfo(3) application, even though I'm slow as hell to integrate it.
Yes, I probably would move a little faster if I didn't spend entire
mornings composing emails like this one. :-|
Regards,
Branden
[1] In another area of geekdom, TSR tried a similar thing with its 2nd
Edition AD&D "Monstrous Compendium" series (1989-), the idea being
that dungeon modules, campaign setting supplements, and similar
would ship additional hole-punched sheets detailing new monsters and
you, the OCD-suffering DM, would dutifully collate the new monster
entries amid the "base" or "stock" set that came with the binder.
For what is now sometimes called AD&D 2.5e about five years later,
the company repented of this decision and reverted to perfect-bound
collections of monster descriptions. Perhaps this was due to a
realization, prompted by the rise of a market competitor (_Magic:
The Gathering_) and a corresponding realization that many (more?)
gamers passively collected product than demanded well-organized
source materials. (If so, they should have realized that fact long
before when comparing the sales figures of Gygax's 1979 1E _Dungeon
Master's Guide_ with the quality of its arrangement.)
But the real reason for the change was, I'd guess, that it made
production cheaper. Like too many corporate executives, Lorraine
Williams was a vampire and rentier.
[2] https://invisible-island.net/ncurses/ncurses-license.html
[3] https://www.zdnet.com/article/eric-raymond-how-ill-spend-my-millions/
[4] A three-year limit on filing civil copyright infringement cases is
widely understood to be in place under U.S. copyright law, and under
a reading most favorable to the defendant (which is the standard for
motions for summary judgment filed by plaintiffs), that limit would
have passed by January 1998,[5] since ncurses 1.8.5 had been
released on 23 February 1994. However, exactly what constitutes an
infringing act is subject to dispute, and even today, all these
years later, the firmness of the three year deadline is in question.
As a matter of fact, it's the subject of a pending Supreme Court
case, Nealy v. Warner Chapell Music.[6] The "smart" decision was
indeed to hand this bomb over to the FSF and see if it ever went
off. If it did, so much the better for the empire one was building
with oneself as president.
[5] ...when Netscape decided to embrace Free Software--but reoriented
their PR materials around the replacement term "Open Source" within
a few months.
https://opensource.com/article/18/2/coining-term-open-source-software
[6]
https://www.scotusblog.com/case-files/cases/warner-chappell-music-inc-v-nealy/
signature.asc
Description: PGP signature
