[bug #64531] [ms] footnote continues emptily to next page

[Doug McIlroy]

Follow-up Comment #2, bug #64531 (project groff):


> Am I missing a trick?

On the contrary, you've supplied a trick for avoiding the pothole. Not the
same as preventing the pothole, but much better than what I did back when I
fell into it.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [Groff] groff ms: Is there an order to setting PS and VS

[Doug McIlroy]

> If I set ?registers PO and LL and also set PS and VS, the values of 
> PO and LL seem to revert to the default values. 

As you expected, the order of setting doesn't matter.

I don't see anything strange in the run below. where the stderr
output follows the closing '!'.

groff -ms <<'!' >/dev/null
.nr LL 10u
.nr PO 1000u
.nr PS 12
.nr VS 1u
.TL
Title
.tm \n[LL]
.tm \n[PO]
.tm \n[PS]
.tm \n[VS]
.LP
.tm \n[LL]
.tm \n[PO]
.tm \n[PS]
.tm \n[VS]
!
10
1000
12
1
10
1000
12
1

.TL and .LP are where all the setup action happens

Can you give a short example of what seems to go wrong?

Re: [Groff] groff, ms, and multipage boxed table

[Doug McIlroy]

> It appears, however, that since with ms doesn't handle my request
> for a table with 9 inch lines on an 11 inch landscape page.

-ms resets several critical registers from standard number registers
at the beginning of each "paragraph". Thus .ll is overridden from LL.
set .nr LL 9i. You probably want to do the same with PO.

Doug

[Groff] (no subject)

[Doug McIlroy]

[Groff] Mission statement PDF

[Doug McIlroy]

Peter wrote:
I've fixed the offending line in the Mission Statement pdf

Out of curiosity, what was the offense? Did some groff construct 
lead to it?

Doug

[Groff] figurate text in groff and TeX

[Doug McIlroy]

Suppose one wants to  control the shape of filled text so it
fits in a figure, for example a triangle or disc. In groff
one would set a trap to change indent and/or line length on
every line. The traps could be set all at once in advance,
or more elegantly by a self-resetting trap macro.

Examples of figurate text appear in Knuth's paper on
the placement of line breaks. How would the changing indent
and length parameters be expressed in TeX?

(The question is motivated from thinking about how to do
Knuth-ish line breaking in the extremely dynamic groff
environment. Figurate text, especially when done by a
self-resetting macro, is an example of path-dependent
state variables. In general it's possible for the text
itself to depend on path, but that's a challenge for
another day.)

Doug

[Groff] [TUHS] where the docs have gone

[Doug McIlroy]

The disappearance of some troff-related documents that had
been on line at Bell Labs was recently reported on this
list. That turns out to have been a bureaucratic snafu.
Plan 9 and v7 are back now. It is hoped that CSTRs will
follow.

Doug

Re: [Groff] figurate text in groff and TeX

[Doug McIlroy]

> Is there a shaping method which provides optimal spacing whilst using traps?

In  priniciple, yes, but I haven't heard a better way of doing it
than the multiprocess dynamic program that I once outlined on this
mailing list; everyone guesses this would be too costly to run.
This is a real challenge for anyone who wants to introduce Knuthian
line-breaking into troff.

But my actual question about figurate text was how in Tex (as
distinct from the Knuth line-breaking paper) would one specify
the shape of a non-rectangular paragraph, in which line length
varies as some function of vertical position.

Doug McIlroy

Re: [Groff] Typesetting Markup Language (TML) - a Superset of Groff

[Doug McIlroy]

bin7yr_t7bqk3.bin
Description: Binary data

Re: [Groff] Typesetting Markup Language (TML) - a Superset of Groff

[Doug McIlroy]

> As Dijkstra said of Algol, "an improvement over many of its successors"

In the interest of accuracy, Hoare said it in "Hints on programming
language design",
 http://i.stanford.edu/pub/cstr/reports/cs/tr/73/403/CS-TR-73-403.pdf
His exact words were
"it was not only an improvement on its predecessors, but also on
nearly all its successors".

doug

[Groff] for amusement only

[Doug McIlroy]

I was surprised to see atomic physics arise on this mailing list.
It took a while to realize that spdf, engraved in memory as the
energy-level sequence in a Bohr atom, has an alternate parsing
of general interest to groffers.

Doug

[Groff] bad QE in -ms

[Doug McIlroy]

The -ms macro QE typically draws a misleading diagnostic, "unbalanced QE".
This breaks old documents that expect QP-QE (quoted paragraph) to narrow
the text and then restore it. The groff QE does not restore.

In fact, QE is aliased to RE, which means it will cause other trouble
for a quoted paragraphs inside an RS-RE relative indent.

I guess the rationale for deviating from previous practice was to make
quoted paragraphs like other kinds of paragraph, which don't have end
macros.

If it is desired retain this difference between groff and heirloom
troff, a safer implementation would be to warn and behave like LP.
This is likely to do the proper restoration.

.als QE @QE

.de @QE
.@warning "legacy QE taken as LP"
.LP
..

Doug

Re: [Groff] bad QE in -ms

[Doug McIlroy]

>> The -ms macro QE typically draws a misleading diagnostic, "unbalanced QE".
>> This breaks old documents that expect QP-QE (quoted paragraph) to narrow
>> the text and then restore it. The groff QE does not restore.
>>
>> In fact, QE is aliased to RE, which means it will cause other trouble
>> for a quoted paragraphs inside an RS-RE relative indent.
>>
>> I guess the rationale for deviating from previous practice was to make
>> quoted paragraphs like other kinds of paragraph, which don't have end
>> macros.

> That's the way I'd always thought it worked. QP sets a block quoted paragraph,
> and the next LP or PP resets the margins to default.

> Perhaps it would be better to:

> .als QE nop

> So it's silently ignored.

Unfortunately, nop doesn't fix things very well, as these examples show:

Bad case I: 
.PP
A display quote occurs
.QP
Like this
.QE
in the middle of what the author wrote as
one logical paragraph.
.PP
Then groff -ms would add the tail of that paragraph 
to the quote.

Bad case II:
.KF
.PS
#Here's a figure
.PE
.QP
And its caption.
.QE
.KE
.PP
The following paragraph begins well enough, but if the
figure gets floated to the next page, then the caption
will run into the body text on that page

.als QE LP isn't perfect; one can invent cases where the LP
adds extra vertical space. But in general too much space is
better than none at all. Notice, though, that it won't hurt
any document that uses the latter-day (no QE) convention.

Re: [Groff] bad QE in -ms

[Doug McIlroy]

I found several old copies of tmac.s lying around in my files,
presumably modified for various special purposes.
They all contain not only QP-QE, but also an undocumented QS,
and a never-tested flag set by QP and unset by LP and PP.
It appears that QS was expected to be used when QE is not
immediately followed by another paragraph macro. The hanging
flag suggests that the logic was never fully worked out.
.de QP
.ti \\n(.iu
.RT
.if \\n(1T .sp \\n(PDu
.ne 1.1
.nr QP 1
.in +\\n(QIu
.ll -\\n(QIu
.ti \\n(.iu
..
.de QS
.br
.LP
.in +\\n(QIu
.ll -\\n(QIu
..
.de QE
.br
.ll +\\n(QIu
.in -\\n(QIu
.LP
..

[Groff] explicit and implicit spacing in eqn

[Doug McIlroy]

I may have made this comment before. My apologies if
it's already on someone's to-do list.

Groff eqn, unlike the original Unix program, attempts to
vary spacing according to mathematical custom. Thus it
automatically adds apace around the equal sign in
a=b
while in the old days one had to put the space in
manually
a~=~b
Somewhat surprisingly, groff eqn, adds space around
Unknown tilde escape.
= even in the presence of ~, seemingly as if ~ were
treated as a letter. This is relatively unnoticeable.
But it is not unnoticeable in case of unary minus.
Groff eqn treats
a~=~-b
as if it were binary, and inserts extra space between
the - and b.

I have a lot of eqn that this interpretation damages.
If the problem is something as simple as treating ~
as a letter, it should be easy to fix.

Doug

Re: [Groff] explicit and implicit spacing in eqn

[Doug McIlroy]

>> But it is not unnoticeable in case of unary minus.
>> Groff eqn treats
>>   a~=~-b
>> as if it were binary, and inserts extra space between
>> the - and b.
>
> It does work with the following patch--for the mentioned cases.
> In case of a=c~-b then there is only space before the '-',
> so either c-b or c~-~b must be used then.

Good sleuthing.  I'd say the fix is robust if the example of
a=c~-b is the worst anomaly left--I can't guess what anyone
writing that really might want. I hope the fix is adopted.

Doug

Re: [Groff] .if !dTS - GNU extension?

[Doug McIlroy]

> The canonical documentation, BTW, are the groff info files

How ironic!

Doug

Re: [Groff] .if !dTS - GNU extension?

[Doug McIlroy]

>>> The canonical documentation, BTW, are the groff info files

>> How ironic!

>  I always tried to maintain well-written man pages that covers
>  everything of groff

Yes. I am very glad for those pages. They are so good that I
had not been conscious of the info files, which you so aptly
call "canonical", not "primary" as many maddeningly
incomplete Gnu man pages do--a daily reminder that Gnu's
Not Unix.

Doug

Re: [Groff] *roff for desktop publishing - is it feasible?

[Doug McIlroy]

While I didn't look at the sample page, I bethought myself how
one might go about setting up the fairly stereotyped NYT editorial
page. Yes, I could copy the page quite exactly, but that would be
something like hand-setting the lines. How would one handle the
weird column layout of the Letter section? I've done complicated
things with troff, but if I had to make a living off that kind of
stuff, I'd go broke.

Doug

Re: [Groff] *roff for desktop publishing - is it feasible?

[Doug McIlroy]

> an example of some quite complicated page-formatting
> entirely composed using groff (with output to the PS
> device, and some embedded PostScript 

I have made greeting cards for 30 years by cobbling together
groff, PostScript, C, Haskell, shell and physical cut-and-paste,
often with input from advanced calculus. That's why I say I
couldn't make a living at it--once a year is quite enough.


doug

[Groff] floating keep of 2-column text in -ms

[Doug McIlroy]

In -ms, I want a floating keep (KF-KE) to begin with 1-column,
then switch to 2-column text. Of course I want the keep to
float past the following text. It is OK, though, if the keep
does have to float to a new page, for the new page to contain
the kept text and nothing more.

In many tries, I have met an equal number of surprises. I   
won't muddy the issue by enumerating them.

I would welcome any working example. I'd even accept a
suggestion of a different macro package that can peform  
the feat.

In extremis, I can finde the natural page break for the
flowing text and put the kept text right there. But this
is not exactly a robust solution.

Doug

Re: [Groff] [groff] groff developments - query about any interest?

[Doug McIlroy]

>   I hacked the eqn preprocessor so that it will translate equations into 
> LaTeX math.

That would be very useful for dealing with journals that insist
on making submissions their way--a great addition to the groff
suite. And now that you've shouwn the way, is there a chance for
rtf, too?

[Groff] Re overview of man(1) and groff(1) command line options

[Doug McIlroy]

I can't help wondering to what extent the man pages for the current
versions reflect this ground truth.

doug

[Groff] tilde glyph

[Doug McIlroy]

It appears that a tilde (unicode 07E) input to groff -Tpdf comes
out as a diacritical (unicode 303). This happens even when the tilde
is entered as \N'126'.
How can I get 07E?

Doug

Re: [Groff] tilde glyph

[Doug McIlroy]

Very helpful advice and explanation. Thank you.

Doug

Re: [Groff] Trying to use tabs and tab stops in groff

[Doug McIlroy]

> I cannot see what you are doing wrong (why the \t is not seen as a tab)

>From the troff user's manual: "\t   Non-interpreted horizontal tab"

Re: [Groff] ASCII Minus Sign in man Pages.

[Doug McIlroy]

I think it's pretty hopeless to ask for AI that can tell
whether a pasted symbol is a hyphen or a minus sign.
The answer is likely to depend on whether it is being
pasted into a program or into a document.

Doug

Re: [Groff] ASCII Minus Sign in man Pages.

[Doug McIlroy]

>> I think it's pretty hopeless to ask for AI that can tell
>> whether a pasted symbol is a hyphen or a minus sign.
>> The answer is likely to depend on whether it is being
>> pasted into a program or into a document.
>
> Right.  I'm happy for the typist to put in the effort.  Perhaps I'm
> getting too hung up on making the output be pasteable, but it's
> annoying, and not obvious to some, why `foo?bar' doesn't run when pasted
> from foo-bar(1).

Interesting difference in habits. I never look at groff-ed man pages on
line--only the default nroff, which is fine for pasting, and more
importantly, examinable with a full-featured editor.

And I don't see how a typist can foresee what I am going to
paste text into any better than AI can.  After all, I write
man pages and other documents *about* programs in volume
comparable to programs themselves.

Doug

Re: [Groff] Nesting font macros in man pages

[Doug McIlroy]

> .TP
> .B \-scale \c
> .IR xfac [, yfac ]

Very clever. I wish I'd thought of it when I was editing
the v7 manual. Then it would have become a standard idiom.
Has nobody tried this during the nearly 40 years since?

Doug

[Groff] pic syntax blemishes

[Doug McIlroy]

This pic fragment
d = 3
circle radius 2d
draws a circle of radius 2, not 6 as one might suppose. It is parsed as
circle radius 2 d
and the "irrelevant attribute" d is ignored.

In another context
d = 3
move 2d
the parsing results in a move of 2 then of d. Thus 2d is sometimes
taken as 2 and sometimes as 2+d, but never as 2*d.

Yet another confusion arises here:
nd = 3
move 2 nd
move 2nd
The first move behaves like move 2+nd, but the second (pun not intended)
is an error, because the pic tokenizer recognizes 2nd (also 2st and 2th)
as an ordinal.

The treatment of irrelevant attributes also allows crazy code like
box radius 3

The convention of dropping irrelevant attributes may have been justified
during the experimental days of pic's development, but seems cheesy now,
nearly 40 years on.

The fact that 2d gets tokenized differently from 2nd is also disconcerting.

I suggest that irrelevant attributes and constructions like 2d should
be errors. Any previously working code that such a tightening of syntax
might reject will be easy to fix.

What do folks think about this issue? Depending on response, I may try to
do something about it.

Doug

Re: [Groff] pic syntax blemishes

[Doug McIlroy]

> WOW.  After 40 years they're not errors, merely idiosyncrasies.

> I admire your courage.

Merely senority. The eruption was triggered by my ineptness at
figuring out how an old pic script that literally contained 2d
could ever have worked. The idiosyncrasies are not part of my
mental working set and probably never were.

Doug

[Groff] : ASCII Minus Sign in man Pages

[Doug McIlroy]

>  If you want a real minus sign (in particular in mathematical
> formular as opposed to in programming language source code),
> \- is not a good choise.

This statement baffles me. That is exactly what \- is supposed
to mean: the mathematical minus sign. In particular it is supposed
to match + in width and weight. Are you saying that it no longer
has that property and something else does?

Doug

Re: [Groff] : ASCII Minus Sign in man Pages

[Doug McIlroy]

Originally \(pl and \(mi came from a fixed font (S) while + and \-
came from the current font. As I understand your comment, groff
has reversed this troff convention. Additionally groff interprets - as
a compromise HYPHEN-MINUS.

man groff_char, however, tells the original state of affairs.  What is
one to believe?

Doug

Re: [Groff] ASCII Minus Sign in man Pages

[Doug McIlroy]

Branden wrote

Ingo's proposal would not mandate that + and \- come from the special
font.

It also would not mandate that \(pl and \(mi come from the current font.


--

I was previously told that \(mi is the true minus sign. But the
true minus sign, at least in my mind, must come from the current
font, so that it comes out right wherever it occurs, even in a
bold headline like "Fairbanks shivers at -50".


I'll buy Branden's  first assertion, but if + and \- come from the
current font as they originally did, and \(pl and \(mi come
from the the current font per the previous paragraph, they
become redundant.

So I remain confused.

Doug

Re: [Groff] ASCII Minus Sign in man Pages

[Doug McIlroy]

It would be well to have the Linux manpages project on board for man macro
discussions. Is anyone from that project on this mailing list?

If not, they should probably be invited to participate. A job for Peter Shafter?

Doug

Re: [Groff] Why does tty-char.tmac not represent meaning?

[Doug McIlroy]

Please change "gradient" to a generic name. It is usually
read "del" or "nabla" and it is often symbolized "grad" or "div"
But "gradient", by picking out one meaning of several
(gradient, divergence, laplacian) can obscure, rather than
reveal, the meaning.

doug

Re: [Groff] Why does tty-char.tmac not represent meaning?

[Doug McIlroy]

Ingo is right, of course. The inverted delta is read as grad when
it operates on a scalar function. The other readings (div, curl, laplacian)
are for that symbol in combination. But nabla-cross is never read
as "gradient times".

Doug

[Groff] pic.ps

[Doug McIlroy]

The Fedora system I have access to lacks /usr/share/doc/groff, and
in particular the wonderful tutorial /usr/share/doc/groff/pic.ps.
Was that omitted from groff 1.22.3, or did it get dropped somewhere
in the chain of custody between there and here?

Another bit of evidence: in a cygwin installation I also use,
the files in /usr/share/doc/groff are a year older than those
in /usr/share/groff.

Doug

Re: [Groff] devpdf U-fonts and Russian

[Doug McIlroy]

This discussion makes me wonder what the 3000-line perl script, grofpdf,
can do that a trivial shell script that calls groff and ps2pdf can't.

doug

Re: [groff] [Groff] Unintended impact of strip.sed on om.tmac-u?

[Doug McIlroy]

It has been said that stripping tmac files improves their 
perfomance. I tried it on s.tmac. It cuts the file by 48%.
But on a real-life groff file of considerable complexity
it saved less than 1% of cpu time.

This example suggests that stripping may be a frill that
makes groff maintenance more complicated to little advantage.
Does it make more difference in other macro packages?
If so, a comparison of commenting styles might reveal 
style recommendations that would overcome the need for
stripping. 

In short, I wonder whether stripping is an instance of
gnu bloat, a disease that groff has generally aavoided.

Doug

Re: [groff] A few newb questions about Troff typesetting

[Doug McIlroy]

> See `info groff Colors | less'

Also man groff_man. To see what's on offer nearby:
ls /usr/share/man/man7/groff*

Re: [groff] [UTROFF] references, summary, index

[Doug McIlroy]

I am still puzzled about paragraph-at-a-time typesetting in groff.

How does Utroff deal with even simple changes of line length, e.g. for
flowing text around an image as in the following trivial example.
A robust version that allows for intervening page or paragraph
breaks would pose even more difficulty.

.wh \n[nl]+3 `in +1.5i
.wh \n[nl]+3+2i `in -1.5i
Paragraph text here ...

The conundrum is that the placement of the picture is defined
by line breaks, but with paragraphwise justification, the
line breaks depend on where the picture is.

Unjustified text is becoming quite common these days, presumably
because the added shape of text helps the eye maintain vertical
sync. I personally prefer it.

On unjustified text, fmt (which uses an algorithm purported to be
like Knuth-Plass) does a worse job than nroff. Its scoring method
has a significant chance of making a paragraph less uniform
than nroff--perhaps because it isn't sufficiently "like
Knuth-Plass". But it also has a habit that seems intrinsic
to paragraphwise justification: each paragraph appears to
have its own distinct line length. How does Utroff address
this pitfall?

Doug

Re: [groff] Release Candidate 1.22.3.rc1

[Doug McIlroy]

> The "can't transparently output node at top level" and "can't
> translate character code n to special character 'c' in transparent
> throughput" warnings occur when gropdf is gathering entries for the
> PDF outline.  They have no effect on the output.  I thought I'd
> documented that, but, apparently, if I did, it wasn't in a good

How about letting the documentation also eliminate the problem?

That can be done by filtering the diagnostics from the pertinent
makefile recipe. A sed script will serve the purpose nicely.

Doug

[groff] modernization, maintanership, separate packages

[Doug McIlroy]

All these threads are tangled in my mind, so ...

-a: I use this quite regularly for quick peeks at line and page
breaks without the trouble of writing a file and looking at it
in another window. It is certainly the option I type most--the
rest are buried in shell scripts.

separate maintenance. macro languages suffer from being almost
write-only. It's only a slight exaggeration to say that each
package requires its own special expert. I would favor separate
maintenance, with the maintainer filing a regression test.
The groff maintainer need only run all the regressions and
check with the package maintainer on failure.

It's helpful to ship a small bundle of macro packages with
groff, just as a small bundle of fonts is shipped. But specialties
(e.g. chem) would best be available for download from the groff
website rather thancluttering the distribution. 

I would like to see font files as downloadable packages, too.

Doug'

Re: [groff] Skip the stripper?

[Doug McIlroy]

I wholeheartedly support eliminating the stripper. It's an
unnecessary step that complicates understanding and maintaining
the distribution package. And to an even greater degree it
obfuscates code that users (who have no interest in the arcana
of maintenance) may want to consult to unravel fine points or
bugs in macro packages. The only argument for stripping is
a supposed efficiency gain, which I suspect is too minute to
matter.

But the stripper should not be dropped solely--or even partly--

Re: [groff] Skip the stripper?

[Doug McIlroy]

The last line of my email on the subject was omitted.
The sentence should have read:

But the stripper should not be dropped solely--or even partly--
to squash a bug, unless the bug is known to be in the stripper.

Doug

Re: [groff] More on stripping

[Doug McIlroy]

The previous discussion that Branden cited offered no
significant data about the value of stripping.
I had given one example of a complicated scientific
paper with lots of pic, eqn, and tbl, typset with
the relatively simple -ms package. Stripping
made essentially no difference in the overall
run time.

Perhaps a more complicated macro package, especially
one that places comments within macro definitions,
would feel a greater effect--even more so if
preprocessors were not involved.

So I put together a -ms test with no preprocessors.
The input was about 1 MB, comprising 30K lines
of which 8000 were macro calls. I padded every line of
s.tmac that did not end in \ or \c with a 32-character
comment. Thus macro expansions were laden with comments.

The variance in running times pretty well swamped
the difference between -ms padded and unpadded.
The difference was at most a few percent.

With Peter preferring to distribute -mom unstripped,
it's hard to find an argument for default stripping.
Maybe mandoc doesn't want to give it up. If so, let
it have it and stew in its own complexity, while
all the rest get freed from meddling.

Doug

[groff] groff@gnu.org

[Doug McIlroy]

> Adding more invalid hyphenation points only happens if you use an incorrect
> (i.e., a too small) value for lefthyphenmin and/or righthyphenmin.

I do not profess to know anything about the hyphenatiion algorithm,
but this statement suggests to me that inconsistent ("incorrect")
combinations of hyphenation settings should be diagnosed. This
kind of arcana should not have to be kept in mind, even if it's
documented somewhere.

Doug

Re: [groff] PSPIC vs PDFPIC: adjust documentation to reality, Re: PSPIC vs PDFPIC: adjust documentation to reality, or the reverse

[Doug McIlroy]

> > Would it hence be sensible to change PDFPIC to fit the description

Yes. This is clearly a bug, even if it's been around for years.

Doug

[groff] mark/lineup in eqn

[Doug McIlroy]

Fellow groffers, what do you think of generalizing the application
of "mark" and "lineup" in eqn to work in columns and piles as
well as in equations.
The typical use of mark and lineup is to align = signs in
a sequence of equations. If the = signs signify steps of

Re: [groff] mark/lineup in eqn

[Doug McIlroy]

Sorry that my previous post was truncated. Here's what
I meant to say:

Fellow groffers, what do you think of generalizing the application
of "mark" and "lineup" in eqn to work in columns and piles as
well as in separately displayed equations.

A typical use of mark and lineup is to align = signs in
a sequence of equations. If the = signs signify steps of a
derivation, the equations should obviously be connected,
as in a pile. Displaying them separately, each with its
own EQ-EN, spreads them out vertically. One can play
with number registers (e.g. PD and DD in -ms) to try
to get the pile-like resultts, but it would much cleaner
if that could happen for free.

There is even a situation that EQ-EN can't handle, but
piles could:
.EQ L
xhortid mark = expression1
.EN
.EQ
longidentifier lineup = expression2
.EN
The marked place doesn't leave room for the subsequent
lineup. Piles, being typeset as a whole, would be
immune to this trouble.

Doug

Re: [groff] mark/lineup in eqn

[Doug McIlroy]

Ingo suggested a way to write two equations aligned
on equals signs, to look rather like this
   shortid = expression1
longidentifier = expression2

Here's the code
.EQ
set column_sep 35
matrix {
  rcol { xhortid above longidentifier }
  ccol { = above = }
  lcol { expression1 above expression2 }
}
.EN

Yes, I've used this trick many times. It's impenetrable to 
read and excruciating to edit. 



In fact the matrix trick is so painful that with tongue
hardly in cheek I'd claim that for the present example
raw troff would be simpler:

\h'\w'longidentifier'u-\w'shortid'u'\c
shortid = expression1
.br
longidentifier = expression2

Re: [groff] mark/lineup in eqn

[Doug McIlroy]

I agree it lines things up right horizontally. What I complained
about is that (at least in -ms) a separate EQ-EN pair for each
line introduces extra vertical space, so the sequence does not
look like a coherent whole. The matrix trick gives a better
display, but sacrifices any connection with ordinary math
syntax.  It makes no sense when read aloud.

Doug

Damian wrote:

When I try (the non-indented) version of this

.S 14 16
.EQ
shortid ~ mark = ~ expression1
.EN
.SP
.EQ
longidentifier ~ lineup = ~ expression2
.EN

with 'groff -mm', it does exactly what I think you want.

Re: [groff] mark/lineup in eqn

[Doug McIlroy]

Indeed, you can tweak things pretty closely (but not exactly)
with , but it fails to express logical intent. Thus it
is brittle. If you want to change anything left of the = sign,
you have to do more twiddling (pun intended) to restore  the
alignnment. Ditto if you change the document font.

Doug


Damian wrote:

.EQ
~~~ doug ~ mark = ~ expression1
.EN
.br
.EQ
malcolmdouglasmcilroy ~ lineup = ~ expression2
.EN

Re: [groff] mark/lineup in eqn

[Doug McIlroy]

Ingo,

Interestingly your comment is the first I have
received that is not of the form "you can jigger
this or that to get the desired effect". And indeed
I had over the  years  used every one of those tricks plus
one more: assemble the parts with tbl rather than
with an eqn matrix. I thought all of them were more
like hand-setting type than recording math.

However, I suspect the real reason that mark/lineup doesn't work
within a pile is that it wasn't considered. I see no
fundamental difference  between aligning on a mark and
aligning on any other point such as the center or
the right end. The only added complexity I see is that
one must keep track of two lengths rather that just
one within each line.

Doug

Date: Wed, 2 May 2018 17:53:17 +0200
From: Ingo Schwarze 
To: Doug McIlroy 
Cc: groff@gnu.org
Subject: Re: [groff] mark/lineup in eqn
You may think that pile/pile/pile and matrix are able to do it and
produce the correct indentation inside a single .EQ block, so
mark/lineup should also be able to as well.  But i fear that misses
the crucial point.  The reason why pile/pile/pile and matrix work
seems to be precisely because the tokens are presented out of order
in the source code, column by column, and that is precisely what
you do not want to carry over to your proposed mark/lineup semantics.

Re: [groff] Spooky action at a distance in line adjustment...sometimes

[Doug McIlroy]

Alas, spooky.diff, allegedly at
http://lists.gnu.org/archive/html/groff/attachments/20180626/6721611f/attachment.diff
elicits 404 Not Found. It may be that some server or client is
allergic to unusual file extensions.

doug

Re: [groff] Spooky action at a distance in line adjustment...sometimes

[Doug McIlroy]

Ancient history: when I wrote BCPL roff, I immediately noticed the
page-level density gradient from thick on the left to thin on the
right if padding spaces were inserted from the right. I next tried
randomly distributing the padding. This was even worse because it
led one to perceive false phrase boundaries at the wider spaces.
The text became maddening to read. Only then did I try alternating
left- and right-padding, which has stood the test of time.

But all this is a frill. Justified text seemed like a nice idea
at the time, because it distinguished computer-composed documents
from old-fashioned typewritten documents. But it soon became old
hat and people migrated back to ragged right margins, which may
not look as neat from afar, but also seem to be easier to read
both because of even spacing and because the variable margin 
provides distinguishablility to help a reader track vertical
position on the page.

Doug

Re: [groff] Spooky action at a distance in line adjustment...sometimes

[Doug McIlroy]

>> [randomly distributed padding]  was even worse because it
>> led one to perceive false phrase boundaries at the wider spaces.
>> The text became maddening to read. Only then did I try alternating
>> left- and right-padding, which has stood the test of time.

> Huh. I wonder what it would have looked like if you weighted the padding
> to happen more often after punctuation, taking advantage of the phrase
> boundaries.

Definitely worth a try. There's even an inadvertent example in the
first line above.

Doug

Re: [groff] How to show all hyphenation points?

[Doug McIlroy]

> a request that would print its argument with all hyphenation points visible
> ...
> it requires a contrivance to discover them

The second bit of the quote seems to answer the first: there's
no need for such a request because the function can be
accomplished fairly easily. 

But I have no perspective on what uses drove the suggestion.

What I see as the typical use is a nonce question about a 
single word. That is trivially handled by
groff -a
.ll 1u
recapitulation
The result is marrred with "can't break line" diagnostics,
but it's quick and intelligible.

Another use would be to consruct hyphenations for a whole
list of words. That would be a rare enough activity to justify
building a "contrivance" for the job per the old Unix adage:
combine tools that do one thing well (in preference to
festooning existing tools with ad hoc features).

Have I overlooked more compelling uses?

Doug

[groff] man-page fixes

[Doug McIlroy]

Regardless of standards considerations, if there's any advice
that needs to be hammered into man authors, it's to be concise
and accurate, but not pedantic. As Will Strunk commanded,
"Omit needless words."

The most needless words of all are promotional. No man page
should utter words like "powerful", "extraordinarily versatile",
"user-friendly", or "has a wide range of options".

As another instance of the rule, it would be better to recommend
short subtitles than to help make them long by recommending
quotes. If anything is said about limited-length macros, it
would best be under BUGS.

As editor for v7-v10, I would not offer v7 as a canonical
model. It owed its use of boldface in SYNOPIS to the limited
number of fonts (Typically R,F,I,S) that could be on our
typesetter at the same time. For v9 we were able to follow
Kernighan and adopt a distinct literals font (L, which happened
to be Courier but could have been identified with bold had we
wished). I still think this is the best choice.

As for options, v7 is a very poor model. It has many pages
that describe options in line, just as v1 had done for its
few options (called flags pre-v7). By v10 all options were
displayed in a list format.

For nagging reasons of verbal continuity, the options displays
were prefaced by *needless words* like, "The following options
are recognized". A simple OPTIONS heading would be better.

Unfortunately, an OPTIONS heading would intrude between the
basic description and less important details that follow
the options. (I don't agree that it would come too closely
after DESCRIPTION; a majority of man pages already have even
shorter sections.)  OPTIONS could be moved to the end of
DESCRIPTION. However, options may well be the biggest reason
for quick peeks at man pages; they should be easy to spot. It
has reasonably been suggested that OPTIONS should be a .SS
subsection.  That might be followed by .SS DETAILS.

Doug

Re: [groff] mom manpage

[Doug McIlroy]

> if you are interested in my perspective - scrap the HTML documentation
> and fix the manpage.  The reference manual - i.e. the manpage - is
> really important: when you use some software regularly, you use the
> reference manual all your life.  Catering to the experienced user

> is most important because whoever is serious about using the software
> will become experienced sooner rather than later.  So the reference
> manual (manpage) must be concise, precise, and correct.
...
> This is not rocket science and nothing new - just do it...

+10

Software that inherently defies concise description is suspect on
its face. In all likelihood it was built by accumulation way beyond
the bounds of any organizing principles that the author(s) may have
had at the outset.

Doug

Re: [groff] Design and Implementation of *roff

[Doug McIlroy]

> Without roff, Unix might well have disappeared.

The patent department and the AT&T president's office are the
only in-house examples I know where Unix was adopted because
of *roff.

The important adoptions, which led Berk Tague to found
a separate Unix Support Group, were mainstream telephone
applications and PWB, a Unix-based IDE.

The first telephone application happened in the field. An
engineer in Charlotte, NC, heard of this cheap easily programmed
system and proposed to use it to automate the scheduling and
dispatch of maintenance on the floor of a wire center. Ken
visited to help get them started.

The first Bell Labs telephone application was automating
the analysis of central-office trouble reports. These had
been voluminous stacks of punched cards that reported every
anomaly detected in huge electromechanical switches. The Unix
application captured the data on line and identfied systematic
failures in real time.

The patent adoption was a direct result of Joe Ossanna's
salesmaship. Other early adopters were self-motivated,
but the generous support lent by Ken, Joe, and others was
certainly a tipping force that helped turn isolated events
into a self-sustaining movement.

Doug

Re: [groff] mom manpage

[Doug McIlroy]

> Bash is a complex program, and the length of the manpage is
> entirely adequate.

It's adequate in the sense of being quite complete and accurate. It's
also verbose. The introductory paragraph is laudably crisp. But right
after that comes

-cIf the -c option is present, then commands are read from  the
   first non-option argument command_string.  If there are argu‐
   ments after the command_string,  they  are  assigned  to  the
   positional parameters, starting with $0.

Like much of the page this can be said in half the space:

-c The first non-option argument is the script. Further arguments
are assigned to the script's positional parameters $0, $1, ...

One may fairly object to the use of the undefined term "script". However,
the word already occurs 36 other times in the document. It should be defined
up front, perhaps by an opening sentence like this:

 Bash executes a "script" of commands, which is read from standard
 input by default.

The weasel-word "quite" in my opening sentence is deliberate. Verbosity
fosters errors: more text presents a larger cross-section to random
mistakes and challenges a proofreader's span of attention.

The quoted paragraph is a case in point. It reveals that the Synopsis

 bash [options] |[command_string | file]

omits the special syntax for positional parameters. I think a proofreader
of the shorter version would be able to pay more attention to the content,
and be more likely to spot the error. In my own case, the effort of
shortening forced a focus on the content, and prompted me to check the
Synopsis, thus uncovering the trouble.

Turning attention to statistics: given that one discrepancy exists within
the first 25 lines of the documentg, how many will there be in the whole
5000+ lines?

-

Getting back to the original subject, this thread led me to peek at
a few pages of Mom's 35,000-line html documention. I noticed a number
of proofreading oversights and stylistic inconsistencies that probably
would have been excised long ago had the document comprised only those
pages. Maintenance of the whole, though, is a daunting task.

At the same time, I was impressed by the thorough cross-linking in
Mom's documentation. It was easy to find explanatory information,
though I would quibble about how often reference inquiries could only
be answered by reading tutorial explanations. A major case in point:
the quick macro reference gives only macro names. You must follow a link
to be reminded of the arguments.

Before making this little foray into Mom, I had been put off by its
LONG_CAPITALIZED_MARKUP, which would quite dominate much of the fiddly
stuff I write: mathematics and man pages. This visit, though, led me to
realize that Mom gets closer than other general macro packages to one
of Joe Ossanna's original dreams, mechanization of style sheets to such
a degree that you can make major changes to style after the fact.

I'd be interested in hearing about experience with, say, taking a Mom
document written with one journal in mind and rendering it in the style
of another. (Neat as this would be, though, it probably wouldn't help
with submission, because journals are prone to insist on Word or Tex.)

Doug

Re: [groff] [patch] modernize -T ascii rendering of opening single quote

[Doug McIlroy]

I'm puzzled. How can one "modernize" ascii? Or to put the question
another way, what universally available character set does -T ascii
evoke?

doug

Re: [groff] [patch] modernize -T ascii rendering of opening single quote

[Doug McIlroy]

The proposal to use the same character for left- and right-quote,
as is customary in C, would be devastating to m4. 

The notion that it would make "kan pages look less antique"

Re: [groff] [patch] modernize -T ascii rendering of opening single quote

[Doug McIlroy]

I just mistakenly hit control-D, sending a half-baked message. Please
ignore it. Full message will follow.

doug

Re: [groff] [patch] modernize -T ascii rendering of opening single quote

[Doug McIlroy]

If I were conscientious in writing about m4, I might choose
to use \(oq and \(cq to assure pretty typesetting. It
would be a disaster to have both come out as apostrophes
in -T ascii. Knowing that, I could use \(aa and \(ga instead.

Still, this is a cautionary tale. What other sorts of
documents would suffer badly under this change?

Re: [groff] modernize -T ascii rendering of opening single quote

[Doug McIlroy]

Ingo has recorded me as being opposed to rendering \(oq and \(cq
the same in -T ascii.

I had raised the issue of ` in m4 and shell scripts. However, it
is good practice to make examples by pasting in working code,
which can in turn be cut, especially from nroff-ed documents.

The rendering of \(oq is irrelevant to this practice.

For publishing m4 programs, however, it is really nice
to have symmetrical left and right quotes. On asking around
(and also in some of my own work), I find that people are
very likely to use "changequote" to bracketing pairs such
as {} [] <> and not to risk damaging the code by transliteration

I conclude that my concern is very iffy. It should not be
taken as a "no" vote.

Doug

Re: [groff] modernize -T ascii rendering of opening single quote

[Doug McIlroy]

A diagnostic from gcc chimes in:
'mktemp' is deprecated: the use of `mktemp' is dangerous; use `mkstemp'

Doug

[groff] Loss of MSVC support

[Doug McIlroy]

I run groff on windows a lot, but via cygwin, which emulates
Unix. I am inclined to think that if you like the groff toolset,
you are likely to want other Unix capability, too, and thus
gravitate towards facilities like cygwin.

I take it that Keith uses groff on bare Windows without a
Unix veneer. If many people work in that mode, we should not
abandon them.

Doug

[groff] Loss of MSVC support

[Doug McIlroy]

I run groff on windows a lot, but via cygwin, which I
believe means that mainline POSIX stuff works. I am
inclined to think that if you like the groff toolset,
you are likely to want other Unix capability, too,
and thus gravitate towards facilities like cygwin.

Re: [groff] Loss of MSVC support

[Doug McIlroy]

Sorry for the false accusation about GOW lacking bash.
What it lacks is anything called sh. My roots are exposed.

Re: [groff] Loss of MSVC support

[Doug McIlroy]

> https://github.com/bmatzelle/gow

I wasn't aware of GOW. A quick look at the contents suggests to
me that what's lightweight about it is the absence of gcc, bash,
and curses (though it includes "less", a poster child for
featuritis).

Am I selling it short?

Doug

Re: [groff] [patch] modernize -T ascii rendering of opening single quote

[Doug McIlroy]

> people aren't aware that their manpage formatter is
> catering to a particular font style that is no longer in 
> common use. They just see that man(1) outputs "weird quotes."

As man pages are now, one will see weird quotes regardless
of how \(oq is rendered.

I checked /usr/share/man1/[a-c]* in Fedora Linux--about a 10%
sample of man1. Only 2 out of 328 pages contained \(oq or \[oq].
By contrast, 80 pages contained ` (0x60) used as a left quote, 
usually paired with ' (0x27) but (surprisingly) sometimes with \(aq.

Although it might help to render \(oq as ' on man pages,
it would be wrong to render 0x60 that way, lest examples
in which the distinction matters be mutilated.

Doug

Re: [groff] [patch] do not strip mdoc macros

[Doug McIlroy]

> It is objectively correct to strip the macro files of bytes that are
> meaningless for the program "groff"
>
> It is objectively correct to _not_ strip the macro files of bytes
> that have a meaning for humans.
>
> So provide both versions.

The conclusion is compatible with the premises but doesn't 
follow from them.

For human consumption, the comments are desirable. For machine
consumption the comments are harmless. So there is no compelling
need for the latter. For maintainability and intelligibility of
the groff distro, smaller is better.

Doug

Re: [groff] troff Address book

[Doug McIlroy]

> I was wondering if some kind of pre-processor existed back in the time

Yes, "form" and "fed", a form-letter generator and editor, were in the 2nd
through 6th editions of Unix. Created by Bob Morris and Lorinda Cherry,
they were independent of roff, but could of course could produce roff
input. You can find their man pages and perhaps their source code in
the Unix Archive at www.tuhs.org.  (Bear in mind that both man macros
and C were different back then.)

Bob Morris used it to patch boilerplate comments into journal referee
reports: sentences such as, "Related work, in particular ]1], should be
cited."  with [1]" and "This paper manuscript presents a known result,
previously published in [2]".  The referee reports themselves were kept
in the same repository.  The system reminded me of Vannevar Bush's Memex
proposal, but other uses did not materialize and it died of neglect.

Doug

Re: [groff] Groff output when using .2C and ms macros

[Doug McIlroy]

The difference between your example and Brian's is that in
yours, .2C mode starts mid-page while in his it starts at top
of page. The trouble will go away if put .ns before the first
.NH. The page-head macros do this automatically.

Doug

[groff] man7/groff.man. Was Make editorial changes.

[Doug McIlroy]

I agree with Ingo about proposed descriptions of \& and sentence
spaces. Elaboration is not explanation.

\& is simply a zero-length character. Its primary use is to disguise
sequences that groff would otherwise unwantedly interpret. For example,
"\&." at the beginning of an input line will be taken as text, not a
groff request. Given the general case, further examples are unnecessary.

"Sentence space" is a fraught convention, mentioned in groff(7) but
not defined. It is not revealed that "sentence space" is extra sace,
not the whole space between sentences. Nor is the default sentence space
stated. A first cut at a general definition might be:

BUGS
Extra "sentence space", by default one space character, is
inserted after sentences, which are identified by artificial
intelligence. False identifications may be mitigated by judicious
use of \&.

A personal false-identification hazard: in the court of groff I will
be declared innocent if I call myself M. Douglas McIlroy, but will be
sentenced if I call myself Mr. Douglas McIlroy.

Again speaking personally, this discussion has made me aware of the
second argument of .ss. I expect from now on to cut the Gordian
knot by using .ss 12 0, at least in nroff.

Incidentally, groff(7) defines \n[.ss] enigmatically thus: "The value
of the parameters [sic] set by the first argument of the ss request",
and defines \n[.sss] similarly. A more informative definition would be,
"The value N set by .ss N M". This rules out other plausible values,
e.g. \w' '*N/12.

Doug

[groff] man 7 groff; was nroff.1.man Make editorial fixes.

[Doug McIlroy]

I agree with Ingo about proposed descriptions of \& and sentence
spaces. Elaboration is not explanation.

\& is simply a zero-length character. Its primary use is to disguise
sequences that groff would otherwise unwantedly interpret. For example,
"\&." at the beginning of an input line will be taken as text, not a
groff request. Given the general case, further examples are unnecessary.

"Sentence space" is a fraught convention, mentioned in groff(7) but
not defined. It is not revealed that "sentence space" is extra sace,
not the whole space between sentences. Nor is the default sentence space
stated. A first cut at a general definition might be:

BUGS
Extra "sentence space", by default one space character, is
inserted after sentences, which are identified by artificial
intelligence. False identifications may be mitigated by judicious
use of \&.

A personal false-identification hazard: in the court of groff I will
be declared innocent if I call myself M. Douglas McIlroy, but will be
sentenced if I call myself Mr. Douglas McIlroy,

Incidentally, groff(7) defines \n[.ss] enigmatically thus: "The value
of the parameters [sic] set by the first argument of the ss request",
and defines \n[.sss] similarly. A more informative definition would be,
"The value N set by .ss N M". This rules out other plausible values,
e.g. \w' '*N/12.

Doug

Re: [groff] groff_man question

[Doug McIlroy]

>  EE  This is a non-standard GNU extension.  In mandoc(1), it does the
>  same as the roff(7) fi request (switch to fill mode).
>
>  EX  This is a non-standard GNU extension.  In mandoc(1), it does the
>  same as the roff(7) nf request (switch to no-fill mode).

"Gnu extension" should be read as "extension adopted by Gnu".
.EX/.EE was introduced in 9th Edition Unix.

Re: [groff] Small general question concerning ms macro package

[Doug McIlroy]

> Just a small question. Do you agree with me that ms does not really
> have separate procedures for things like indent and text boxes.

Besides .RS/.RE it also has .QP

Re: [groff] 02/04: grotty.1.man: Make editorial fixes.

[Doug McIlroy]

I have never used grotty. Reading the man page I wondered why one would
use it rather than nroff (which is absent from the SEE ALSO list).

Doug

pic anomalies

[Doug McIlroy]

The description of sprintf in the man page pic(1) does not
reveal that only a few format codes are permitted.

Eric Raymond's "Making Pictures With GNU PIC" says only
%,%e,%f,%g are  permitted. But what does a bare % mean?

In fact pic rejects a bare %. However it does accept
%%, which is supposed to print a single %. Pic,
however prints %%.

So I believe we have
1. An incompleteness in pic(1)
2. An error in "Making Pictures With GNU PIC"
3. An error in pic itself

Doug

Re: pic anomalies

[Doug McIlroy]

> Getting back on topic, are we sure we want to deviate from GNU pic's
> current behaviour without checking historical norms of other pics?
>
> $ printf '%s\n' \
> .PS 'print sprintf("%.17g %.0f% % %%", 3.14, 42, 99)' .PE |
> > pic >/dev/null
> 3.1401 42% % %%
>
> Though that may seem odd to our modern C-standardised eyes, it's
> understandable in that if it isn't a valid %f, etc., format specifier
> then it's a literal percent sign.

It looks like Ralph has turned up a really strange bug in pic
that suppresses pic's usual diagnosis of a bare % in a format.

The example can be boiled down to
sprintf("%g% %",1)
which produces
1% %
without complaint. If you omit either the 2nd or 3rd % though,
pic announces "bad sprintf format".

Doug

Re: GNUism in groff tests, was: pic anomalies

[Doug McIlroy]

>  C is one of the worst possible foundation languages conceivable for
> automated formal verification

Yet the Mars rovers run on a wholly checked code base written
in C, subject to certain mechanically enforced restrictions on
coding style. I'm not aware of comparably challenging systems
having been verified regardless of programming language.

But I stray far from groff.

Doug

Re: [groff] 01/03: **/*.man: Eliminate blank lines in man pages

[Doug McIlroy]

I almost agree with Ingo. A blank line in tbl is generally equivalent to
a table line in which all fields are empty. It is also generally equivalent
to .sp 1. These interpretations differ in the presence of .blm or .ns.
By decorating every table line with an initial \&, tbl has picked the
former interpretation.

Doug

mail groff@gnu.org

[Doug McIlroy]

Subject: " Re: man Macro Package and pdfmark"
> Just don't do that.  Never use low-level roff stuff in manual pages,
> don't even think about it.  This makes your manual pages non-portable.

I can understand why playing with private aspects of the macro
package may be unportable. And it would be poor style to use
low-level roff to do what the man macros can do. But I do not
see how portability concerns justify such a categorical
proscription.

As worded, the rule forbids one from using .de, .ds and .nr,
which may be useful in assuring consistency of usage within
a single man page. Heed the refrain in HMS Pinafore:
What, never?
No, never.
What, never?
Well, hardly ever.

Doug

eqn anomaly

[Doug McIlroy]

.EQ
define f % $1 %
f("a,b")
.EN

draws a diagnostic from Gnu eqn: "newline before end of quoted text".
Remove the comma and all is well. Apparently the comma delimits
the first argument.

The program isn't totally naive about parsing arguments. It
does think that there's only one argument in the macro call

f((a,b))

Surely this is a bug, not a feature.

Doug

evaluation of \w

[Doug McIlroy]

Why does this input echo "\w'0'"
.tm \w'0'
while this input echoes "5000"?
.nr w \w'0'
.tm \nw

Doug

amusing bug

[Doug McIlroy]

For a good time, try
groff -o /dev/null
I have reported this to bug-groff

Doug

Re: amusing bug

[Doug McIlroy]

Ralph pointed out that
groff -o /dev/null
does behave right. It sits there waiting for input.
Having been trained on the very first groff, I overlooked
the fact that this is the same as
groff -o/dev/null
separable parameters of flag arguments are a "modern"
innovation. Please excuse my antediluvian hangover.

Doug

discrepant groff configurations

[Doug McIlroy]

I run groff in windows (cygwin) and linux (redhat).
Groff's appearance in /usr/share is surprisingly
different in the two environments.

cygwin:
groff
1.22.4 current site-tmac
doc
groff-1.22.4
pic.ps

linux:
groff
1.22.3 current site-tmac
doc
groff-base
BUG-REPORT
MORE.STUFF
NEWS
PROBLEMS

Is this a difference between 1.22.3 and 1.22.4 or
between Cygwin and Redhat?

In the cygwin variant, the pathname of Eric Raymond's
excellent pic.ps changes with every release of groff.
while there's an unchanging "current" path to groff proper.
Is this the fault of cygwin.org or gnu.org/software/groff?

It is too bad that Raymond's piece is not in Redhat,
and not mentioned in MORE-STUFF, which lists groff-
related resources.

If the difference is between Cygwin and Redhat, I suppose
they are exploiting configuration options offered by
the groff project. What is the point of these particular
options? We're not talking significant disk space.
But we are talking cognitive dissonance for users of
multiple systems.

Doug

weird \s

[Doug McIlroy]

Does anyone else see the following behavior?
Version 1.22.4 handles \s correctly up to \s39, but
truncates a size of 40 or greater to its first
digit. Here are two screen shots, with ^D edited in
to show where input ends and output begins.

groff | tail -5
\s39 hello
^D
%%EndPageSetup
/F0 39/Times-Roman@0 SF(hello)81.75 12 Q 0 Cg EP
%%Trailer
end
%%EOF

groff |tail -5
\s40 hello
^D
%%EndPageSetup
/F0 4/Times-Roman@0 SF 1(0h)72 12 S(ello)-1 E 0 Cg EP
%%Trailer
end
%%EOF

The second example takes "0" as text, not part of the number 40.
I met the behavior with \s48. It continues at least 
through \s50.

Doug

Re: weird \s

[Doug McIlroy]

Thanks for spotting the facts in info, a jungle I rarely
enter. Especially for groff, for which groff(7) is quite a
comprehensive reference.

The difference between \s39 and \s40 is a documented living
fossil!

Clearly this dates from the first CAT phototypesetter's limited
range of point sizes: 6 to 36.  In one of his less brilliant
moments, Joe Ossanna apparently built that limitation into
troff's tokenizer: \s ate one digit, or two if the second is
not more than 3. This was not spelled out in the Troff User's
Manual, nor did it apply to .ps.  Hidden away as it was, the
obsolete feature persisted past the arrival of more capable
typesetters.

Did the author of groff steal the code from Bell Labs?  Or did
he merely read the code and preserve the feature in a misguided
nod to backward compatibility?  Did he find it by experiment?

Doug

Re: weird \s

[Doug McIlroy]

I've been writing the ugly \s360 since ancient times. Groff still thinks
this means a 36-point 0. But man 7 groff says it means a 3-point 60:

   \s±N   Set/increase/decrease the point size to/by N scaled points; N is
  a one-digit number in the range 1 to 9.  Same as ps request.

By convention ± is optional. Groff does as the man page says when
a sign is present, but does as Joe Ossanna did otherwise.

I would happily endure the breaking of a whole lot of old [gt]roff for the
sake of making the man page true. That would unify the syntax of
\s, \n, and \*. It would be as easy to recover from the change
(with a sed script) as was groff's imposition of a gap in .sp12.

Doug

Re: weird \s

[Doug McIlroy]

Amen.

I had a comment drafted and almost ready to go
when Bjarni made it unnecessary.

Doug

Date: Thu, 2 Apr 2020 19:11:35 -0700
From: Larry McVoy 
Agreed.

On Thu, Apr 02, 2020 at 09:11:50PM -0400, Mike Bianchi wrote:
> Bjarni,
>   Nice, tight analysis and proposed solutions.  Thank you.
>   Mike Bianchi
>
> On Thu, Apr 02, 2020 at 11:58:01PM +, Bjarni Ingi Gislason wrote:

snip

Re: weird \s

[Doug McIlroy]

> These changes may, must, shall, should be undone.

I'd like to think the message was postmarked April 1, but it wasn't.

> "and more recently, McIlroy referred to it as a ``living fossil''."
...
> "A living fossil" is a sign of a successful species (function).

> And now this species shall be "castrated" on the altar of an ideology,
> "all shall be the same (similar)".

I concede the persistence of horseshoe crabs. But "castrate" is exactly
the opposite of the evolutionary advance to which the message objects.
Evolution sometimes leaves vestigial organs, sometimes innocuous, but
sometimes problematic--as with the human appendix and \s.

In programming-language syntax, "All shall be the same" is an ideal,
not an ideology. The great John Cocke once told me, "Doug, you've got
to understand that Fortran is not a mathematical language or a logical
language; it's a natural language," meaning that Fortran grew by accretion
as it was built, for at that time rational language-design principles
had not yet arisen. And so it was with novel corners of troff.

> Who asked for changes and how?

I'll take the fall for the initial complaint. The move to fix it was
the upshot of an extensive discussion on this mailing list.

> [It will] cause a regression

Yes. Among my nearly 250 -ms files that comprise nearly 100,000 lines
of text, four are affected. Three of these had already been modified
to accommodate another (completely arbitrary) deviation of Groff from
Troff--the reversal of Pic's light-dark scale for area fill.

Far more significantly, every file that originated before my use of Groff
has been or still must be modified to recover from the revised syntax that
allows longer request names. That change was made for compelling reasons
analogous to those behind the \s fix. The latter fix is comparatively
benign from a regression standpoint, and firmly within Groff's modest
reform tradition--a total cure for a significant speech defect.

Doug

documentation of hyphenation

[Doug McIlroy]

groff(7) doesn't tell what the hyphenation modes are.
It directs you to info for the "gory details".
But info doesn't tell everything either. It omits .hy 0·

Mode bits 2, 4, and 8 turn off certain hyphenations.
A literal reading of info would have .hy 0 turn them on.

Since groff(7) is otherwise so complete, I'd love to see
it fixed. That can be done succinctly, and more accurately
than info, as follows

.hy same as .hy 1
.hy 0   turn hyphenation off
.hy N   turn hyphenation on, modified by some bits of N:
2 don't hyphenate across page boundaries
4 don't hyphenate first two letters of a word
8 don't hyphenate last two letters of a word

Doug

-ms anomaly

[Doug McIlroy]

This groff -ms document:
.LP
The formula is
.EQ
x = 1
.EN
produces just what one expects. But if .LP is deleted,
the formula is displayed in line. This causes little
trouble in everyday life. Nevertheless, -ms is
misinterpreting the output of eqn in this case.

Doug

-ms anomaly

[Doug McIlroy]

>> Nevertheless, -ms is misinterpreting the output of eqn in this
>> case.
> 
> It appears to be intentional. At least in groff's implementation
> of the ms macros, the first call to a paragraph macro is special,
> in that it terminates the front matter and begins the body text,
> and redefines a number of macros in the process, including EQ/EN.
> (Setting off the equation on a line of its own is the job of the
> EQ/EN macros, not of eqn.)

I suspect it's accidental. Further experiment shows that .EQ/.EN
work properly in the abstract (.AB/.AE) but not in the title (.TL).
This may be an artifact of limited memory on the PDP-11. A lot of
the original -ms was concerned with front matter, including the
details of cover sheets for Bell Labs internal memoranda. To
squeeze the package size, the set of available macros changed
after front matter was complete. Groff appears to perpetuate
that hack.

Regardless of how the behavior arose, it is certainly a bug for
-ms not to implement the semantics intended by eqn.

In my experimentation, I came on a related quirk. .AB and .AE
are noisily rejected and ignored if not preceded by .TL.
This behavior is rather presumptuous. Almost all groff runs
are drafts. Why must an incomplete paper have a title in
order to be typeset correctly?

I hit the .EQ/EN anomaly precisely because I was dealing with
a fragment of a paper. I was debugging some hairy equations 
that were to be slipped into a long manuscript later.

Doug