Please don't post huge programs (in this case 1500 lines) as email text.
For those of us who subscribe to the groff digest, it's a pain to scroll
past such monsters to see the remaining messages. Big documents are best
relegated to attachments, which readers who need them can fetch from the
mailin
Indeed, .so does not keep a quoted argument together. Surely that's a bug.
Doug
On Thu, Feb 20, 2025 at 1:39 PM onf wrote:
> On Thu Feb 20, 2025 at 5:59 PM CET, Douglas McIlroy wrote:
> > The idea that the argument of .so might contain unquoted spaces is
> > anathem
> .so[2-11] /my/source/file with spaces in the name
The idea that the argument of .so might contain unquoted spaces is
anathema--contrary to groff convention and fortunately not supported. I
think the idea of selecting lines from a file is good, but it doesn't
warrant new groff syntax. I wou
info groff gives semantics for including nonempty files that don't end with
newline. Such files violate the Posix definition of text file.
Although groff is certainly justified in providing semantics for non-Posix
text, I suggest that it should warn when it does so.
Doug
>> Surprise: in a font description file "scalesize" is called "sizescale".
>> [...]
> Huh?
> $ man 7 groff_diff | grep scalesize | wc -l
> 0
All too true. I don't know how I managed to copy the quote from
groff_diff(7) wrongly.
I hope the rest of my note is more accurate.
Doug
groff_diff(7) says scalesize is 1 by default and gives this
rule for interpreting scalesize:
[given] arguments that represent a type size in points the
formatter multiplies by scalesize and converts to an integer
Surprise: in a font description file "scalesize" is called "sizescale".
I ran
>> neither of which exists in groff tmac.s.
> I assume you mean "an.tmac",
Actually, I meant s.tmac--and even had that in a draft. But s.tmac is
utterly irrelevant--a horrible mental misconnect, burned in from
almost exclusive use of -ms.
Doug
> * People may discover that quotation marks are properly available in
> the man(7) language, a fact that has been obscure for 45 years. (The
> `\*(lq` and `\*(rq` syntax has been available since day one [1979]. I
> suspect these failed because man page authors who weren't already
> pract
I don't see this wording as an improvement:
> .ne dAdvance drawing position to the next vertical
>position trap and spring the trap, if it is
>nearer than distance d (default scaling unit v).
The proposal uses nonstandard terminology ("drawing position"),
and is ambi
>> I invented .ne 55 years ago and have never heard a complaint about its
>> design before. It is not a conditional .bp, because that would case a
>> line break, which .ne never does, nor should.
> I know it does not behave like a conditional `bp` (that was my
> entire argument, after all). I have
Re: Differences in `ne` and `bp` line-breaking behavior
> I have discovered recently that `ne` and `bp` behave differently in
> regards to pending input lines. `bp` breaks such lines, while `ne`
> does not. In practice this means that `ne` does not behave like a
> conditional `bp` as one would re
A worthy objective, but it should not be released without user
documentation. Where can one see that?
Doug
> echo is okay if no literal `\` appears in its argument list.
> If one does, I need to switch to printf(1)
Wise advice that I'd modify only by s/okay/right/. I believe
I've never used printf(1), but if I were preparing tiny test
scripts for groff I might well do so.
Doug
> > "printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -mandoc -Z - "
>
> [...]
> The foregoing is also revealing of a low level of sophistication with
> printf(1).
True. But why harness marginal feaures for such small benefit? Unrewarding
sophistication should be disparaged, not flaunted. I would s
Once again I emailed the wrong list, so here it is again, sent to both,
since it touches on both groff and history.
Sorry,
Doug
-- Forwarded message -
From: Douglas McIlroy
Date: Tue, Oct 8, 2024 at 8:21 AM
Subject: Re: groff_man.7.man.in: Some remarks and editorial changes for
A word of caution. AI is a dangerous tool. "Smart" features abound in
Microsoft Word and its imitators. They are neat when they work, but can be
extremely frustrating when they go wrong. Whenever one bites, you have to
cook up a special trick--or a whole new layout--to get past it.
A common examp
There it festered, right in the middle of Branden's otherwise high literary
style: "use cases". I've despaired over the term ever since it wormed its
way into computer folks' vocabulary. How does a "use case" differ from a
"use"? Or, what's the use of "use case"?
And while I'm despairing, "concate
This topic scratches an old itch: it's a shame that pic does not exploit \D
for filling polygons. I have filled an axIs-oriented right triangle in pic
by making a filled box and deleting one corner of the resulting \D. Other
polygons can be filled by breaking them up into axis-oriented right
triang
A day after opning on the subject,
I came across a delicious example,
"suspended between the nas-
tiness of life and the meanness
of death", split just like that between
recto and verso of the first leaf of
Toni Morrison's classic "Beloved".
Doug
> However, no matter what you do, you simply *cannot* end the last line
> of a column or page with a hyphen.predicting
Alas, it happens regularly in real life.
The groff line-filling algorithm would have a hard time predicting a page
break, for the break is usually the result of a yet-unseen .br,
Bernard wrote, "My work on the knuth-plass branch is also interesting,"
I'd love to hear how you approach that. All I could think of is really
heavy-duty dynamic programming that replicates almost the full internal
state of groff in every path.
As one example, the K-P paper sets type inside a cir
Slight correction. groff needs one empty line of input, not zero lines, to
produce proof.ps. According to the postscript, it was made with grops 1.22.
-- Forwarded message -
From: Douglas McIlroy
Date: Thu, Jul 4, 2024 at 7:56 AM
Subject: what is /usr/share/doc/groff/proof.ps?
To
The cited file is what would result from [groff /dev/null]. Why is it in
the groff distribution?
Doug
When I picked up a copy of 1.23.0 barely a week after its release, I found
(and reported) that [groff -ms -p] had a fatal auto-immune disease, in
which -ms diagnosed customary pic output as invalid. Nearly a year later,
our departmental computer center just caught the disease from Ubuntu. If
compla
Roff adopted the term "adjust" from Runoff, in the guise of.ad and .na,
which have persisted sixty decades, through nroff, troff, and groff.
"Justify" joined the roff family lexicon well before Branden's citations,
via pic's keywords ljust and rjust.
Doug
> 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.
Mandoc's diagnostic is good advice.
Doug
> [looping the groff list back in]
Again I got my wires crossed. Thanks.
> Do you happen to remember _when_ the CSRC got its 4014? About what
> year? Did Joe Ossanna have access to one early enough to use it in aid
> of troff development?
I think it was about the time of v6, well after the adv
> (pdfbookmark, pdf*href-M): Use the new mechanism to record a bookmark
> tag if `PRINTSTYLE` (a mom(7) macro) is _not_ defined
This feels backwards to me. I understand pdf.tmac to be a low-level macro
package that other packages can invoke. It shouldn't have to know what
packages are going to use
> By the time the formatter is done processing an input line, what it has
> to work with is a series of "nodes". These are each converted to one or
> more device-independent output commands. At this point what we have
> doesn't look much like *roff anymore.
My mental model of a macroprocessor is
> The question is whether or not man macros can be expanded
> to their groff equivalents.
If you'd consider a preprocessor based on groff, there's a
notionally simple way to get a copy of the input with macros
and strings expanded: Provide a groff option that has the
side effect of sending post-ex
To expand on Branden's observation that translating from one member of the
roff family to another is hard, I note that the final output of roff
usually presents a text in a shape that has been fine-tuned for appearance.
In grammatic terms it might best be described in transformational terms a
la Ch
In this real life example, the bigger brace has a lot more freeboard* than
the smaller one does.
groff -ms <
> For historical reasons (and for compatibility with AT&T 'troff'),
> the end macro exits as soon as it causes a page break and
> no remaining data is in the partially collected line.
This isn't the only anomalous behavior at the end of a
document. Since day one, troff has occasionally emitted
a b
eqn issues a .lf for every .EN. In 1.23.0 the line number is assigned as if
there were only one line of eqn text between .EQ and .EN, regardless of how
many lines actually are present. Thus the two fragments below yield
identical sequences of .lf requests
.EQ.EQ
1
> I'm still having trouble figuring out what you think is wrong with groff
> 1.23.0 relative to 1.22.4.
Stripped to the bone, this example
.LP
.bp
.AB
.AE
is accepted by 1.22.4 but not by 1.23.0. And, yes, I do have a
previously working -ms document that contains th
>> This diagnostic in -ms 1.23.0 breaks a document that works with 1.22.4:
>>
>> error: .AB is not allowed after first .AB, .LP, .PP, .IP, .SH or .NH
>>
>> This dictum is unreasonably prescriptive. The "error" is the
>> appearance of .LP in a cover sheet for the document.
> Where in the co
This diagnostic in -ms 1.23.0 breaks a document that works with 1.22.4:
error: .AB is not allowed after first .AB, .LP, .PP, .IP, .SH or .NH
This dictum is unreasonably prescriptive. The "error" is the
appearance of .LP in a cover sheet for the document.
Doug
The two bars below differ radically, although the barred objects have
the same width. The lone A gets a wimpy short bar. (Roman font merely
avoids possible confounding effects with slanted characters.)
.EQ
gfont R
A bar ~~~ "\&A\&" bar
.EN
If you put a bar over a string of As, the length of the ba
Sorry for the accidental send.Here's the whole message
Used in connection with man(7):
PS/PE
TS/TE
Used in other popular macro packages:
KS/KE
DS/DE
RS/RE
In hindsight I plead guilty to
EX/EE
Questionable newcomer in man(7)
UR/UE
And now, run
Used in connection with man(7):
PS/PE
TS/TE
Used in other popular macro packages:
KS/KE
DS/DE
RS/RE
Run up the flagpole:
>From the user's perspective, I think simplest would be if "line" took a
"fill" attribute subject to the constraint that the line ends where it
begins, something pic can enforce. In that case, it would draw a solid
polygon instead of a sequence of lines.
I once looked into the code to see if that
> I don't know of any other PDF generation tool chain that works that way
> [via PostScript] or regards it as optimal.
Nor do I, but I stick with the PostScript route because it's more flexible.
PostScript can be edited. In particular, I can edit the content of
figures, which I believe is impossib
Branden,
I forgot to add that your diagnosis seems to explain everything. I had
not noticed groff-perl among the zillion things on offer at Cygwin.
Being no fan of Perl, I may continue to rely on ps2pdf.
Doug
Cygwin did exclude gropdf and pdfgroff. "The accompanying man page"
that I meant was groff.1. Perhaps that man page should say that not
all groff distributions support pdf.
On Sat, Jul 29, 2023 at 1:35 PM G. Branden Robinson
wrote:
>
> Hi Doug,
>
> At 2023-07-29T13:00:13
1.22.4, which I got via Cygwin, lacks -Tpdf, although the accompanying
man page describes it. Is it perhaps an installation option that
Cygwin didn't set?
Doug
In the beginning header layout varied from edition to edition. The
first edition was printed one-sided with the date left and title
right. Then came two-sided printing with a double title, good for
printing either recto or verso. Some editions, but not all, displayed
the edition number in the cente
Upon updating from 1.22.4 to 1.23.0 this pic delimiter
.PS 6i
failed; it worked in 1.22.4. The updated pic turns it into
.PS 6.000i 6.000i 6i
which causes groff -ms to barf:
s.tmac: ... error: .PS: expected 2 arguments, got 3; not
preprocessed with pic?
groff, pic, and tmac.s were a
I hate to keep raining on the persistent dream of K-P in groff, but it
fits poorly with troff's basic typesetting model. How will it deal
with line-length changes that pop up in the middle of a paragraph, due
to requests that can come inline or from a macro, perhaps triggered by
a trap? K-P faces
not those of any past or present employer
>
>
>
> --
>
> Message: 3
> Date: Mon, 3 Jul 2023 19:53:58 -0500
> From: "G. Branden Robinson"
> To: groff@gnu.org
> Subject: [TUHS] Re: symbols in eqnchar
> Message-ID: <202307040053
Here's what I think is happening.
Each element of a row appears to be typeset on the same baseline.
It looks as if the baselines of adjacent rows are separated by the
maximum of the separations that would be needed in each column. This
assures that no entries collide with each other--the tightest
Given this input, eqn says it sees an end of file while reading
arguments of delim, but goes on to copy xxx to the output
.EQ
delim
.EN
xxx
Doug
> I think moving to
> .EQ
> delim ##
> .EN
> is an alternative which is easier to justify (and explain).
$$ is etched into my fingertips; @@ is the fallback when
I need to protect $1 and the like, typically for pic code
that contains its own macros together with eqn co
I am not convinced that using special characters rather than in-line
eqn is a good thing. It means learning a whole new vocabulary. Quick,
what's the special character for Greek psi?
I have found that, for a sequence of displayed equations as in an
algebraic derivation, a pile often looks more co
The fact that you can't apply "fill" to a polygon drawn with pic's
"line" command is a minor symptom of a general phenomenon. Pic accepts
any modifier attached to any command that admits some modifier, and
simply ignores those that don't make sense. A couple of examples:
box rad 1
b
Deri,
Thanks for concentrating our attention on detail.
Now I see that Branden hid some easter eggs for us to find.
1. An ellipse is said to have "diameter d". Actually it has principal
axes of lengths h and v.
2. There's a typo hv for the relative vertical position of arc center vc.
3. It isn
p]
>
> At 2023-06-05T20:57:37-0500, G. Branden Robinson wrote:
> > Hi Doug,
> >
> > At 2023-06-05T19:48:50-0400, Douglas McIlroy wrote:
> > > > I understand that groff has the \D escape which allows you, among
> > > > other things, to draw outline and
> I understand that groff has the \D escape which
> allows you, among other things, to draw outline
> and filled polygons.
Very helpful. I rely on the old testament book of
Ossanna and on groff(7), neither of which cover
that option for \D. One must look in "info groff". I
hope Branden's extensive
Pic knows how to fill a box, a circle or an ellipse.
Groff(7) says you can fill "closed drawn objects".
So, on a whim, I tried to fill a triangle by drawing a closed line.
.PS
line from 0,0 to 0,1 to 1,1 to 0,0 fill 0.5
.PE
The line is drawn but not filled, and no diagnostic is
issued for the in
bitmap produces unwanted artifacts such as. Moiré patterns.
Of course, on a very high resolution device 1000x1000 pixels may be an
extreme eye test, but I can deal with that if necessary.
Doug
On Fri, Jun 2, 2023 at 10:34 AM Damian McGuckin wrote:
>
>
> hi Doug,
>
> On Fri, 2 Jun 2023, D
Does anyone have a recipe for including a bitmap image in a groff
document? I wish to assure that on a raster-printing device the bitmap
is appropriately aligned with that of the device.
Doug
officially deprecated. Does anyone disagree?
Doug
On Tue, May 23, 2023 at 12:48 AM G. Branden Robinson
wrote:
>
> Hi Doug,
>
> At 2023-05-22T20:04:53-0400, Douglas McIlroy wrote:
> > > Basically, [if] a tab occurs within braces, it will be rejected.
>
> This statement of
> Basically, [if] a tab occurs within braces, it will be rejected.
Running eqn standalone, I got identical outputs from these
two inputs
.EQ
ab
.EN
.EQ
{ab}
.EN
The tab is passed to groff as \t\,
man 7 groff says \t is "uninterpreted", yet the tab
skips to a tab stop set by .ta. This leaves me
man eqn says
set thin_space n
causes n/100 em space to be "automatically inserted after punctuation
characters", which are vaguely defined as "characters such as ',' "
I used thin_space 0 to take away automatic space after . in formulas.
To my surprise it also took away intentional spaces
K-P would not be a mere add-on to groff. K-P knows in advance the
shape of the space into which a paragraph must fit, but groff doesn't.
This means a whole lot of groff state must be carried along with the
K-P dynamic program. The latter merely needs to keep a set of
candidate line-break points.
F
g list for paragraph awareness is far less so. Bad
things happen when "prettiness" overrides predictability and one has
to psych out the AI to fix the trouble.
Doug
* Truth be told, some of the idiocy is fun to complain about. My
all-time favorite is Open Office inferring that my name, M.
> $ ./build/test-groff -Tutf8
.> nr a 3c
> .nr b 3cm
> .tm a=\na, b=\nb
> a=283, b=283
> This suggests that one could get away with "3in" as well. Yeesh. Not
> sure how I feel about that. I think I'd prefer to have Yet Another
> Warning Diagnostic for non-pristine input syntax.
Beware of the
The proposal is clean and well defended.
Perfecting tweaks for the proposed man page:
1. Delete the parenthesized remark about boldface. At best it is TMI,
at worst, condescending.
2. To parallel the phrase "to be set in italic", delete "type" from
"to be set in roman type".
3. Delete the last
> Hi Doug,
>
> At 2023-04-01T19:45:19-0400, Douglas McIlroy wrote:
> > I went to see what this proposal meant and ran into undefined jargon
> > in groff_char.7.
>
> This, and phrases like "in the actual version", are regrettable defects
> in the groff 1.22.4
I went to see what this proposal meant and ran into undefined jargon
in groff_char.7. Yes, info groff probably tells me more than I want to
know. Still, I expect the man page to be terse, but intelligible.
What's an "entity"? Fortunately, Dave Kemper's post shed light on
this question.
The first
> Can anyone justify the existence of memset(3) in libc?
Memset is in the C standard; bzero is not. End of story.
Bzero is justly deprecated on the man page I have (2008-08-06 via Red
Hat). I avoid bzero and compile with "gcc -std=c17 -Wall -pedantic
-extra" to raise a flag when I stray from the
A nice property of "section" is that it's recursive--applies to any
level of a hierarchy--so you don't have to struggle to keep
level-specific terminology straight.
Doug
On Sun, Dec 11, 2022 at 2:21 PM Alejandro Colomar
wrote:
>
> Hi Michael,
>
> On 12/11/22 20:05, Michael Haardt wrote:
> > I ju
> Wouldn't it be nice to use -Wunterminated-strings and let the
> compiler yell at me if I write a string literal [that's too long]?
A good idea. Assuming you use gcc, please propose it at
https://gcc.gnu.org/bugzilla.
Apropos of help from the compiler, I normally run gcc via this script
and sta
> What do you think about this patch set?
Having worked towards list consistency in v7 (before which many lists
had been embedded in paragraphs), I am in awe of the effort. Back in
the day it was easy--simply edit the man page. Documenting changes
magnifies the job enormously.
Doug
I strongly second Steve Izma. "-based" is an ugly substitute for
"based on", regardless of what other words are present.
Doug
On Wed, Oct 12, 2022 at 12:03 PM wrote:
>
> Send groff mailing list submissions to
> groff@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> A man page author at anything less than master level might wonder, when
composing and test-rendering a section 7 page, why they have to supply
text in this case but not any other
I apparently weigh in far below master level. I didn't realize there
was a default per section. But seeing them laid
> I was wondering if tbl(1) wouldn't be better split into tbl(1) and
> groff_tbl(7)
The main argument against this very rational proposal is that tbl(1)
would become low-information wasted real estate. NAME and SEE ALSO
would tell almost all. Most of the page would be blank.
Doug
An empty field conveys as much information as the uninformative
default, "Miscellaneous Information Manual", with less clutter. I
recommend abolishing the default.
Doug
>> Physical Review was an early adopter of troff,
> Oh, interesting. I admit i submitted my own publications
> in Phys Rev D in LaTeX in 2000 and didn't know at the time troff
> would have been an option.
Phys Rev A adopted troff for their in-house typesetting soon after the
advent of eqn. It wa
Physical Review was an early adopter of troff, but now invites
submissions in either REVTeX or MS Word. A lot of math journals invite
LaTeX. Do any journals out there invite [tg]roff?
Doug
I agree with all of Ingo's comments. A man page is a reference, not a
history, not a tutorial, not a style guide, There s nothing to say
about NULL beyond it's being a synonym for the constant 0 converted to
the null pointer. Other facts about the behavior of null pointers will
have been learned ho
Changing the .TH case convention throughout the Unix world is about as
futile an effort as English spelling reform. Doing it for
groff-related man pages only would simply brand groff as quirky.
At least the current convention has the virtue of simplicity. A
convention of matching the case of comma
>> In regard to turning the warning on or off, the warning should not be
>> given when sentence spacing is set to 0
> I'm not sure I agree
I withdraw the suggestion. Since the default .ss 12 12 has the same
effect at a mid-line "sentence space" as copying the double space, I
had not realized that
In regard to turning the warning on or off, the warning should not be
given when sentence spacing is set to 0 (or below some small
threshold). In that case the opposite warning would be appropriate--a
double space between sentences is questionable when sentence spacing
is 0.
Doug
> I understand UNIX v7 is under this BSD-style license by Caldera Inc.
> https://www.tuhs.org/Archive/Caldera-license.pdf
The eqn document by Kernighan and Cherry also appears in the v10
manual, copyright by AT&T and published as a trade book. Wouldn't the
recent release of v10 also pertain to t
I believe pic will obey whatever size you specify by .PS.
Groff probably needs to be told about it via the somewhat bizarre option -P
Doug
AI is a bane of formatting. When Libre Office sees my name, M. Douglas
McIlroy, at the beginning of a line, it renders it by default as a
paragraph numbered with Roman numeral 1000 (and labels the next
paragraph MI). While groff is not so wild, it does have AI foibles in
intersentence spacing and
> I propose a radical solution to the problem of defining \&: return
> to the cstr54 definition,
Hear! Hear!
> if we must find a convenient, shorter alternative, "null
> character" seems the best choice,
You must be joking. That would be a gratuitous clash in
terminology for a large fraction of
> https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/C.1.2_NROFF_TROFF_Users_Manual.pdf
Since PDF didn't exist in 1981, the document is either a scan or the
result of a recent *roff run on ancient source. If it was made from
source, it's an impressive testimonial to the longevity
I don't see how to typeset a multilingual text
parallel by page strictly within groff.
However, suppose
1. the input comes from two different files
that contain synch points.
2 corresponding synch points must appear
on facing pages.
3. segments between successive sync points
always fit on one pag
.TQ strikes me as awfully special pleading: a single-shot zero-spaced
tagged list item.
.PD is at least general-purpose. It sets paragraph spacing globally,
which I deem
much better than setting it separately (via .TQ) for every item in a list.
I fail to see any case for deprecating .PD.
Doug
Tangential comment:
I have always recoiled from git. The appearance of "diff --git" in
Ingo's post reinforced my aversion.. --git is not mentioned in any
documentation (man or texinfo) I could get my hands on.
Gnu diff's 100-line help message is depressing enough even without
--git. Where did --
> Its main functionality is “calling groff with a number of parameters".
How might this be or become more than lipstick on a make(1) recipe?
I imported the windows package and started it. It immediately reported
that it couldn't find SSL. This smelled bad. What was its intent?
Finally, I'm used
>>> if (!*dst)
>>
>> As I've noted elsewhere (can't remember if it's where you might have
>> seen it), I dislike punning pointers to Booleans. But this is a matter
>> of style, and as far as I know nothing can go wrong with it.
>
> I wasn't punning the pointer to bool (which I also do
son
wrote:
>
> Hi, Doug!
>
> At 2021-12-30T21:18:04-0500, Douglas McIlroy wrote:
> > The man page roff(7) incorrectly attributes roff to Joe Ossanna.
>
> I agree, that's true of the roff(7) man page in groff 1.22.4 (and some
> number of releases before that I haven&#x
The man page roff(7) incorrectly attributes roff to Joe Ossanna.
Ossanna wrote nroff and troff, but roff preceded that work. The name
roff was first used to distinguish a rewrite for Multics from the
original runoff, probably because both were maintained on CTSS. I
wrote an extended roff in BCPL f
> This [disagreement in position of a drawn baseline]
> seems like a bug in Heirloom Doctools troff to me, but given that
> code base's provenance, it's easily possible that it's better aligned
> with AT&T troff behavior. (Does someone know?)
I don't know absolutely, but it's very likely that bot
The easy answer to making blocks of filled text that fit between two
tab stops is tbl(1), invoked by groff -t.The hard answer is to do by
hand what tbl automates: set the blocks to the desired width in
diversions then paste it together by fiddling with indents and
vertical motions.
Doug
On Wed, Nov 10, 2021, Peter Schaffter wrote:
On Wed, Nov 10, 2021, Douglas McIlroy wrote:
>> > .SP (or the groff request .sp) adds the current linespace (\n[.v]) to
>> > the requested distance when | is used, for which compensation needs
>> > to be applied:
>&
> .SP (or the groff request .sp) adds the current linespace (\n[.v]) to
> the requested distance when | is used, for which compensation needs
> to be applied:
Wording like this somewhat obscures the point.
.sp |d, where d is some vertical distance, provides that much space
from the top of the pag
> In a more purely mathematical context, I prefer the term "radix point",
> myself.
After reading the long list of suggestions, I would nominate"radix
separator" as a Utopian candidate, ideal but unrealistic. Then I would
vote for some term already in wide use.
Doug
1 - 100 of 132 matches
Mail list logo
