Re: removing the .IX macro from the ms package in 1.23 breaks old documents

[Tadziu Hoffmann]

> > Of course the macro also needs to be upgraded to properly format
> > multi-line TOC entries, but that's a different problem.

> Anyone want to volunteer?  :)

I just realized it is not necessary.  The TOC mechanism in ms is
very general.  It requires the user to provide content for the
TOC between calls to XS and XE, but that content can contain
arbitrary control lines, so we can just set up the indents
any way we like.

Here's a demonstration using Joerg's example.


.\" ms
.\" 
.ds FAM T
.nr PS 15700
.nr VS \n(PS+4p
.\" 
.de MHEAD
.XS
.sp 1v
.nh
.in \\n[tocw1]u+1n
.ti 0
.ta \\n[tocw1]uR +1n
.ft B
\t\\$1\t\\$2\h'1n'\c
.ft P
.XE
..
.\" 
.de SHEAD
.XS
.nh
.in \\n[tocw1]u+1n+\\n[tocw2]u+1n
.ti \\n[tocw1]u+1n
.ta \\n[tocw2]uR +1n
\t\\$1\t\\$2\h'1n'\c
.XE
..
.\" 
.LP
.nr tocw1 \w'\fB1.\fP' \" these should reflect the longest
.nr tocw2 \w'1.11.'\" section numbers at each level
.MHEAD 1."Chapter whatever
.SHEAD 1.1.  "long entry not honouring indent after line break as one\~can see: 
foo bar baz foo bar baz
.SHEAD 1.2.  "short and good entry
.SHEAD 1.3.  "this entry fails to line break but instead pushes numbers to the 
right
.SHEAD 1.4.  "short and good entry
.SHEAD 1.5.  "long entry not honouring indent after line breaking. the\~word 
`elaboration' seem hyphenated too late, too (hyphenation aligned with page 
numbers)
.SHEAD 1.6.  "short and good entry
.SHEAD 1.7.  "the next entry below shows additional problem of spurious ruler 
(single dot) way too close to preceding\~text
.SHEAD 1.8.  "short and good entry
.SHEAD 1.9.  "Distributed Model als unendlich-dimensionales Kompartmentmodell
.SHEAD 1.10. "Of course none of the above happens anymore
.MHEAD 2."Chapter whatever
.PX


tocbug.pdf
Description: Adobe PDF document

Re: removing the .IX macro from the ms package in 1.23 breaks old documents

[Tadziu Hoffmann]

> If we establish that this is a bug [...]
> But I need evidence of that, and as yet I don't have it.

I don't have any evidence other than

  a) empirically, it fixes Joerg's problem.
  b) logically, it is necessary, as the leaders and the
 pagenumber are attached to the end of the line, so one
 needs to guarantee that there is enough space for them.
  c) aesthetically, you don't want the text in the TOC to
 extend all the way to the right margin, so that the
 pagenumbers stand out (literally and figuratively).
 That means that the margin for the text (= 8n) should
 be larger than the space for the pagenumbers
 (= TC-MARGIN = \w'000').

Of course the macro also needs to be upgraded to properly
format multi-line TOC entries, but that's a different problem.

Re: removing the .IX macro from the ms package in 1.23 breaks old documents

[Tadziu Hoffmann]

> the most serious one is misalignment of page number column
> for entries which are long but seemingly fail to line
> break early enough. there are also instances where the line
> break just occurs too late w/o causing page number column
> misalignment (this seems to be the case when no further
> ruler char creeps in).

Can you try putting a

  .ll -8n

after the line containing ".na" in the definition of XA in s.tmac?
That used to be there before.

Re: How \c works (was: removing the .IX macro from the ms package in 1.23 breaks old documents)

[Tadziu Hoffmann]

> we already have a means of input line continuation [...]

Not in the sense that the input line can be interrupted by
some other processing and then continued.  But we do have a
workaround for this situation: append material to a string
until the full line has been assembled, and then feed it
into the input stream.

Re: removing the .IX macro from the ms package in 1.23 breaks old documents

[Tadziu Hoffmann]

> .

I must have been blissfully unaware of this discussion.

However, I want to caution against the idea that "\c" continues
an *input* line.  "\c" is something that concerns the *output*.
I.e.,

  foo\c
  bar

is *two* input lines (and therefore I believe the input trap
request .it should count it as two).
This is consistent with other troff behavior, in particular
tabs and fields, which are relative to the *input* line.
Here is an example ( should be an actual tab character):

  .ta 10n +20n
  .fc ^ #
  ^#\m[black]xxx\m[]#^\
  ^#\m[blue]xxx\m[]#^
  .br
  ^#\m[black]xxx\m[]#^\c
  ^#\m[red]xxx\m[]#^
  .\" the following is just decoration
  .sp -3
  .ta 10nC +20nC
  01030
  .sp -1
  \v'0.3v'\
  \D'l 0 -0.1m'\D'l 10n 0'\D'l 0 0.1m'\
  \D'l 0 -0.1m'\D'l 20n 0'\D'l 0 0.1m'
  .br

This sets up two fields, the first one 10 ens wide and the
second 20 ens wide.  The first input line centers the text
"xxx" in black and in blue in these two fields.

The second input line again centers the text "xxx" in black
in the first field.  This input line ends in a "\c", but
this does not continue the input line.

The third input line also centers the text "xxx" (in red)
in a field, but since a new input line has been started,
this again corresponds to the first, 10-ens-wide field (not
the second, 20-ens-wide field) so it outputs something that
is 10 ens wide, even though this output is now attached
to the 10-ens-wide output from the second input line and
superficially looks like it is inside the second field of
the first input line.

If we want to change the semantics of "\c" to mean continuation
of the input line, then I believe we should also change this
above behavior of tabs and fields, so that the red "xxx"
will be in the second field like the blue "xxx".




inputlines.pdf
Description: Adobe PDF document

Re: opposite of \c?

[Tadziu Hoffmann]

> but i can't figure out how to inhibit the space for
> the end quote inside the macro, so it ends up like
>
>   'wow wow the text is quoted '
>
> is there an escape or a request that allows for this?

Many times have I wished for such a feature to exist,
but there is no equivalent to "\c" that can be applied
after the fact.

However: groff has the ".chop" request, which removes the last
character of a string/macro/diversion, and which we can try
to use to remove the last whitespace newline from the end of
the quoted text, before attaching the ending quote character.
But since chop only works on strings/macros/diversions, and
not on the running text, we first have to save the material
in a macro or diversion before we can do the chopping.

The attached code is an example of how this might be done.
For illustration purposes, it also shows the nesting level
alongside the quote characters.

But why does it work at all?  The first call of .q( begins
at level 0 before "She said," but only scans forward until
the first .q) (after "nesting"), at a nesting level unknown
to the macro.  (It just collects text, and can't count the
number of .q( and .q) encountered.)

The reason it works is that upon the first replay of the
collected qq the second .q( is invoked, which causes it to
redefine qq with the remainder of what had been read the first
time, plus additional material until the next .q), and so on.

Note that adding the ending quotes is delegated to a separate
macro .qe, which only gets expanded when the text is finally
processed for output and the correct nesting level is known,
and not when the line ".qe" is just copied from macro to macro.
We cannot add the ending quotes directly in .q), because the
numeric register ql will not necessarily contain the correct
quote level for the ending quote at the time .q) is called,
and since it is also invoked at different nesting levels,
we can't just add an appropriate number of backslashes.


.\"
.\" 
.po 3c
.ll 21c-6c
.sp 2c
.ps 18
.vs 20
.\" 
.ds ql \m[red]\s[\\n(.s*5/10]\v'-0.7m'[\\n(ql]\v'+0.7m'\s0\m[]
.\" 
.nr ql 0
.de q(
.nr ql +1
.de qq q)
.ie \\n(ql%2 \\$1\\*(ql\(lq\c
.el  \\$1\\*(ql\(oq\c
..
.de q)
.chop qq
.am qq
\c
.qe
\&\\$1
\\..
.qq
..
.de qe
.ie \\n(ql%2 \(rq\\*(ql\\$1\c
.el  \(cq\\*(ql\\$1\c
.nr ql -1
..
.\" 
.q(
She said,
.q(
I think we're getting a little carried away
with the
.q(
nesting
.q) \^
.q) .
But I told her it's all the rage among Lisp
.q(
programmers
.q) .
.q)
.\" 


nestedquotes.pdf
Description: Adobe PDF document

Re: drawing requests following the line

[Tadziu Hoffmann]

> (Should we raise this issue again?  Nothing ever seems to
> get done no matter how much we discuss it.)

I think this is because it's not really something that many
users badly require.  (I certainly don't.)

Continuous underlining can probably only be done well by
treating it as a character attribute in the formatter and
passing it on to the postprocessor for execution
(like color, for example).

It might be possible to get a reasonably well working
implementation in a macro package by diverting the text and
inserting start/stop markers, and then trapping the formatted
text line-by-line and drawing the underlines.  I don't know
whether this extra effort is really worth it, and how well it
integrates into the rest of all the processing that the macro
package performs. (But ultimately, text hyperlinks in PDF
suffer from the same problem.)

Re: .CW usage by a new user

[Tadziu Hoffmann]

> I am translating to Spanish the book "Introduction to the command line"
> Attached is an image showing that I made it.

In your case you are intending those double quotes to directly
become characters in the output (as opposed to them being used
internally as delimiters for macro arguments).  In this situation
it may be helpful for possible future readers of your groff code
to actually insert them as "special" characters in your code,
i.e., instead of

  .CW "$ echo ""foo  bar"""

write

  .CW "$ echo \[dq]foo  bar\[dq]"

and use " exclusively as a macro argument delimiter.
(Then there should also be no problems if you later decide to
rewrite the .CW macro and make it pass its argument to still
another macro.)

(You are going to have to go through all of the example
command lines anyway and convert the quotes, so I don't
think this is going to be more work.)

Re: .CW usage by a new user

[Tadziu Hoffmann]

> .CW "this phrase is spicy with \[lq]Courier\[rq] powder" .

Also, within a double-quoted request or macro argument, you
can use a double double-quote to get a single double-quote
in the argument:

  .CW "| ` ' \[aq] \[lq] \[rq] \[dq] "" |"

but you'll only need this if you're typesetting computer code
like shell command lines (or you are writing macros that write
macros), in normal text \[lq] and \[rq] look much better.

Re: groff Digest, Vol 239, Issue 2

[Tadziu Hoffmann]

> Unfortunately pic chops broken lines into separate segments,
> so it can't directly fill general polygons.

But then again, the nice thing about pic doing this is that
its dashed lines always begin and end with a stroked segment.
Many programs don't get this right.

And the nice thing about using groff with the ps device is
that it makes it easy to add features not natively supported
by supplying the appropriate device code.  See the attached
example.  Of course this needs to be made configurable with
parameters to allow it to be used more generally, but for a
first start it's not bad.


.\" pic
.\" 
.po 2.5c
.ll 21c-5c
.sp 2c
.\" 
.de XX
ps: mdef 2
/blam!
{ 0 -25 moveto
  10
  { 18 rotate 0 -15 lineto 18 rotate 0 -25 lineto }
  repeat
  closepath
  gsave 1 1 0 setrgbcolor fill grestore
  [ 6 2.5 1.6922 2.5 4 2.5 1.6922 2.5 ] 3 setdash
  stroke }
def
/shift
{ currentpoint 2.2 sub translate }
def
..
.devicem XX
.PS
define blam { [
box width 0.5 invis "\X'ps: exec gsave shift blam! grestore'"
] }
box "foo"
arrow right
blam "bar"
arrow right
circle "baz"
.PE


pictest.pdf
Description: Adobe PDF document

Re: a boundary-pushing challenge for drawing commands

[Tadziu Hoffmann]

> How does the formatter know which parts to fill?

In the case of groff (I can't say anything about the original
troff), I don't think the formatter actually knows or cares,
but simply passes the path on to the device postprocessor,
which just incorporates it into the device-dependent output,
to be dealt with by the actual output device.

For Postscript, the Postscript Language Reference Manual
has a short description of how filling conceptually works
(Section 4.5.2, "Filling").  There's actually two different
algorithms that can be selected, "non-zero winding rule"
or "even-odd rule", which can give different results under
certain circumstances, such as self-intersecting paths or
paths consisting of multiple sub-paths.  However, in the
case of your bowtie, both render the same.

Re: a question of hyphenation policy

[Tadziu Hoffmann]

> > I believe distorting the shapes of letters is even more frowned
> > upon in typesetting circles than consecutive hyphenation is.
> 
> Tadziu, were you referring to your language (where I *think*
> hyphenation would always be necessary)?

Sorry if my wording was a bit vague.  I was referring to
hyphenation on multiple consecutive lines, which is sometimes
stated as something to avoid.  The point I was trying to make
is that multiple consecutive hyphenated lines is still often
the lesser evil compared to some of the proposed solutions.

Personally, I have no problems with consecutive hyphenated
lines at all, or even with hyphenating the last line of a page.

What I find much more jarring is letterspacing words just to
avoid larger interword spaces.  I find the latter acceptable,
but the former disruptive even at fairly small amounts.

Re: a question of hyphenation policy

[Tadziu Hoffmann]

> \s[-X]\H[+X]text to be kerned goes here\H[0]\s0

I believe distorting the shapes of letters is even more frowned
upon in typesetting circles than consecutive hyphenation is.

As a practical approach to manually optimizing the line
breaks in a paragraph, I have found that twiddling the space
size using .ss often leads to acceptable results.  Also,
using \p (or .brp) to break-and-stretch a line earlier in a
paragraph can sometimes lead to nicer line breaks later on
in the paragraph.

Re: a question of hyphenation policy

[Tadziu Hoffmann]

>  .hlm nSet the consecutive automatically hyphenated line limit
>to to n.  A negative value means "no limit".

What happens after that count is reached is that the next
line is stretched wide, simply to avoid hyphenation (unless
.na is used, in which case the line is simply broken short).
To me it sounds like this "solution" is worse than the
problem.  Without an optimizing paragraph-at-a-time algorithm
like TeX has, which can retry the entire paragraph with
different breakpoints, with roff's line-at-a-time approach
only human intervention can really help.

>  \n[.hlc]  Count of immediately preceding consecutive
>hyphenated lines in environment.
>
> My question is: should a page break reset this count?

If the register is made writable, this can be decided by the
macro package, by writing a zero to the register when a new
page is begun.

Re: Rendering the em dash on the terminal

[Tadziu Hoffmann]

I suspect conventions might be strongly regionally
dependent.

> - Em-dashes are represented by two hyphens with no space
>   either side--visually easy to understand.
>
> - En-dashes are represented by a single hyphen
>   surrounded by spaces (e.g. 2 - 3 minutes).

I believe this should be reversed -- 2 hyphens with spaces
for an em-dash, and 2 hyphens without spaces for an en-dash
(e.g., 2--3 minutes).  This not only follows typeset conventions
more closely, but it also indicates the intent to the typesetter
much better.  In addition, it corresponds to European practice,
where it is customary to use an en-dash surrounded by spaces
instead of the em-dash without spaces used in the US.

TeX's convention is also good and unambiguous, and I've
seen that being used in documentation as well:
  * one hyphen for hyphen or minus (depending on context)
  * two hyphens for an en-dash
  * three hyphens for an em-dash

> - All enumerators for lists (other than letters or digits) are
>   represented by a single hyphen followed by a space

Anything nicely symmetric works well, and allows visually
distinguishing between different list levels in addition
to list indentation.  (In earlier times when documents
such as manual pages were often printed on lineprinters
capable of overstriking, I've seen o-plus used.)

Re: magazine style end marks

[Tadziu Hoffmann]

> For a small fanzine project I want to typeset magazine
> style end marks [1]. Particularly I want to include the
> authors handle or name in the end mark, like seen for 
> instance in some articles like in this issue of the
> Space Gamer Magazine [2].

How about this (see attachment)?
It prints the partially collected line, and if there
was enough room for the end mark to fit, spaces up one
line again.  Then it prints the and mark right-adjusted.
This should be good enough unless you have extra tall
constructs with in the text.


.\"
.\" 
.ll 5c
.po 3c
.sp 3c
.\" 
.de Au
.gcolor red
.ta \\n(.luR
.ad l
\t\[em] \fI\\$1\fP
.ad b
.gcolor
..
.\" 
.de AU
.gcolor blue
.br
.ds XX "  \(em \fI\\$1\fP
.nr XX \w'\\*(XX'
.if \\n(.n+\\n(XX<\\n(.l .sp -1
.ad r
.nh
\\*(XX
.br
.ad b
.hy
.gcolor
..
.\" 
.de Tx
Either on the last line of the article, or \(em if that line is
too long to accomodate the end mark \(em on the following line.
..
.de Ty
So in any case the end mark should be flush right.
.Tx
..
.\" 
.Tx
.Au "The author"
.sp
.Tx
.AU "The author"
.sp
.Tx
.AU "The author with a very long name"
.sp
.Ty
.Au "The author"
.sp
.Ty
.AU "The author"


endmarks.pdf
Description: Adobe PDF document

Re: vim :hardcopy equivalent

[Tadziu Hoffmann]

> I will defend my formulation.  `sp` _does_ position the
> text baseline, period.

I concur.  It positions every part of the line.
I simply did not want anyone to get the impression that
".sp |3c" would put the _baseline_ at 3 cm from the top.

Also, in this case the baseline will only _normally_
be put at 3 cm + 1 vee.  If the line is overly tall
(i.e., extra line-space has been requested with \x),
then the baseline will be automatically shifted
downward by the corresponding amount.

(This is in contrast to Postscript or PDF, where a moveto
_does_ position the baseline for any text to be output,
regardless of the height of the text.)

> Where I, and apparently sometimes others, usually screw this
> up is when computing distances from the page _bottom_.

This unfortunately stems from the way traps are implemented
in troff.  The Troff User's Manual says

  The macro associated with a page trap is automatically
  invoked when a line of text is output whose vertical size
  reaches or sweeps past the trap position.

so that when you say ".wh -3c FT", when the FT macro is
invoked, the output (usually) has already intruded into the
margin of 3 cm and you can't do anything about it anymore.

I don't know whether it is possible (or desirable) to
modify the behavior so that the macro is invoked _before_
the line sweeping past the trap position is output, because
then the invoked macro needs a mechanism to deal with the
finished-but-not-yet-output line in addition to the usual
partially collected line.

My approach normally is to put the trap at -(margin+1v-1u)
and just hope that no over-tall line will be output as the
last line.

Re: vim :hardcopy equivalent

[Tadziu Hoffmann]

> > a "margin" measures an extent of whitespace (or "negative space"),
> > whereas the `sp` request positions the _text baseline_,

The first is correct and the second incorrect for [g]troff.
In troff (and nroff), if you say

  .sp |0

then this does not mean "put the baseline at the top of the page"
but rather "leave zero space above the text", and correspondingly

  .sp |50p

means "leave 50 pt of space above the text", as you would expect
for margins.  Thus, troff's model somewhat follows the concepts
of metal typesetting.

Of course, troff simplifies this a bit, in the first case by putting
the baseline at 1 vee below the top of the page, and in the second
case at 50 pt + 1 vee.

Groff enables you to follow the metal typesetting model more
closely, by allowing you to split the baseline distance into
".vs" and ".pvs".  Thus, to have a baseline spacing of 20 pt,
with 14 pt above the baseline and 6 pt below the baseline, say

  .vs 14
  .pvs 6

as demonstrated in the attached example.


.\"
.\" 
.gcolor green
.vs 0
.sp |0
\D'p 400p 0 0 50p -400p 0'
.sp |70p
\D'l 400p'
.sp |90p
\D'l 400p'
.br
.ps 18
.vs 20
.gcolor red
.sp |50p
The quick brown fox
.br
jumps over the lazy dog.
.br
.in 200p
.gcolor blue
.vs 14
.pvs 6
.sp |50p
The quick brown fox
.br
jumps over the lazy dog.
.br


margin.pdf
Description: Adobe PDF document

Re: Oversized Tables - how to produce non-truncated PDF?

[Tadziu Hoffmann]

> some of the huge tables which in my original sources spread
> over two book pages, appear truncated by the PDF, no matter
> what papersize I try to set (e.g. like A3).

The default column separation is 3 ens.  We can make the table
a bit narrower by reducing this to 2 ens,

  lb2 s2 s2 s2 s2 s2 s2 s2 s2 s2 s2 s2 s2 s2 s2 l

and then the table does fit within the width of A3 landscape,
as the attached example shows.

(This was formatted with mm which supports multi-page tables
with repeated headers.  I also messed with the vertical
spacing around the horizontal lines a bit.  I first tried
to add .sp requests before and after the horizontal lines,
but then the last line that should have been on the bottom
is always pushed to the next page.  So I gave up and added
extra-linespace requests using \x instead.)




1985_1006_Politbuero.pdf
Description: Adobe PDF document
.\" tbl a3 land
.\" 
.\" vim:syntax=groff
.\"
.\" 1985_1006_Politbuero.tbl
.\"
.\" Oliver Corff, 2020-04-03
.\"
.\"
.\"
.\" .so ../Pool/0_Definitionen.roff
.\" fam H
.nr L 29.7c
.nr W 42c-4c
.nr O 2c
.mso m.tmac
.ds pg*header ''\(en \\nP \(en''
.ps 10
.vs 12
.TS H
expand nospaces tab(|) decimalpoint(,);
lb2 s2 s2 s2 s2 s2 s2 s2 s2 s2 s2 s2 s2 s2 s2 l
l  s l l l c s l l l l l l l l l
l  s l l l c s l l l l l l l l l
r  l l l l l l l l l l l l l l l.
\x' 2.5p'Politb\[:u]ro des ZK der SED\fR  (Neu zusammengestellt von Bernd 
Niedbalski) | Stand August 1984
_
\x'-2.5p'Mitglieder |Geb.-|Partei-  |Partei- |Politb\[:u]ro 
   |ZK-Sekretariat   |Wichtige  |Ministerrat|Nat. Vert.-
|Staatsrat  |Volkskammer|Massenorganis. |FDJ-Hintergrund|Bildung
|Jahr |zugeh\[:o]rigkeit|eintritt|ZK
   |Funktion |Parteifunktionen  |   |Rat
|   |   |   |Zentralrat
\x' 2.5p'  || | ||Kandidat  
|Mitglied  |seit |z. Z.
_
.TH
\x'-2.5p'1.|Honecker,   |1912 |KPD  |1929|1950  |1958   
   |Generalsekr. 1976|  |   |Vorsitz 1971   
|Vorsitz 1976   |Abg.   |   |FDJ-Vorsitz|Dachdecker
   |Erich   | | ||  |PV/ZK 
1946|Erster Sekr. 1971|  |   |Sekr. 
1960\-71 |Mitgl. 1971|   |   |1946\-55   
|1955/56 PHS KPdSU
\x' 2.5p'  || | ||  |   
   |Sekr. 1958
_
\x'-2.5p'2.|Axen,   |1916 |KPD  |1942|1963  |1970   
   |Internat. Verbind.   |  |   |Mitglied   
|   |Abg.   |Mitgl. Zentr.ltg.  |ZR-Sekr.   
|Realgymnasium
   |Hermann | | ||  |ZK 
1950   |1966 |  |   |   
|   |Vors d. Aussch.|u Pr\[:a]s d. Kom. |1946\-49   
|Journalist
   || | ||  |   
   |Agitprop 1950\-53|  |   |   
|   |f. Ausw. Angel.|d. Antifasch.
   || | ||  |   
   | |  |   |   
|   |   |Widerstands-
\x' 2.5p'  || | ||  |   
   | |  |   |   
|   |   |k\[:a]mpfer
_
\x'-2.5p'3.|Dohlus, |1925 |KPD  |1946|1976  |1980   
   |Parteiorgane 1973|ZK-Abt.-Leiter|   |   
|   |Abg.   |   |   |Friseur
   |Horst   | | ||ZK 1950   |ZK 
1963   |Mitgl. d. Sekr.  |Parteiorgane  |   |   
|   |   |   |   
|1954/55 PHS KPdSU
\x' 2.5p'  || | ||  |   
   |1971\-73
_
\x'-2.5p'4.|Felfe,  |1928 |KPD  |1945|1973  |1976   
   |Landwirtschaft   |  |   |   
|Mitgl. 1981|Abg.   |   |2. ZR-Sekr.
|Ind.-Kaufmann
   |Werner  | | ||ZK 1954   |ZK 
1963   |1981 |  |   |   
|   |   |   |1954\-57   |1953 
PHS SED
   || | ||  |   
   | | 

Re: vertical spacing trivia challenge

[Tadziu Hoffmann]

[Spoilers ahead.]

> A   Question: is the `vs` request (which sets the vertical spacing)
> honored in nroff mode?

Yes.

> B.  In nroff (or nroff mode in groff), what _units_ is the argument
> to the `vs` request reckoned in?

I remember .vs always being given in points, with a default value of
12 pt, resulting in 6 lines per inch, or 66 lines per 11-inch sheet.

(I know this because I have set my terminal windows to a height of
67 lines, in order to display manual entries paginated for 11-inch
fan-fold line printer paper one page at a time, with an additional
line for the "less" prompt.)

Empirical tests with groff support this.  However, groff appears to
round different values for .vs immediately to a multiple of 12 pt,
and then consistently use that rounded number.  E.g.,

  echo -e '.sp 12p\n.nf\n.vs 6\na\nb\nc\nd' | nroff | less

only shows "d", i.e., 6 gets rounded down to zero.

[This is in contrast to a conceivable different model, in which
groff might internally keep a higher-resolution line tally, and
output a linefeed only when this surpasses the next grid position.]

> C.  A point is less than a vee, right?

Usually, but the vee can also be set to zero for special
formatting purposes.

> D.  What does nroff do if you request to alter the vertical
> spacing in points?

Not sure what is meant here.  I think it is always in points.
Or do you mean, if different values than the default are
requested?  Then, see above.

> E.  Attempt to address the foregoing questions empirically.
> Compare the results to the claims of CSTR #54.
> Do they agree?

[Now browsing CSTR #54...]
I can't see anything beyond it stating that the default scale
indicator for .vs is points, and that nroff rounds numerical
input to the actual resolution of its output device.
So I would say yes, they agree.  :-)


However: I remember Unix nroff also supporting terminals with
half-line capability, which groff doesn't.  Maybe someone here
has an old system they can use to test nroff's behavior when
formatting for one of these terminals?

Re: On the term "justification"

[Tadziu Hoffmann]

> [2] Maybe introducing a replacement term, "rotated"--which is
> unused in the GNU pic manual except to define "aligned"--would
> be a good idea [...]

I don't think this is a good idea.  "aligned" in pic means
the direction of the text is aligned with the direction of
the object:

  .PS
  arrow right "aligned" "" aligned
  arrow down  "aligned" "" aligned
  .PE

means the text is horizontal in the first case, vertical
in the second.

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

[Tadziu Hoffmann]

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

> > Be nice to include that.

Wikipedia has an SVG of the logo, but it's a bit asymmetric.
Instead of trying to fix it I decided to draw a new one,
based on a bitmap image I found on the web.

This one is in Postscript and it doesn't set the color, so
in principle you can have it drawn in any color you like by
setting the color before including the graphic with "ps: import",
*if* you comment out the "0 setgray" in PBEGIN in the grops prolog.
Or you do the work of "ps: import" yourself using "ps: exec" and
"ps: file", as in the attached example, in which case no change
to the grops prolog is necessary.




Bell-Logo-1969-rounded.ps
Description: PostScript document


Bell-Logo-1969.ps
Description: PostScript document
.\"
.\" 
.po 3c
.ll 21c-6c
.sp 3c
.defcolor Bellblue rgb 0 0.6 1
This is the Bell logo
\m[Bellblue]\v'0.25m'\
\X'ps: exec gsave currentpoint translate 12 1000 div dup neg scale /showpage { 
} def'\
\X'ps: file Bell-Logo-1969-rounded.ps'\
\X'ps: exec grestore'\v'-0.25m'\h'12p'\m[]
from 1969.


Bell-logo-test.pdf
Description: Adobe PDF document

Re: *roff hyphenation trivia challenge

[Tadziu Hoffmann]

> Which would be better?
> 
> 1.  Change GNU troff to not write out a hyphen if the
> hyphenation control escape sequence is at the end
> of the word.
> 
> 2.  Change GNU troff to not reënable automatic
> hyphenation after encountering a non-initial
> hyphenation control escape sequence in a word.

I think 1 is impractical.  I favor 2, and I have the feeling
that groff's current behavior wasn't intended.  I think the
simple rule "if the word contains one or more occurrences of
"\%", then hyphenation is allowed exclusively at these points"
is easier to follow and remember.

Here's another empirical observation:
Suppose we have an "enquote" macro,

  .de QQ
  \(lq\\$*\(rq
  ..

and we want to suppress hyphenation in the quoted word,
then both

.QQ \&\%antidisestablishmentarianism

and

.QQ antidisestablishmentarianism\&\%

work, but the "\&" is needed in both cases.




> reënable

Nice!  Like "coördinates".

Re: *roff hyphenation trivia challenge

[Tadziu Hoffmann]

> $ printf '.ll 8n\n\\%%antidisestablishmen\\%%tarianism\\%%\n' \
>   | nroff -Wbreak | cat -s
> antidisestablishmen-
> tarianism-
> 
> I don't think we can tolerate that trailing hyphen.

Yes, that's why we have to use "\&\%" at the end.

Re: *roff hyphenation trivia challenge

[Tadziu Hoffmann]

> Groff already *does* ignore correct hyphenation points,
> namely before the first "\%" (but allows them afterward).
>
> My concern is that if "\%" only allows specifying
> *additional* hyphenation points, then we have no method
> of forbidding hyphenation points that the patterns
> incorrectly allow.

I'm revising my empirical description of groff's behavior.

Groff allows normal hyphenation after the *last* "\%" in
the word.  Thus, if we end the word with "\&\%", it has the
effect of only allowing hyphenation at any of the "\%" given.
(If the word contains no "\%" other than the trailing "\&\%",
the effect is the same as preceding the word with "\%", i.e.,
hyphenation is suppressed in this occurrence of the word.)

The behavior feels weird, but I'm satisfied that my
requirements can be fulfilled using this trick.

Re: *roff hyphenation trivia challenge

[Tadziu Hoffmann]

> I prefer groff's behaviour because I don't ever want correct
> hyphenation points to be ignored. Using \% is almost always a
> correction to the hyphenation logic.

Groff's current behavior is weirdly inconsistent.
It already *does* ignore correct hyphenation points,
namely before the first "\%" (but allows them afterward).
Except if the word *starts* with "\%" and does not contain
any other "\%", in which case hyphenation is entirely
suppressed in the whole word.

My concern is that if "\%" only allows specifying
*additional* hyphenation points, then we have no method
of forbidding hyphenation points that the patterns
incorrectly allow.  (Unless you count weird tricks like
inserting "\h'0p'" that could mess with the kerning.)

Re: *roff hyphenation trivia challenge

[Tadziu Hoffmann]

> > Also interesting to see that in this word, the hyphenation
> > patterns don't suggest a hyphenation opportunity after "anti".

> The leading `\%` prevents that.

Sorry, I meant even without "\%".  With a line length of 1 en,
and without any "\%" at all, groff prints

  an-
  tidis-
  es-
  tab-
  lish-
  men-
  tar-
  i-
  an-
  ism

and Heirloom troff prints

  an-
  tidises-
  ta-
  blish-
  men-
  tari-
  an-
  ism

TeX gives the same as groff since it uses the same
hyphenation patterns (groff borrowed them from TeX).

For "antidisestablishmen\%tarianism", groff prints

  antidisestablishmen-
  tar-
  i-
  an-
  ism

(which I think is strange), while TeX and Heirloom troff print

  antidisestablishmen-
  tarianism

which I think is the only reasonable way of handling this case.
(I remember in Word it was only possible to add additional
hyphenation points, but not to inhibit existing ones, which
is a terrible idea if one of the builtin ones turns out to
be wrong.)

For "\%antidisestablishmen\%tarianism", Heirloom troff does not
hyphenate at all (even if the word contains additional "\%"),
whereas groff and TeX do the same as they did with only the
inner "\%".  (Also, "\&" is not a letter, so a leading "\&"
should not influence hyphenation at all.)

With *only* the leading "\%", ("\%antidisestablishmentarianism"),
none of the formatters hyphenates, which is correct.

Of the three formatters, TeX's behavior appears to be the most
sensible to me, i.e., if the word contains one or more "\%",
*only* those points (but all of them) will be considered
for hyphenation.

Re: *roff hyphenation trivia challenge

[Tadziu Hoffmann]

> Predict the output of the following *roff input.
> [...]

I guessed wrong.  And Heirloom nroff behaves differently
from groff.  Some more unexpected behavior can be seen
by shortening the line length to just 1 en.

I also tried the same thing in TeX and learned that by
default TeX doesn't hyphenate the first word of a paragraph.
(I didn't know this before, but I also never yet had to deal
with a document where this was necessary.)

Also interesting to see that in this word, the hyphenation
patterns don't suggest a hyphenation opportunity after "anti".

Re: the Courier font family and nroff history

[Tadziu Hoffmann]

> (I use a bitmap font because it's substantially more readable
> for long periods of time than any TrueType font I've found at
> equivalent sizes, but using a bitmap font disables some of
> xterm's font family support.)

The xterm source can be hacked to provide italics using the
classic bitmap fonts (see attached image).
[My mod is most certainly incomplete and/or partially wrong
since I did not embrace the full complexity of xterm's
configuration options, but it works for my limited use case.]

As a side note, I find that for reading documentation, color
is more helpful than italics alone.  You can achieve this
either using the xterm resources colorBDMode & colorBD and
colorULMode & colorUL (or possibly colorITMode & colorIT)
or, if you only need this within "less", by using
"traditional" backspace highlighting with grotty:

  export GROFF_NO_SGR=yes

and setting

  export LESS_TERMCAP_md=$'\E[1m\E[34m'
  export LESS_TERMCAP_us=$'\E[3m\E[31m'
  export LESS_TERMCAP_ue=$'\E[23m\E[39m'

to make "less" generate the terminal control sequences
instead of grotty.

Re: Accent mystery

[Tadziu Hoffmann]

> However, pdfmom is supposed to accept all the same
> options as groff.  Here, it does not, since "-Kutf8 -k" is
> acceptable to groff.
> 
>   groff -Tpdf -Kutf8 -k -mom timeline.mom > timeline.pdf
> 
> works but
> 
>   pdfmom -Kutf8 -k timeline.mom > timeline.pdf
> 
> fails.

In the perl script, both "-k" and "-K" options _assign_ the
$preconv variable (which ultimately gets passed to groff),
so the second overwrites the first, leading to the encoding
info "utf8" getting lost.

However, "-Kutf8 -k" feels unnatural to me, whereas "-k -Kutf8"
feels reasonable.  If pdfmom was only tested with the latter
order of options, it would not have been noticed that "-k" got
lost, because it would be implied by groff seeing "-K".

I guess the simplest fix would be to have pdfmom _append_ the
"-k" and "-K" options to $preconv, i.e., replacing

  $preconv=$c;

by

  $preconv.=' '.$c;

at all three occurrences (the space makes sure the option strings
don't run together).  But I have very little experience with
perl, perhaps a cleaner solution exists.

Re: Accent mystery

[Tadziu Hoffmann]

> Processed with
>   pdfmom -Kutf8 -k  timeline.mom > timeline.pdf
> the é is garbage.

If I swap the order of the options:

  pdfmom -k -Kutf8 timeline.mom >timeline.pdf

or leave out the "-k" entirely (since it is implied by "-K"):

  pdfmom -Kutf8 timeline.mom >timeline.pdf

it works on my machine.

Re: Proposed: make \X read its argument in copy mode

[Tadziu Hoffmann]

> > \fB\s(12\m[red]\X'ps: big bold red text in my device command'\fP

> \X'ps: exec 1.0 0 0 setrgbcolor /Times-Bold findfont \n[.s] scalefont setfont 
> (Text) show'

This assumes you know both the desired font and the desired
color, which might be defined at other places in the document
and not under your control.  Thus, unless you need multiple
colors/fonts/sizes within the device code, it is probably more
practical to set theses outside, as in Branden's original sketch.

Here is a possibly useful example:

  .defcolor my-outline-color rgb 0.9 0 0.7
  .fp 4 BI LinLibertineOBI
  .\" 
  .de outline
  \Z'\N'32''\X'ps: exec \\n(.s 0.01 mul setlinewidth (\\$1) true charpath 
stroke'\h'\w'\\$1'u'
  ..
  .\" 
  Here is some
  .gcolor my-outline-color
  .ft BI
  .outline outlined\/
  .gcolor
  .ft
  text.

(Note that this code is not optimal, in particular because
grops does not set the font unless it is outputting something,
necessitating the hack of printing an explicit space with
\N'32' in order to get grops to set the desired font.)




outlined.pdf
Description: Adobe PDF document

Re: the 'SS' (slanted symbol) font (was: Original print of V7 manual? / My own version of troff)

[Tadziu Hoffmann]

> For people producing greek documents who wish to use eqn,
> I did some testing, using the Tinos family of fonts (R, I,
> B, BI) which include greek glyphs and SS font for gropdf.
> The attached pdf shows the results with the different
> fonts colour coded.

Nice!  How did you do the color coding?

> If you want to see the slanted versions for alpha and beta,
> it is best to set the family to T and select TinosR as the
> main font.

But this gives you the Greek characters of the Symbol font.
Since Tinos also has Greek characters, it would be nice to
use the italic Tinos Greek for the math.  Could you maybe
try the trick of telling eqn

  chartype "letter" \[*a]\[*b]\[*g]\[*d]\[*e]\[*z]
  chartype "letter" \[*y]\[*h]\[*i]\[*k]\[*l]\[*m]
  chartype "letter" \[*n]\[*c]\[*o]\[*p]\[*r]\[*s]
  chartype "letter" \[*t]\[*u]\[*f]\[*x]\[*q]\[*w]

at the beginning (in the first EQ/EN pair)?



Attached is my own experiment of using a different Greek font
(GFS Didot) for the math.  Unfortunately I do not speak Greek,
so I have no idea whether the text is typeset correctly,
but I think the Greek typeface looks very nice.

I did the color coding by inserting color commands into
the intermediate output wherever a font change occurred.
The colors are:

  red:   Roman
  blue:  Italic
  green: Symbol

(The fraction bar is not from a font, but drawn as a line
while the blue color was active.)




greek.pdf
Description: Adobe PDF document

Re: the 'SS' (slanted symbol) font (was: Original print of V7 manual? / My own version of troff)

[Tadziu Hoffmann]

> The ordering of the S and SS fonts is immaterial here because
> the C/A/T _had_ no SS font.
> Nor do I see any of evidence of an "SS" font for _any_ device
> in Documenter's Workbench 3.3 troff.
> Barring evidence of pre-groff usage, then, I submit that the
> slanted symbol font must be a groffism.

No disagreement here.  Neither the C/A/T nor the APS 5 had an
SS font.  But both had a symbol font containing upright Greek
capitals and slanted Greek lowercase letters, specifically
intended for typesetting mathematical expressions
(based on a century of established mathematical typesetting
conventions[*]).

The SS is a groffism introduced to replicate this behavior
in a compatible manner without having a symbol font with
the above properties, in such a way that eqn could simply
request \(*A or \(*a and troff would automatically provide
the correct character.

[*](I'm wondering whether these conventions might not have had
much older roots, namely in the fonts (Garamond, Didot, Porson)
historically used to typeset some of the Greek classics,
which similarly had "roman" uppercase and "italic" lowercase
Greek letters.)


> > and nothing needs to be changed.

> I disagree, because nroff output is incorrect, failing to render
> lowercase Greek letters in italics when troff output _does_.

I see.  Since groff does not provide a usable neqn, I had never
considered using groff for typesetting math for the terminal.
(But see below.)


> sin ( 2 theta ) ~ = ~ 2 ~ sin theta cos theta
> (Note to self: an eqn full space should render as a space on
> nroff devices.  File a bug.)

No bug, simply "set thick_space 100" in eqnrc for the terminal
devices.

In addition to this, I'd suggest not to habitually try to
override the default spacing rules of eqn,

  sin ( 2 theta ) = 2 sin theta cos theta

since eqn already inserts thick_space around relations.


> Further, nothing in eqn documents its sensitivity to the font
> mounting order when determining the typefaces to be used.
> In fact that sensitivity overrides explicit configuration!

I'd assume this is a good (= flexible) thing.  Eqn requests
character "\(*h" (= theta), and troff provides this, from
whatever font the user has supplied that contains this
character.


> .\" "letter" means "slanted" in GNU eqn
> .\" This is actually redundant with the default configuration.

  .EQ
  chartype letter \(*h
  sin ( 2 theta ) = 2 sin theta cos theta
  .EN
  \(*h

Interestingly enough, the "chartype letter \(*h" is already
sufficient to switch the thetas from eqn into italic (or
rather, underlined) on my terminal, while the \(*h from the
last line remains normal, i.e., this simple change already
achieves what your proposed modification is meant to do.  (?)

(I assume this is because on the utf8 device, the theta is
provided by a normal text font, whereas in the postscript
device it comes from the special font.)


> >   1-4: R, I, B, BI(standard text fonts)
> >   5:   CW (computer/monospaced)
> >   6-9: SS, S, ZD, ZDR (special)

> Heavens no!  "CW" is a System-V-ism.  We have CR, CI, CB, and CBI.

Yes, but it explains why there are 5 empty positions in the
"fonts" declaration before SS, S, ZD, and ZDR.  :-)

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

[Tadziu Hoffmann]

> Note that there is no SS for 'devpdf'. So, from where does
> -Tpdf find (or construct) the slanted versions of the Greek
> letters if the standard symbol font has upright Greek letters?
> Or are the two 'S' fonts different for -Tpdf and -Tps?

In the current groff release, the slanted Greek characters
are constructed from the characters in the standard Symbol
font using .char in pdf.tmac:

  .char \[*a] \S'16'\[*a]\S'0'
  (etc.)
  [note special anti-recursion feature of .char]

but since the font metrics are not adapted this has some
spacing issues.

For the upcoming release I believe Deri has provided a real PFB
font file containing the slanted font plus the corresponding
font metrics file "SS" which will resolve these issues.
(Discussion on this list from June 2023.)

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

[Tadziu Hoffmann]

[Redirected to the list, since I believe it is of general interest.]


> > Which character (slanted or upright) groff uses simply depends
> > on the mounting order of the fonts S and SS.
> > 
> > [...]


> I never knew this.  Where is the reference please?
> I would like to mention this in my new EQN manual.

The Troff User's Manual (section 2, "Font and Character Size
Control") says:

  The troff character set is defined by a description file
  specific to each output device.  There are normally several
  regular fonts and one or more special fonts.

  Troff begins execution by reading information for a set of
  defaults fonts, said to be mounted; conventionally, the first
  four are Times Roman (R), Times Italic (I), Times Bold (B),
  and Times Bold Italic (BI), and the last is a Special font (S)
  containing miscellaneous characters.  The set of fonts and
  positions is determined by the device description file.

  It is not necessary to change to the Special font;
  characters on that font are automatically handled as if
  they were physically part of the current font.  The Special
  font may actually be several fonts; the name S is reserved
  and is generally used for one of these.  All special fonts
  must be mounted after regular fonts.

However, it does not explicitly say that the special fonts
are searched in mount-position order.  (I think it is a
reasonable assumption, but I may be biased.)

The groff Info file (section 5.17.4, "Using Symbols") is more
specific:

  Here are the exact rules how 'gtroff' searches a given symbol:

   [... current font and explicit declarations using
 .char and .fspecial ...]

   * As a last resort, consult all fonts loaded up to now for
 special fonts and check them, starting with the lowest
 font number.  [...]

Since both S and SS contain lowercase Greek characters, placing
SS before S will result in gtroff picking the slanted alpha for
\(*a, whereas placing S before SS with pick the upright alpha.
(Unless of course the current font also contains a \(*a character,
in which case this will be used, or any other font declared
as special and containing \(*a is mounted before S and SS.)


> As far as I knew, there are no default fonts for 1-5 but
>
>   .fp 6 S
>   .fp 7 SS
>
> was the default as per DESC.

A reasonable default would be:

  1-4: R, I, B, BI(standard text fonts)
  5:   CW (computer/monospaced)
  6-9: SS, S, ZD, ZDR (special)

but this is simply convention, it is not hardcoded into groff
(and can be modified by specifying a different DESC file with a
different setup via the GROFF_FONT_PATH environment variable).

I believe the leading empty positions in the "fonts" declaration
of groff's DESC files are related to groff's extension using
"styles" and "family", which the original troff did not have.


> Where goes groff and eqn configure their font positions?

eqn itself doesn't set up any fonts, it simply requests fonts by
name or number (as specified by "gfont", "grfont", and "gbfont",
by default "I", "R", and "B", and maybe overridden by eqnrc or the
document itself) and characters by name (via builtin translation
tables or as declared via "define": "alpha" --> "\(*a" etc.).

Troff tries to satisfy these requests using the fonts it has
available/mounted, by default those from the device description
file DESC, possibly modified by troffrc (and whatever this in
turn reads), the macro package, and the document itself.

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

[Tadziu Hoffmann]

> AT&T troff was engineered around the assumption that the
> lowercase Greek letters typically used for mathematical and
> scientific typesetting are slanted/italic rather than upright.
> This assumption is baked into the semantics of special
> character names *a, *b, *g, and so forth.
> [...]
> If you couldn't guess, I plan to change this in groff.

It is not, and nothing needs to be changed.

Which character (slanted or upright) groff uses simply depends
on the mounting order of the fonts S and SS.

Example:

  .fp 5 S
  .fp 6 SS
  \(*A\(*a --> upright lowercase alpha.
  .fp 5 SS
  .fp 6 S
  \(*A\(*a --> slanted lowercase alpha.

Re: gpic and 8-bit characters (was: Proposed GNU troff behavior change: require end-of-input macros to exit)

[Tadziu Hoffmann]

> > So because both being above ASCII (8 bit area),

> ASCII is not an 8-bit code.  It is a 7-bit code, [...]

Latin-1 is a superset of ASCII, with ASCII occupying the lower
half, so technically I would argue that the above statement
"being above ASCII" (namely, being in the area where the
eighth bit is set) is correct.  :-)

Re: Regarding groff, soelim, and macros

[Tadziu Hoffmann]

> Can we create documents that have chapters, sections,
> that are in separate files? How can we do this?

Use the method you already described that works: source the files
directly from the main document, not from within a macro.


> Now if I run this main file using
> (cat main.tr | groff -p -s > main.ps)
> I get the document with the picture.
> But if I instead uncomment the source macro and call this
> macro (.source ch1.tr) instead of (.so ch1.tr), it fails with
> (soelim:stdin:2: can't open '\$1': No such file or directory).

soelim and the other preprocessors run *before* troff (see the
pictures in the soelim manual page), i.e., *before* your macro
is evaluated.[*]  This means that:

 1. when soelim runs, the only line it sees is ".so \\$1",
which it can't really process because you (probably)
do not have a file called "\$1".

 2. when troff runs, all the preprocessors have already
finished, so that when troff evaluates your macro,
the requested file *will* sourced, but it will *not*
be preprocessed.

The only way to achieve what you want from within a macro at
troff runtime is to use the "sy" (system) request to execute a
shell command that runs the required preprocessors on the file
and redirects the output to a temporary file, which you can
then source.  But this opens up an entirely new can of worms.



[*] To see in detail how the files are transformed, try the
following series of commands and examine the temporary files:

  soelim tmp1
  pic tmp2
  tbl tmp3
  eqn tmp4
  troff tmp5
  grops main.ps

Re: inconsistent behavior of eqn bar operator

[Tadziu Hoffmann]

> If you put a bar over a string of As, the length of the bar increases
> by the same amount for every A you add, but that amount is not the
> length of a bar over a lone A.
> This nonuniformity is unfortunate.

This appears to be by design.  The manual page says:


  accent_widthWhen bar or under is applied to a single
  character, the line will be  this  long.
  Normally,  bar  or under produces a line
  whose length is the width of the  object
  to  which  it  applies; in the case of a
  single character, this tends to  produce
  a line that looks too long.

Re: Leaders

[Tadziu Hoffmann]

> The example was enormously helpful.  There's light at the end
> of my TOC multi-line entry tunnel.

Happy to be of help!  Note that the example was simplified to
illustrate the principle, and would need some (minor) aesthetic
tweaks for practical application.  Most importantly, you will
want the leaders of different TOC entries to align vertically:

  .de PG
  \\a\\t\\$1
  .br
  .di
  .in
  .ll
  .nf
  .ta \w'\\$1'u%\w'\(LC'u+\\n(.lu-\w'\\$1'u-\w'\(LC'u \\n(.luR
  .XX
  ..

(and if you're using different fonts/sizes, making sure the
leaders are always the same width).




leaders.pdf
Description: Adobe PDF document

Re: Leaders

[Tadziu Hoffmann]

> Rare?  Maybe.  But not so rare that a macro package need not
> be prepared for it.

I think leaders are meant to be used in conjunction with
diversions.  When they are used in already formatted text,
all required dimensions are known, allowing n/troff to
compute the number of leader character repetitions plus any
possibly required additional space.  See the attached example.
Note that "\t" has one backslash, so it is evaluated as a
tab while the diversion is being set up (the input is the
"input line"), but "\\a" has two backslashes, so the leaders
are applied when the diversion is output to the page (the
formatted content of the diversion is the "input line").


.\"
.\" 
.ll 16c
.po 2.5c
.char \(LC .\h'1m'
.lc \(LC
.\" 
.de CH
.ll -10n
.in 6n
.ti -6n
.ta 6n
.fi
\\$1.\t\c
.di XX
..
.\" 
.de PG
\\a\\$1
.br
.di
.in
.ll
.nf
.ta \\n(.luR
.XX
..
.\" 
.sp 2c
\D'l \n(.lu 0'
.br
.CH 14
The Laureate Is Exposed to Two Assassinations of Character,
a Piracy, a Near-Deflowering, a Near-Mutiny, a Murder, and
an Appalling Colloquy Between Captains of the Sea,
All Within the Space of a Few Pages
.PG 222

Re: Footer trap in a A4 PDF

[Tadziu Hoffmann]

> A slight change and you can colour the margins with pure troff
> so it works for both postscript and pdf:-

Very good!  Your example also demonstrates how setting the
vertical spacing to zero allows directly positioning the baseline
(which is the reference position for "\D" drawing commands)
with ".sp" requests, without having to add "-1v".

Re: Footer trap in a A4 PDF

[Tadziu Hoffmann]

> How should I proceed to achieve precise margin sizes?

There's two things to consider here.  One: the trap is sprung
when a line is output that reaches OR SWEEPS PAST the trap
position.  If you set your trap at -2 cm, then an output
line may nevertheless still intrude into the bottom margin
of 2 cm.  Unless you have over-tall lines, this will usually
be not more than the baseline distance of the running text.
If you want to keep the bottom 2 cm of the page free of text,
then it may be a good idea to set the trap at -2c-1v.

Two: if your footer macro just outputs the footer line without
doing anything else, then the position of the footer line WILL
DEPEND ON where the last line of text had been output, and thus
may vary from page to page.  To keep the footer line always
in the same position, have the footer macro space absolutely
to the desired position before outputting the footer line.

Also, if the footer (and header) lines should be output in a
different font, size, or color, it is best to reserve a separate
environment for the headers and footers, in order to minimize
interactions with the running text.  E.g., you might use

  environment 0: normal running text
  environment 1: headers and footers
  environment 2: footnotes

I have attached a demonstration file you can use for experimenting.
(I have used 3 cm margins for this.  Coloring the margins with XX
(for debugging purposes) only works with the PS device; you can
safely remove this.)


.\"
.\" 
.pl 29.7c
.po 2.5c
.ll 16c
.lt 16c
.\" 
.ev 1
.ll 16c
.lt 16c
.gcolor blue
.ft 2
.ev
.\" 
.de HD
.ev 1
\Y[XX]
.sp |1.5c-1v
.if o .tl '\\*[RH]''%'
.if e .tl '%''\\*[LH]'
.tl ''\v'-0.5v'\D'l \\n[.lt]u 0'''
.sp |3c
.ev
..
.de FO
.ev 1
.sp |29.7c-1.5c-2v
.tl ''\D'l \\n[.lt]u 0'''
.if o .tl '\\*[RF]''%'
.if e .tl '%''\\*[LF]'
.bp
.ev
..
.ds RH right header
.ds LH left header
.ds RF right footer
.ds LF left footer
.wh 0 HD
.wh -3c-1v FO
.\" 
.de XX
ps: exec
gsave 72 2.54 div dup scale 1 .9 .8 setrgbcolor
0  0   21  3 rectfill
0 29.7 21 -3 rectfill
grestore
..
.\" 
.ft 3
5.2. Extra line-space.
.ft
.de ZZ
.sp .5
If a word contains a tall construct requiring the output line
containing it to have extra vertical space before and/or after it,
the extra-line-space function x'N' can be embedded in or attached
to that word.
If N is negative, the output line containing the word will be preceded
by N extra vertical space; if N is positive, the output line containing
the word will be followed by N extra vertical space.
If successive requests for extra space apply to the same line, the
maximum values are used.
The most recently utilized post-line extra line-space is available
in the .a register.
..
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ
.ZZ


footer.pdf
Description: Adobe PDF document

Re: Footer trap in a A4 PDF

[Tadziu Hoffmann]

> I would expect the word "footer" to pop up at -2c from the page bottom,
> then a page break. Footer does pop up, and there's the page break too,
> however it does not show up at -2c from the bottom. It's lower.

It is working as intended.  When you say ".sp |0c" in troff,
that does not mean that the baseline will be at 0 cm, but
rather the "top of the text" will be at 0 cm.  Think of it
as an approximation to lead typesetting, except that in
troff the baseline will be set 1v below the specified point
(i.e., one whole baseline distance, and not some fraction of
the total line height as it would be in real lead typesetting).

You may set the baseline separation to zero with ".vs 0", but it
is best to do this in a separate environment, in order to avoid
messing up the running text.

Re: Weird in-line trivial EQN issue with 1.22.4 - bad font number

[Tadziu Hoffmann]

> > It's an issue with eqn material inside a macro definition.
> > To avoid expanding eqn-generated escapes at macro definition
> > time, bracket the macro definition with ".ec #" (or some other
> > unused character) and ".ec" (to restore backslash as the escape
> > character after the macro definition).  This way, backslashes
> > are retained in the macro and escapes are only evaluated at
> > macro expansion time.

> If this problem is not only in-line EQN code but also .EQ/.EN code,

EQ/EN and in-line eqn code are identical.

> then it would seem to me that any EQN code inside a groff/troff
> macro is to be avoided. Anything else seems like a recipe
> for disaster.

Not at all.  One only has to understand what causes these
issues and then handle them appropriately.

Normally, one would double all backslashes inside a macro
definition because escapes are also evaluated at macro definition
time (copy mode).  Each double backslash is interpreted as a single
backslash inside the macro, so that the "real" interpretation
of the escapes is delayed until macro expansion time (when the
macro contents are re-read and all still existing escapes are
re-interpreted).

However, eqn doesn't have a "double all backslashes" option to
be used inside a macro definition (and even if it did, how would
eqn know which code is in a macro and which isn't, without doing
all the work that troff does?).

The solution is to not interpret backslashes at macro definition
time.  This is achieved by declaring a different character[*] to
be used as the escape character before defining the macro, and
reinstating backslash as the escape character after the macro
definition(s).

This approach can also be used independently of eqn if you
simply want to avoid all the backslash-doubling hassle while
defining macros.

Obviously, when using this approach to deal with eqn code
inside macros that also contain other escapes, you must not
double the other non-eqn backslashes in the macro either.
On the other hand, sometimes you *do* want escapes to be
evaluated at macro read time (e.g., converting \t to a tab),
in which case you would have to use the new escape character
instead of the backslash.


[*] I recommend ascii BEL = control-G because it is unlikely
to be used elsewhere in the manuscript.

Re: Weird in-line trivial EQN issue with 1.22.4 - bad font number

[Tadziu Hoffmann]

It's an issue with eqn material inside a macro definition.
To avoid expanding eqn-generated escapes at macro definition
time, bracket the macro definition with ".ec #" (or some other
unused character) and ".ec" (to restore backslash as the escape
character after the macro definition).  This way, backslashes
are retained in the macro and escapes are only evaluated at
macro expansion time.

Re: Weird in-line trivial EQN issue with 1.22.4 - bad font number

[Tadziu Hoffmann]

>   .EQ
>   delim ##
>   .EN
>   [] which will not fit into the #p# bits
> 
> which breaks 'groff' with 'bad font number' messages.

I can't reproduce this, it works as intended on my machine.
Are you running any other preprocessors, and if yes, in
which order?  What does the output of eqn look like?

Re: Help wanted: just run gxditview on your system and click

[Tadziu Hoffmann]

> gxditview from 1.22.4 freshly compiled on Opensuse 15.4 works
> (all menu items).

Also, this is straight X11, no Wayland involved.

Re: Help wanted: just run gxditview on your system and click

[Tadziu Hoffmann]

> Just run "gxditview", left-click in the big yellow canvas area,
> and try to select _any_ menu item.

gxditview from 1.22.4 freshly compiled on Opensuse 15.4 works
(all menu items).

Re: widows vs orphans

[Tadziu Hoffmann]

> What do our resident typographers regard as a widow and an orphan?

Not an expert, but I thought the mnemonic was that orphans
become isolated at the beginning of their lives, and widows
at the end of their lives.  Correspondingly, an orphan is the
first line of a paragraph that gets separated from the rest
of the paragraph, and a widow is the last line of a paragraph
that gets separated from the rest of the paragraph.

Re: Using -Tpdf rather than -Tps and then ps2pdf

[Tadziu Hoffmann]

> I think the likeliest site to fix PDF output is the `pdf:SS`
> macro in pdf.tmac.

You are right.

This works:

  .de pdf:SS
  .char \\$1 \s'n[.ps]u*89u/100u'\S'15'\\$1\S'0'\s'0'
  ..
  .pdf:SS \[*a]
  .pdf:SS \[*b]
  (etc.)

Re: Using -Tpdf rather than -Tps and then ps2pdf

[Tadziu Hoffmann]

> I tried two different methods of getting it to adjust the
> font height, and neither worked at all.

For me, the following works:

  .fzoom S 890
  .EQ
  i iota
  .EN

Unfortunately, this also scales the uppercase Greek letters and
other mathematical symbols, which we don't want.  In grops, we
can scale Symbol-Slanted (SS) for the lowercase Greek letters
independently of Symbol (S) for the uppercase Greek letters.

Re: Using -Tpdf rather than -Tps and then ps2pdf

[Tadziu Hoffmann]

> But, the output direct to PDF from 'groff' does not match that of
> going to Postscript and then converting that to PDF using 'ps2pdf'.

The main difference that I can see is that in p8ps.pdf the symbol
font has been scaled to match the x-height of the text font.
In p8pdf.pdf the Greek letters (alpha, beta, pi) are too large,
resulting in an unpleasant appearance of equations containing
these symbols.

Re: Explanations with an EQN User Guide

[Tadziu Hoffmann]

> 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 totally confused, because groff apparently
> ignores \t when it doesn't come from eqn. If, as i believe,
> eqn doesn't know about .ta and groff doesn't know about eqn
> and normally ignores \t, what causes the skip to happen?

Eqn makes troff assemble a string named "10", and at the end
of its output this string is interpolated:

  \*(10

During the definition of the string, the escape sequence \t
is interpreted as a tab (see section 7.2. "Copy mode input
interpretation" of the Troff User's Guide).  You can therefore
even embed \t in your equation to achieve the same effect as
a literal tab.  (But why would you want to do that?)

Accordingly, troff only ignores \t when it is encountered in
the running text, and if this text is not subject to copying:

  a\tb  <-- does nothing

  .ds X a\tb
  \*X   <-- tab!

  .de Y
  a\tb
  ..
  .Y<-- tab!

Also, tabs in eqn material are a bad idea if your macro package
internally uses tabs to place the equation number.  This is
roughly what my own macros do:

  .nr E# 0
  .de EQ
  .nr E# +1
  .di XX \" Just to throw away the default output.
  ..
  .de EN
  .br
  .di
  .ta \n(.lu/2uC \n(.luR
  \t\\*(10\t(\\n(E#)
  .br
  ..

Re: Truncate the last lines of a diversion to another diversion

[Tadziu Hoffmann]

Since you're already diverting into TEXT when you expect the
overflow to occur, you have to use a diversion trap instead
of a page trap:


  .ll 20m
  .de CUT
  .di   \" stop diverting into TEXT...
  .di TEXT2 \" ...and divert into TEXT2.
  ..
  .di TEXT
  .dt 1v CUT \" 1v into the diversion, redivert into TEXT2.
  A paragraph that is long enough to be used as an example
  for my question.
  .br
  .di
  .nf
  .TEXT
  -
  .TEXT2
  .fi

Re: Unexpected behaviour when using linenumbering and tbl

[Tadziu Hoffmann]

> What can be done to resolve this issue?

One possible way would be to put

  .nr ln 0

after ".nm".

Explanation: if you look at the output of tbl, you can see that
tbl will issue ".nm" requests under certain circumstances, but
apparently only if the line number register is nonzero.

Re: 3-word compound adjectives; the return of the '-'

[Tadziu Hoffmann]

>  a) block device-based filesystems
>  b) block-device-based filesystems
>  c) block- device-based filesystems
>  d) block device\[en]based filesystems
>
> Which form would you recommend me to use?

I would go with "block-device\[en]based filesystems", with
the reasoning that a dash binds stronger than a space, the
precedence being (from stronger to weaker binding):

  [none] > hyphen > en-dash > space

Similarly:

  hot-fudge sundae

and

  Einstein\[en]de-Sitter universe

even though other people may disagree on this point.
(de Sitter as a name is without hyphen, but I would
hyphenate it in a compound to make the relationship
between the words clearer.)

On the web and in the literature you can find

  Anti-de Sitter space

which I would prefer to see as

  Anti\[en]de-Sitter space

Although language does not always follow logic, in reference
manuals and the like exactness should be preferred over
traditional custom.  This also pertains to moving punctuation
outside of quotes, if it is not part of the quoted text, e.g.,

  This is referred to as a "file system".

instead of

  This is referred to as a "file system."

Re: Fwd: Re: suspected `eqn' bug.

[Tadziu Hoffmann]

> This appears to be because "PI" is a magic token in eqn(1),
> preferentially interpreted even in this context as a shorthand
> for the capital Greek pi symbol; it is therefore replaced with
> a special character escape sequence to access the
> corresponding glyph, which is `\(*P`.

warning: can't find font '\(*P'

> How do we cope with this problem?

Quoting the argument works:

  gfont "PI"

It seems that the parser does not make an exception for eqn
control commands, at least in this case, so "PI" remains PI
and is not replaced by the Greek uppercase pi, just like in

  "PI" + "pi" != PI + pi

Re: Parallel Typesetting

[Tadziu Hoffmann]

> With a little more macro magic, I would assume it wouldn't be
> too much trouble for both pages to have the same content for a
> portion of it, such as with an illustration, say, or a math
> equation.

Indeed, that should be possible without much work.  In the
simplest case, one could just duplicate the material, but you
might just as well write a macro that simply appends to both
diversions.  In the example, every language change starts a new
paragraph, but this doesn't have to be.  The important thing is
just that the two diversions are synchronized in length when
switching back to the first language (and output if enough
material for a whole page has been gathered[*]).

[*]This wasn't implemented correctly, but is fixed now.
(Everything was just flushed out at the end, which is very
inefficient if many pages were being processed, because
it results in mostly just copying overflowing formatted
material around.)

I have now also uploaded a minimal version with a few comments
indicating the purpose of the macros, and added a few features,
such as the use of separate environments for the two languages
(this would be useful for synchronizing the diversions anywhere
in mid-sentence without needing a paragraph break, since the
partially collected line could remain in the environment,
to be resumed later).

Re: Parallel Typesetting

[Tadziu Hoffmann]

> > I'm trying to see how much trouble it would be to typeset
> > a bilingual text parallel by pages, as in, one language on
> > the recto page, the other on the verso page, synchronized
> > somehow by paragraph, preferably more or less automagically.

> I would say you could do this with a number of custom macros,
> in the same vein as Ted Harding's suggested solution (your
> first reference).

Here is a little proof-of-concept, built entirely with a few
ad-hoc macros and some hacks to account for font (mis-)encoding:

  https://www.usm.uni-muenchen.de/~hoffmann/roff/2lang/

View the PDF in acroread with page display settings "Two-Up"
and "Show Cover Page During Two-Up".

(Setting Fraktur really isn't my area of expertise, so
I beg pardon for any blunders I may have committed.)

Re: Parallel Typesetting

[Tadziu Hoffmann]

> I'm trying to see how much trouble it would be to typeset
> a bilingual text parallel by pages, as in, one language on
> the recto page, the other on the verso page, synchronized
> somehow by paragraph, preferably more or less automagically.

I would say you could do this with a number of custom macros,
in the same vein as Ted Harding's suggested solution (your
first reference).

Format the text into two diversions (one for each language),
paragraph by paragraph, and at the end of each pair of paragraphs
add space to the diversion with the smaller height, in order
to re-synchronize the two diversions.  After you have gathered
enough text for a full page (you can do this with a trap, but I
would probably just check the height after adding each paragraph),
write the page header for the first language, output the first
diversion onto the page, trapping the overflow into a temporary
diversion (like you would do for footnotes), and write the page
footer for the first language.  Begin a new page, write the page
header for the second language, output the second diversion,
again trapping the overflow into a second temporary diversion,
and write the page footer for the second language.  Then, fill
the two primary diversions with the still-remaining overflow
and continue.

That way your manuscript should remain fairly uncluttered
(since all the complexity is in the macros),

.2B
.L1
stuff in language 1
.L2
stuff in language 2
.L1
more stuff in language 1
.L2
more stuff in language 2
.2E

with a couple of macros for starting and finishing the
dual-language part.

Re: Five glyphs: a minor PostScript challenge

[Tadziu Hoffmann]

> [...] glyph coverage of the special characters listed in
> groff_char(7) for the PostScript output device.

> As I understand it, the PostScript language has operators or
> built-in functions for performing basic transformations like
> reflection and skew.

Just as a general note, I wanted to point out that we do
not want to output faked glyphs unconditionally, since the
user might choose to work with a font that has those glyphs.

If a font does not have the glyphs, we can indeed use
.fchar/.fschar/.schar to substitute embedded Postscript
code to manipulate things on the fly.  Ideally, however,
this should be fixed by providing a suitable font.

Could we perhaps distribute a custom Type 3 (possibly Type 1)
font that contains only these missing glyphs, accessed as
fallback font using .special/.fspecial?

> Does PostScript have an erasure operator?

Postscript has a clipping operator, which inhibits drawing
anything outside a given region.

Re: Five glyphs: a minor PostScript challenge

[Tadziu Hoffmann]

> > A. \[-+]: The minus-plus.  We should be able to dynamically generate
> >   this from \[+-] by reflecting the latter about a horizontal axis.  If
> >   the glyph is flipped within its bounding box, I guess the result
> >   would need to be vertically shifted to align it on the baseline.
> 
> This needs a lot of work but might get you started.
> 
>   \s+1\fB+\h'-0.55m'\v'-0.30v'\-\v'+0.30v'\fP\s-1

That would be my ansatz as well: simply assemble the glyph
in groff itself.  Note also that some fonts have a weirdly
squished plus-minus sign, which is ugly.  Building it from
a real plus sign and a real minus sign ensures consistency
in the shapes.  Here's my solution for Times + Symbol that
I came up with some time ago:


  .\" eqn
  .\" 
  .sp 3c
  .ps 72
  .vs 74
  .fp 1 R Times-Roman
  .fp 2 I Times-Italic
  .fp 3 S Symbol
  .char \(pm \v'-0.11m'\Z'+'\v'0.34m'\-\v'-0.23m'
  .char \(mp \v'-0.23m'\Z'\-'\v'0.34m'+\v'-0.11m'
  .gcolor red
  .EQ
  a +- b
  .EN
  .sp -1
  .gcolor
  .EQ
  define pm % type binary font S \(pm %
  a pm b
  .EN
  .br
  .EQ
  define mp % type binary font S \(mp %
  a mp b
  .EN

Re: Equation Label wrongly positioned in indented '-mm' (MM) display

[Tadziu Hoffmann]

> This is a bug in groff's MM. Irrespective of the type of display, the
> Equation number argument to .EQ should display on the right margin.

You are right, it is a bug in groff's MM.  Your fix does look
reasonable.  The real problem is that groff's MM's treatment of
displayed equations is messed up, and should be completely reworked.
In groff's MM the equation number is printed independently of the
equation proper, and is thus not guaranteed to be aligned with the
baseline of the equation.  AT&T MM does it correctly.

Re: Equation Label wrongly positioned in indented '-mm' (MM) display

[Tadziu Hoffmann]

> If anybody wants to tell me a better way to fix the problem,
> I would love to know.

What about defining a new display style that only indents on
the left, not on the right?  I.e., add the following two lines
to m.tmac at the appropriate places:

  .nr ds*format!6 6\"   indent only on the left

and

  .if \\n[ds*format]=6 'in \\n[ds*old-in]u+\\n[Si]n

Or perhaps use -1 instead of 6?  Just an idea.

Re: Multiline Subject as PDF metadata

[Tadziu Hoffmann]

> .pdfinfo /Subject  line 1\\nline\\n line 2
> does not work

It seems the argument is reprocessed several times,
so you need escape the backslashes accordingly.
This appears to work:

  .pdfinfo /Subject line 1nline 2nline 3

Re: Multiline Subject as PDF metadata

[Tadziu Hoffmann]

> This metadata is held in the "document information dictionary"
> of the pdf. In the pdf 1.4 standard the items
> Title/Author/Keywords/Subject are all defined as text strings,
> so I believe that precludes them from being multiline.

You can embed \n into the strings, but not all programs will
display this as a newline -- pdfinfo does, but my version of
acroread displays a boxed "000A" instead.

  \X'ps: exec mark \
  /Title (\\nMy\\nmultiline\\ndocument\\ntitle\\n) \
  /Synopsis (A short description of the document content.) \
  /CreationDate (Jan 25, 2022) \
  /ModDate (Jan 25, 2022) \
  /DOCINFO pdfmark'
  Hello, world!

I used groff -Tps and ps2pdf to create the PDF file,
and pdfinfo shows:

  Title:
  My
  multiline
  document
  title

  Creator:groff version 1.22.4
  Producer:   GPL Ghostscript 9.53.3
  CreationDate:   Jan 25, 2022
  ModDate:Jan 25, 2022
  Tagged: no
  UserProperties: no
  Suspects:   no
  Form:   none
  JavaScript: no
  Pages:  1
  Encrypted:  no
  Page size:  595 x 842 pts (A4)
  Page rot:   0
  File size:  4785 bytes
  Optimized:  no
  PDF version:1.4


> It does seem a little odd that the command "pdfinfo -meta"
> does not include custom keys in its output.

"pdfinfo -meta" prints the "Metadata" stream from the PDF
file's Catalog object.  This is an entirely different object
than the Info dictionary, so it doesn't make sense to jumble
the two together.  (Instead, it would be better if pdfinfo
would simply always print all keys of the Info dictionary.)

  trailer <<
/Info 2 0 R
/Root 1 0 R
... other entries ...
  >>

  2 0 obj
  <<
/Producer (GPL Ghostscript 9.53.3)
/CreationDate (Jan 25, 2022)
/ModDate (Jan 25, 2022)
/Creator (groff version 1.22.4)
/Title (\nMy\nmultiline\ndocument\ntitle\n)
/Synopsis (A short description of the document content.)
  >>
  endobj

  1 0 obj
  <<
/Type /Catalog
/Metadata 3 0 R
/Pages 5 0 R
  >>
  endobj

  3 0 obj
  <<
/Type /Metadata
/Subtype /XML
/Length 4 0 R
  >>
  stream
  ... XMP encoded metadata ...
  endstream
  endobj

(PDF version 1.2 has no Metadata stream, but PDF 1.4 does.)

Re: Is there any way to make alternate rows of a table have a light gray background?

[Tadziu Hoffmann]

>  The problem occurs when your table spans pages.  Since you
>  are creating the gray line _after_ the current line,
>  sometimes you get an extra gray line on the first page, and
>  other times you get a double gray line on the second page.

Indeed.  Just to clarify, filling the *next* line ahead of
time was intended for tables which have both horizontal rules
and fills.  On a high-resolution device you can fill right up
to the rule, but at screen resolutions the viewer software has
to round the coordinates and might overpaint the previously
drawn rule with a fill.  This looks ugly.  Thus, my approach
of already filling the next line, thereby ensuring that the
rules bordering a table line always get drawn after the fill.
However, this approach unfortunately only works if the table
does not get broken across pages at unpredictable positions.

If you have long tables which must get broken across
pages automatically, you only have the choice of filling
(or not filling) the *current* line, and possibly avoiding
horizontal rules.  (Unless you're willing to modify tbl to
add real support for fills.)

In this regard, your solution works correctly, but it still
has a feature which has bothered me, namely that the fills
are tied to specific lines in the table (which might indeed
be what you want).  But suppose I always wanted to fill the
*even* lines of the table on every page.  Then the decision
whether or not to fill a specific line must be delayed until
it is known whether that line is an even or odd line on the
page it will appear on.

Since tbl uses diversions to test whether a table line will
still fit on the current page, we need to embed the decision
to fill (or not to fill) into the content in such a way that it
survives this diversion and becomes active when the diversion
is finally replayed onto the page.

Fortunately, that is indeed possible using the \? escape,
as show in the attachment.  This solution alternates between
a filling and a non-filling macro (F1 and F0, both triggered
by \*Z in the table), and resets the fill mode on every table
header (\*X or \*Y in the table header; \*Y allows the header
to have a separate fill using F2).  I have also decided to
add dummy columns on the left and right, so that the fills
always start at the same horizontal position, independent of
the alignment of the first data column.


.\" tbl mm
.\" 
.de TP
'SP 1i
..
.\" 
.nr TW 0
.nr F 0
.defcolor tblfill1 rgb .9 1 .8
.defcolor tblfill2 rgb 1 .9 .8
.ds X \\?\R'F 1'\\?
.ds Y \\?\R'F 1'\\*(F2\\?
.ds Z \\?\R'F 1-nF'*(FnF\\?
.ds F0
.ds F1 \Z'\v'0.3v'\M[tblfill1]\D'P 0 -1v \\n(TWu 0 0 1v''
.ds F2 \Z'\v'0.3v'\M[tblfill2]\D'P 0 -1v \\n(TWu 0 0 1v''
.\" 
.TS H
tab(~);
L1 Lb Lb Lb 1L
L  Lb Lb Lb  L
L  N  N  N   L.
\*Y~A~B~C
\*Y~~~
_
.TH
\*Z~1~2~3
\*Z~4~5~6
\*Z~7~8~9
\*Z~11~22~33
\*Z~44~55~66
\*Z~77~88~99
\*Z~111~222~333
\*Z~444~555~666
\*Z~777~888~999
\*Z~1~2~3
\*Z~4~5~6
\*Z~7~8~9
\*Z~11~22~33
\*Z~44~55~66
\*Z~77~88~99
\*Z~111~222~333
\*Z~444~555~666
\*Z~777~888~999
\*Z~1~2~3
\*Z~4~5~6
\*Z~7~8~9
\*Z~11~22~33
\*Z~44~55~66
\*Z~77~88~99
\*Z~111~222~333
\*Z~444~555~666
\*Z~777~888~999
\*Z~1~2~3
\*Z~4~5~6
\*Z~7~8~9
\*Z~11~22~33
\*Z~44~55~66
\*Z~77~88~99
\*Z~111~222~333
\*Z~444~555~666
\*Z~777~888~999
\*Z~1~2~3
\*Z~4~5~6
\*Z~7~8~9
\*Z~11~22~33
\*Z~44~55~66
\*Z~77~88~99
\*Z~111~222~333
\*Z~444~555~666
\*Z~777~888~999
\*Z~1~2~3
\*Z~4~5~6
\*Z~7~8~9
\*Z~11~22~33
\*Z~44~55~66
\*Z~77~88~99
\*Z~111~222~333
\*Z~444~555~666
\*Z~777~888~999
\*Z~1~2~3
\*Z~4~5~6
\*Z~7~8~9
\*Z~11~22~33
\*Z~44~55~66
\*Z~77~88~99
\*Z~111~222~333
\*Z~444~555~666
\*Z~777~888~999
\*Z~1~2~3
\*Z~4~5~6
\*Z~7~8~9
\*Z~11~22~33
\*Z~44~55~66
\*Z~77~88~99
\*Z~111~222~333
\*Z~444~555~666
\*Z~777~888~999
\*Z~1~2~3
\*Z~4~5~6
\*Z~7~8~9
\*Z~11~22~33
\*Z~44~55~66
\*Z~77~88~99
\*Z~111~222~333
\*Z~444~555~666
\*Z~777~888~999
\*Z~1~2~3
\*Z~4~5~6
\*Z~7~8~9
\*Z~11~22~33
\*Z~44~55~66
\*Z~77~88~99
\*Z~111~222~333
\*Z~444~555~666
\*Z~777~888~999
\*Z~1~2~3
\*Z~4~5~6
\*Z~7~8~9
\*Z~11~22~33
\*Z~44~55~66
\*Z~77~88~99
\*Z~111~222~333
\*Z~444~555~666
\*Z~777~888~999
\*Z~1~2~3
\*Z~4~5~6
\*Z~7~8~9
\*Z~11~22~33
\*Z~44~55~66
\*Z~77~88~99
\*Z~111~222~333
\*Z~444~555~666
\*Z~777~888~999
.TE


tblfill.pdf
Description: Adobe PDF document

Re: How to align filled output line with tab stop?

[Tadziu Hoffmann]

> However, I want the output to be like this:  I want the "Right" content
> of the second input line to be aligned with the second tab stop.  I also
> want the long "Middle" content of the second input line to be filled
> between the two tab stops.  Like this:
> 
>   Left Middle..Right
>   Left This is a very long string that will not fit in a
>single output line and will have to break...Right

This requires some serious troff magic.  The problem is that
the motion generated by tabs and leaders

  [...] is the distance from the current position on the
  _input_ line (where a tab or leader was found) to the
  next tab stop [...]

(Troff User's Manual section 9.1).

Nevertheless, the problem can be solved using diversions,
by delaying the interpretation of tabs and leaders until
the text has already been formatted.

It looks like you're trying to construct something similar to
a table of contents, so in case this might be illuminating,
here is a simplified version of my solution to that problem
from my own macro set.  I prefer wrapping the lines at a bit
less than the full width, in the example I've arbitrarily
set this to 4i (the full width is 5i).  The second tab exists
just to get the dots in different lines vertically aligned.


.\"
.\" 
.ds L This is a very long string that will not fit in a single output line and 
will have to break
.\" 
.char \(.. \0.\0
.lc \(..
.\" 
.de BT
.di TC
.in 1i
.ti -1i
.ll 4i
.ta 1i
.fi
.ad l
.hy 0
\\$1\t\c
..
.\" 
.de ET
.ta 1i \w'\\$1'u%\w'\(..'u+5i-\w'\\$1'u-\w'\(..'u 5iR
\\a\\t\\$1
.br
.di
.in 0
.nf
.TC
..
.\" 
.po 1i
.sp 2i
\D'l 0 -1m'\D'l 1i 0'\D'l 0 1m'\v'-1m'\D'l 3i 0'\D'l 0 1m'\v'-1m'\D'l 1i 0'\D'l 
0 1m'
.BT First
Middle
.ET 1
.BT Second
\*L
.ET 1234567


tocfmt.pdf
Description: Adobe PDF document

Re: Should vertical motions be in vees or ems? Where does the baseline go?

[Tadziu Hoffmann]

> - General typographic convention is to measure vertical
> motions in v's, not m's.  CSTR #54's definitions of \u, \d,
> and \r do not align with this common expectation.

I think this depends on what you consider the purpose of \d
and \u to be.  Obviously they are not needed: everything they
do can be achieved with \v.  However, if we assume they were
intended as an easy way to get super- and subscripts (e.g., for
footnote markers, or as in "H\d2\uO"), then you definitely want
the motion to be in units of the current font size and not in
baseline spacings.  Otherwise, those super- and subscripts
would be ripped from the text lines they belong to if you
were to try setting the text double-spaced by requesting
(say) .vs 24 for a 10-point font.

Re: weird behaviour of .sp| with expression

[Tadziu Hoffmann]

You are getting an overflow.  The request

> .sp |(\n[t1]+\n[t2])u

does not do what you think it does.

Section 1.4 "Numerical expressions" of the Troff User's Manual says

  In the presence of default scaling, the desired scale indicator
  must be attached to *every* number in an expression for which
  the desired and default scaling differ.

In your case this means that the formatter is trying to space to
position 383464 _baseline spacings_ (the default scaling for sp)
from the top of the page, which it apparently cannot do, so the
request is ignored.

Re: The 3-faces problem

[Tadziu Hoffmann]

> - It's all a single identifier, so breaking it into multiple
> lines to avoid using \f would hurt readability.

I think it's a matter of debate whether

  .RB [ U ] INT \fIN\fP _WIDTH

or

  .RB [ U ] INT\c
  .IB N _WIDTH

is more readable.  In the latter at least it's obvious
in which typeface each part will be set.


> but for some reason the underscore (_) is also set in italics
> (well, under-underscored, since italics is just a big hype :).

How can you tell?

If you're using devps:

  in the Adobe fonts Times-Roman, Times-Italic, and Times-Bold
  the underscore is identical, so you don't see which underscore
  is being used (but it's the bold underscore).

If you're using devtty:

  If GROFF_NO_SGR is unset:
the output is correct, the underscore is in bold.

  If GROFF_NO_SGR is set (and you're piping into less):
Both bold underscore and underlined underscore are output as
.  less has a preference
for interpreting this as an "italic" underscore rather than
as a bold underscore.  There's nothing you can do short of
modifying less.

Re: pic doesn't center when i use a macro

[Tadziu Hoffmann]

> I can do something more manual but i really would like to take advantage
> of the expressivity of pic. Any other comment is also warmly welcome.

It looks like pic has no string variables, and the "if"
works at the statement level, not expression level.

To provide a somewhat constructive answer: do you really
need the "for" loop here?  Perhaps it might also help to
restructure the code, for example like this:

  .PS

  define mybox {
  s = layer * margin
  box width w height h with .sw at (s,s)
  box width w height margin with .nw at last box .nw dashed $1
  w = w - tr
  h = h - tr
  layer = layer + 1
  }

  w = 3; h = 2; margin = .2; tr = 2 * margin; layer = 0
  mybox("Entête Ethernet")
  mybox("Entête IP")
  mybox("Entête TCP")
  mybox("Donnees applicatives")

  .PE

Re: SEE ALSO fails

[Tadziu Hoffmann]

> If the proposal is to remove See Also's that aren't installed, I
> could not be more against that idea.  That just makes the system
> harder to learn.

I agree.

Also, some of the manual pages reference Bell Labs Technical
Reports or other papers that are hardly ever installed on any
system.  Nevertheless, these "see also" entries are still helpful
to the reader by indicating specific non-manpage documentation
that contains relevant information on the subject.

Re: Problems with .PDFPIC caused by pdfinfo

[Tadziu Hoffmann]

> grep: (standard input): binary file matches
> you see, the \0 chars are already there.
> What can I do?

Is there a reason you need grep in there?

You can work around the issue by removing the grep completely
and do the filtering with sed: add the "-n" (no default output)
command-line option when calling sed, and the "p" (print) flag
to the substitute command:

  sed -ne 's/.../.../p'

Re: Align top of text blocks

[Tadziu Hoffmann]

> I noticed you removed the overlapping email domain, that was
> an extreme example, but how do I go in order to define a
> column width, i.e. when roff has to wrap the text?

In this case you could use tbl (convenient) or do manually
what tbl would do internally (gives you more freedom to fiddle
around), i.e., fill 3 diversions with text and then replay
those diversions side-by-side onto the page.

If the amount of text is limited and you don't have to worry
about text filling up the column and causing a page break,
you can also write the text directly to the page using suitable
combinations of line length and indent:

  .\"
  .\" 
  .nr LL 21c-5c
  .ll \n(LLu
  .po 2.5c
  .\" 
  .nr w1 3.5c
  .nr w3 3.5c
  .nr w2 \n(LL-\n(w1-\n(w3
  .\" 
  .ps 10
  .vs 12
  .sp 2.5c
  .ll \n(LLu
  .mk
  \m[red]\v'-1v'\D'l 0 1c'\h'\n(w1u'\D'l 0 -1c'\h'\n(w2u'\D'l 0 
1c'\h'\n(w3u'\D'l 0 -1c'\D'l -\n(.lu 0'\m[]
  .br
  .rt
  .in 0
  .ll \n(w1u
  .ad l
  Sometown, Earth
  .br
  v...@johndoethetrueone.com
  .br
  .rt
  .in \n(w1u+\n(w2u
  .ll \n(LLu
  .ad r
  linkedin.com/in/j.doe
  .br
  github.com/j.doe
  .br
  .rt
  .in \n(w1u
  .ll \n(w1u+\n(w2u
  .ps 28
  .vs 24
  .ad c
  John \[Fo]The Doe\[Fc] Doe
  .br
  .ps 10
  .vs 12
  .sp 3
  .in 0
  .ll \n(LLu
  .ad b
  .fi
  Text

Note that if you want to allow groff to break lines then you
cannot use .nf, .ce, and .rj, but instead have to use .ad l,
.ad c, and .ad r, and break lines manually if necessary
with .br.

Re: Align top of text blocks

[Tadziu Hoffmann]

> I have three blocks of text on a line and I would like to align them
> on top rather than on the baseline.
> 1. Is there a "proper" way to achieve this?

Since letters are not perfect rectangles, and you're mainly
concerned with the aesthetic appeal of the end result rather
than some "ideal" mathematical alignment, I will argue that
there is no "proper" way other than manually moving the text
around until the result appears pleasing to the eye.

That said, with the example text you have given (where the
big letters have no descenders), I *do* prefer alignment of
the baselines of the bottom lines of text, with the upper
two lines moved above:

  .ll 21c-5c
  .po 2.5c
  .sp 10
  .nf
  .vs 0
  .ps 10
  \v'-12p'Sometown, Earth
  v...@johndoethetrueone.com
  .ps 28
  \h'4.3c'John \[Fo]The Doe\[Fc] Doe
  .ps 10
  .rj 2
  \v'-12p'linkedin.com/in/j.doe
  github.com/j.doe
  .ps 10
  .vs 12
  .sp 3
  Text

(Using this template, you could of course also move the big
middle text vertically.  I've set the baseline spacing to zero,
which allows the baselines of all text to be manually positioned
relative to the same vertical location on the page.)

Re: Man page quibble about .wh

[Tadziu Hoffmann]

> .wh N trap
>   Set condition trap; negative means from page bottom.

I think it should say "set position trap", to distinguish it
from other traps (e.g., input line count traps).

Re: "Can't break line warning"

[Tadziu Hoffmann]

> The horizontal line output by the \l escape is 6 inches, the same as the
> declared line length.
> troff: letterhead-demo.mm:31: warning [p 1, 0.5i]: can't break line

You have a tab after the "\l'6i'", which counts as part of the
line.  Remove it, and the error disappears.

  \s+5World Reknowned Corporation\s0
  .br
  \u\l'6i'\" Horizontal line @ 6 inches
  .tl '''\u\s-24927 33\*[SUP]rd\*[SUPX] Street, Megalopolis, KS 67999\s0'
  .sp 3

You then need to put a ".br" after the line, to terminate it,
otherwise it's retained as a partially filled line until the
next break (from the ".sp 3"), and therefore is only output
after the 3-part title.

  \s+5World Reknowned Corporation\s0
  .br
  \u\l'6i'\" Horizontal line @ 6 inches
  .br
  .tl '''\u\s-24927 33\*[SUP]rd\*[SUPX] Street, Megalopolis, KS 67999\s0'
  .sp 3

Alternatively, do the right-adjusting with ".rj" instead of ".tl":

  \s+5World Reknowned Corporation\s0
  .br
  \u\l'6i'\" Horizontal line @ 6 inches
  .rj 1
  \u\s-24927 33\*[SUP]rd\*[SUPX] Street, Megalopolis, KS 67999\s0
  .sp 3

Re: mm(7) DT string and super/subscripts (was: troff Memorandum Macros documentation derived from the paper "MM - Memorandum Macros")

[Tadziu Hoffmann]

> .ds { \v'-.9m\s'\En[.s]*7u/10u'+.7m'

Wow.  I didn't know that was possible.  You're interrupting the
calculation of the amount of vertical movement to set the point
size, and then use the new value (as ems) in the interrupted
calculation...

But the result is correct, it's equivalent to

  \v'-0.41m'\s'\n[.s]*7/10'

where -0.41 = -0.9 + 0.7*7./10.

Re: Why does refer(1) have no database field for "edition"?

[Tadziu Hoffmann]

> > Inaugurate a GNU extension?  

> Indeed, but the subject under discussion is making refer(1)
> conformant to various acknowledged styles, not in-house usage.

But isn't that the job of the macro package, not refer?

I guess the question is "How can refer make that job easier?",
which you answered by saying that mom defines a new database
field for the edition.  If we consider this usage the status
quo, should it be documented with an appropriate entry in the
list of field names in the refer manual page?

(The manual page does speak of the "conventional meaning" of
each field, implying that this is by common agreement rather
than by rule of an authority.)

Re: Why does refer(1) have no database field for "edition"?

[Tadziu Hoffmann]

> There are no should therefores or guesswork when it comes to
> formatting bibliographies.  Where edition goes and how it's
> formatted is fixed by the style: [...]

If you're submitting a paper to a journal you obviously have to
follow the journal style (usually the editors will take care of
that), but for in-house documents I'm not required to use either
of those styles and can define my own, in which case I do have a
choice on how to format the bibliography.

Re: Why does refer(1) have no database field for "edition"?

[Tadziu Hoffmann]

> > Why does refer(1) have no database field for "edition"?

> The lacuna isn't in refer(1), but in the macro packages using it.
> Any %c, where c is an alphabetic character, can be used to create
> a field refer(1) understands.  It is up to macro writers to work
> out the the formatting and placement within a refer(1) citation or
> bibliography entry.

Certainly it can be extended, but it would be useful if
there were some general agreement on which character to use
(preferably something mnemonic;  "E" is already taken by
"editor"), unless you are satisfied with a solution that
works only with one macro package (if competing approaches
are taken by the writers of different macro packages).

Sticking it onto the end of the title field is ugly, because
one might like the title to be printed in italics, whereas the
edition is "meta information" and should therefore perhaps be
in the regular font.  Making the macro parse the content of a
field to extract this kind of information is also unappealing,
because that is the whole purpose of having different fields
in the first place.

There is also no field for "type" (i.e., article, book,
etc.), so refer has to infer this information from the
presence/absence of other fields...

Re: Help needed with pdfroff and suppression nodes

[Tadziu Hoffmann]

> But the wheels turning here mystify me.  What is causing the
> `image_filename` (formerly `last_image_filename`) to go
> uninitialized, why only in very specific circumstances?

pdfmark uses the suppression mechanism bounding box output
to find the anchor positions, but no images are involved.
The Postscript branch in suppress_node::tprint should be
perfectly okay with an empty image_filename.  At the moment,
the entire "is_html / else postscript (or other device)" switch
is being skipped if we have no image_filename, resulting in
no output of the link anchor information for pdfmark.

Re: utmac -muh error on Ubuntu

[Tadziu Hoffmann]

> > echo ".ds head-str ${str: -1}"

> The compatible syntax is ${str:-1}.

I wonder if that is meant, though.

Bash also has

  ${parameter:offset}
  ${parameter:offset:length}
Substring Expansion.  Expands to up to length characters of
the value of parameter starting at the character specified
by offset.

with the caveat that

  Note that a negative offset must be separated from the
  colon by at least one space to avoid being confused with
  the :- expansion.

This latter is something that all Bourne-compatible shells
understand, here in a summary by POSIX:

 | parameter set| parameter set   | parameter unset
 | and not null | but null|
  ---+--+-+
  ${parameter:-word} | substitute parameter | substitute word | substitute word
  ${parameter-word}  | substitute parameter | substitute null | substitute word
  ${parameter:=word} | substitute parameter | assign word | assign word
  ${parameter=word}  | substitute parameter | substitute null | assign word
  ${parameter:?word} | substitute parameter | error, exit | error, exit
  ${parameter?word}  | substitute parameter | substitute null | error, exit
  ${parameter:+word} | substitute word  | substitute null | substitute null
  ${parameter+word}  | substitute word  | substitute word | substitute null

but the purpose of this differs from that of the bashism above.

Re: [mom] using chem in mom

[Tadziu Hoffmann]

> But I would like to append arguments after .PS like `CAPTION'
> and `TARGET'.

  .PS CAPTION "My chemical structure" TARGET "NoMethane"
  begin chem
  CH3
  bond
  CH3
  end
  .PE

Re: "absolute" vertical position seems awfully relative

[Tadziu Hoffmann]

> Here is a more complex test file using the -me macros.
> It uses -me's $H macro to define an action that should be
> done on every page, in this case the printing of a bit of
> text at an "absolute" vertical position.
> [...]
> Each page has a different combination of leading and
> presence/absence of header.

If you want to insulate your header against the effects of
varying the parameters of the running text, use a dedicated
environment for the header:

  .de $H \" -me macro called at the top of every page
  .ev header
  \v'|3u'At 30,000 units.
  .br
  .ev
  ..

Re: "absolute" vertical position seems awfully relative

[Tadziu Hoffmann]

> At first blush this seems like a bug.  But Heirloom troff does the
> same thing, so maybe the so-called absolute position is relative in
> some obscure but intended way?

I think \v'|10u' does not mean "space to an absolute vertical
position of 10 units".  It means "space vertically a distance
corresponding to the difference between the current point and
the absolute vertical position of 10 units".

Normally these would be equivalent in effect, except for the
combination of initial pseudo-page transition and trap-invoked
page header macro (which you don't have if you're using plain
groff and have not set one).

>From experiments I deduce the sequence of events to be similar to:

  1. The initial vertical position is 0.
  2. The distance from 0 to 10u is computed;
 let's call this "x".
  3. Something is about to be output, so the trap is sprung and
 the point is set to a vertical position "y" by the macro.
  4. From "y", a distance of "x" is spaced, and then the text
 is output (at the seemingly wrong location).
  5. "bp" is invoked, a new page is begun, the top-of-page
 macro is executed, and the point is set to vertical
 position "y".
  6. The distance from "y" to 10u is computed;
 let's call this "z".
  7. From "y", a distance of "z" is spaced, and then the text
 is output (at the correct desired location).

To prevent the surprising result on the first page, simply
begin the sequence with a ".br", which then initiates the
first page *before* performing the distance calculation.

Re: (A possible) way to change the background color of pdf

[Tadziu Hoffmann]

> I want to have a black background with green text for
> my slides.
> 
> If I'm correct this can't be set within groff.

You can draw a filled polygon (rectangle) using \D'P ...'
covering the whole page at the beginning of each page,
before outputting any text.  Example:


.\" a4 land
.\" 
.nr PL 21.0c \" A4 landscape height
.nr PW 29.7c \" A4 landscape width
.pl \n(PLu
.po 2c
.ll \n(PWu-\n(.ou-\n(.ou
.gcolor green
.\" 
.\" set up a separate environment for headers and footers
.\" to avoid interference with the running text
.ev 1
.vs 0
.lt \n(PWu-\n(.ou-\n(.ou
.fcolor black
.gcolor yellow
.ev
.\" 
.de BP
.ev 1
\Z'\h'-\\n(.ou'\D'P 0 \\n(PLu \\n(PWu 0 0 -\\n(PLu''
.sp |2c
.ev
..
.de EP
.ev 1
.sp |\\n(PLu-1.5c
.tl '\\n[year]/\\n[mo]/\\n[dy]''\\n%'
.bp
.ev
..
.wh 0 BP
.wh -3c EP
.\" 
Hello, world!




coloredbackground.pdf
Description: Adobe PDF document

Re: Is there any way to make alternate rows of a table have a light gray background?

[Tadziu Hoffmann]

> The data is simple, but the table is wide and the data
> occurs in a right triangle shape, with one point at the
> top left, another point at the top right, and the other
> point at the bottom right.  This means that it is hard to
> accurately follow from the row heading on the left to the
> appropriate column on the right.

> Is there any way to make alternate rows of a table have a
> light gray background?

It is possible only with some trickery, and it's easier
if all the lines have the same height, otherwise much more
manual intervention will be necessary.  To make this fully
automatic will probably require modifying tbl.

In the attached example, the gray background is created by
drawing filled boxes across the width of the table.  In fact,
the background is drawn in advance for the *next* line, in
order to prevent the horizontal line from being painted over,
which can happen at low resolutions; however, this requires
two slightly different versions of the fill because the line
spacing is different around the horizontal line.

TW is the width of the table and is set by tbl.  LW is a
correction for (half) the line width and is only necessary
because I'm using square linecaps.


.\" tbl a4 land
.\" 
.defcolor lightgray gray 0.95
.fcolor lightgray
.nr TW 0
.nr LW 0.2p
.ds X \Z'\h'-\\n[LW]u'\v'0.39v'\D'P 0 1v 2u*\\n[LW]u+\\n[TW]u 0 0 -1v''
.ds Y \Z'\h'-\\n[LW]u'\v'0.22v'\D'P 0 1v 2u*\\n[LW]u+\\n[TW]u 0 0 -1v''
.\" 
.po 2c
.ll 29.7c-4c
.ps 10
.vs 12
.sp 3c
.TS
center expand;
l0c |cbescbescbescbescbescbescbescbescbescbescbesl
l0lb|n0n n0n n0n n0n n0n n0n n0n n0n n0n n0n n0n0l.
\*X System  Chahnae DrougaynHelmar  Kalavel Lesdin  Peles   Petrion 
Seljan  Tauran  Telmera Varos
_
Ajada   11h 19d 11h 6d  3h  5d  16h 
2d  1h  4d  23h 3h  12d 16h 9h  
1d  3h  14h
\*Y Chahnae 12d 16h 8d  12h 4d  19h 
2d  17h 6d  20h 22h 7d  22h 12h 
8h  16h
Drougayn5d  17h 4d  
6h  12d 6h  2d  19h 11d 2h  6d  21h 9d  
10h 11d 11h 7d  13h
\*Y Helmar  9d  20h 
3d  18h 5d  6h  9d  3h  3d  22h 7d  2h  
5d  21h 10d 15h
Kalavel 
7d  4h  9d  6h  10d 7h  3d  5h  12d 15h 
7d  14h 10d 19h
\*Y Lesdin  
9d  11h 11d 16h 1d  23h 10d 2h  
6d  8h  7d  11h
Peles   
9d  19h 2d  14h 3d  6h  
10d 20h 4d  6h
\*Y Petrion 
4d  11h 7d  18h 
3d  9h  7h
Seljan  
6d  1h  
9d  5h  13h
\*Y Tauran  

20h 5h
Telmera 

9h
.TE


alternaterows.pdf
Description: Adobe PDF document

Re: Is decreasing top margin with mm macros broken?

[Tadziu Hoffmann]

> Does anyone how to decrease the top margin with mm macros?
> There is VM macro that is supposed to change it, however it
> has no effect on the top margin, when one wants to decrease
> it.  Looks like the top margin can only be increased.

This is possibly a bug.  In groff's mm, the option -T *does*
set pg*header-size, but this does not appear to be used in
the page header macro, only pg*extra-header-size.

As a workaround, you could use the advice from an old MM manual
(http://www.bitsavers.org/pdf/altos/3068/690-15844-001_Altos_Unix_System_V_Documenters_Workbench_Vol_2_Jul85.pdf),
which says:

  The .VM (vertical margin) macro allows the user to specify
  additional space at the top and bottom of the page.  This
  space precedes the page header and follows the page footer.

and also:

  Default spacing at the top of the page may be decreased by
  redefining .TP.

and:

  Generalized Top-of-Page Processing

  Note: This part is intended only for users accustomed
  to writing formatter macros.

  During header processing, MM invokes two user-definable macros:

   * The .TP (top of page) macro is invoked in the environment
 (refer to .ev request) of the header.

   * The .PX is a page header user-exit macro that is invoked
 (without arguments) when the normal environment has been
 restored and with the "no-space" mode already in effect.

  ...

  To obtain more specialized page titles, the user may redefine
  the .TP macro to cause the desired header processing.



So, if you define

  .de TP
  ..

there will be no space at all at the top, and

  .de TP
  .sp
  .tl \\*(}t
  .sp
  ..

will give you three lines of top margin, with the default
header in the middle.

Re: Vertical Span in a tbl

[Tadziu Hoffmann]

> Can anybody explain to me why the curly bracket begins way below
> the first row even if its definition is put in the first row?

That appears to be a peculiarity of the interaction between
eqn and tbl, which looks like its aligning the top of the
equation with whatever alignment point was specified in tbl.
You can see this if you try top-aligned and bottom-aligned
placement in tbl instead of vertical centering.  For vertical
centering (and if your equation has approximately equal
height and depth), you can usually obtain the desired result
by saying "space 0" inside the equation, which overrides
the default extra pre- and post-line space requested by eqn.

Re: Warnings of dangling .el with bracket-less nesting

[Tadziu Hoffmann]

> I'd like to keep #60260 open as a documentation issue and adapt your
> explanation into an addition to the Texinfo manual.  Is that okay with
> you .if/.ie/.el are a matter of recurring confusion.

No problem -- that's why I wrote it.

> My first attempt to contrive this situation (attached) did not succeed
> in provoking such bad behavior, but I think you have a valid point.

It probably doesn't happen very often, because we would have
to pop a "true" off the stack for this to be critical, which
means that the "if" branch has to be false, but the broken
macro still has to be called before the "else" branch.

Here is a somewhat contrived situation that exhibits the error:

  .de My
  .ie '\\$1'1' my x
  .el .ie '\\$1'2' my y
  .el  my z
  ..
  .de Yr
  .ie '\\$1'-' [before]
  .My \\$2
  .el  [after]
  ..
  .Yr - 1
  .Yr + 1

which outputs "[before] my x" and "my x my z" (which probably
isn't what the code intended).  If we correctly write

  .de My
  .ie   '\\$1'1' my x
  .el \{.ie '\\$1'2' my y
  .elmy z\}
  ..

we get "[before] my x" and "my x [after]" instead.


> [...] since *roff has no C-like "switch" or Lisp-like "cond".

Not sure how robust this is, but we can construct something
lispish (and even completely braceless):

  .de cond
  .if \\n(.$=1 \\$1
  .if \\n(.$>1 .cond1 \\$@
  ..
  .de cond1
  .ie \\$1 \\$2
  .el .cond2 \\$@
  ..
  .de cond2
  .shift 2
  .cond \\$@
  ..
  .de My
  .cond '\\$1'a' "CASE 1" '\\$1'b' .special '\\$1'c' "CASE 3" "CASE other"
  ..
  .de special
  .nr x 2+3
  CASE special: \\nx
  ..
  .My a
  .My b
  .My c
  .My d
  .My e

Re: Warnings of dangling .el with bracket-less nesting

[Tadziu Hoffmann]

> > in spite of the warnings.  Are the warnings a bug?

> It seems so.  Would you be willing to file this report
> as a Savannah ticket?

Do not remove the warnings.  They are not a bug.

Here is how .ie and .el work:

  * .ie evaluates its condition "c" and pushes "not(c)" onto a
stack.  Then, if "c" is true, it executes the rest of the
line, otherwise it simply discards it.

  * .el pops a value "z" from the stack.  If "z" is true, it
executes the rest of the line, otherwise it discards it.

Now consider again the code

  .de mymac
  .ie '\\$1'a' CASE a
  .el .ie '\\$1'b' CASE b
  .el .ie '\\$1'c' CASE c
  .el  CASE z
  ..

and imagine calling this as

  .mymac a

Then, step by step, this is what happens:

  1) First line: the condition evaluates to "true", so .ie
 pushes "false" onto the stack.  The stack now contains one
 item.  "CASE a" is output, since the condition was "true".

  2) Second line: .el pops the previously pushed value "false"
 off the stack.  The stack is now empty.  Since "false"
 was popped, the rest of the line is discarded.

  3) Third line: .el tries to pop a value off the stack,
 but the stack is empty, therefore a warning is printed.
 Since no "true" was popped, the rest of the line is
 discarded.

  4) Fourth line: .el tries to pop a value off the stack,
 but the stack is still empty, therefore a warning is
 printed.  Since no "true" was popped, the rest of the
 line is discarded.

So, superficially it might appear as if the code were doing the
right thing.  But now imagine that .mymac was called as part of
a larger .ie branch.  THEN THOSE TWO .el REQUESTS WILL POP VALUES
FROM THE STACK THAT MOST PROBABLY WERE NOT INTENDED FOR THEM.
With no warnings to indicate that the logic of .mymac was flawed
when called in isolation, imagine the frustration of trying to
debug the behavior of troff in that larger context under the
(wrong) assumption that .mymac was in fact correct.

Re: Warnings of dangling .el with bracket-less nesting

[Tadziu Hoffmann]

> > The warnings do not happen if the "else" statements are
> > wrapped in \{\ ...  \} but is this supposed to be necessary?

> No.  It may be sanity-preserving to use the brace escapes but
> they are not syntactically required.

I will argue that they *are* necessary.  The code might appear
to be syntactically correct, but in general it might not do
what you want it to do.  This particular code:

  .de mymac
  .ie '\\$1'a' CASE a
  .el .ie '\\$1'b' CASE b
  .el .ie '\\$1'c' CASE c
  .el  CASE z
  ..
  .mymac a
  .mymac b
  .mymac c
  .mymac d

only works because it is a linear "select first true of" switch
without branches, and an ".el" without an executed ".ie" is not taken.
(Remember that the decision logic is internally coded as a stack,
and an empty stack [which should not happen, and therefore
prints a warning] acts like "false".)

However, a branching switch like

  .de mymak
  .ie   '\\$1'a' \{.ie '\\$2'1' CASE a
  .el\{.ie '\\$2'2' CASE b
  .el   CASE x\}\}
  .el \{.ie '\\$1'b' \{.ie '\\$2'1' CASE c
  .el\{.ie '\\$2'2' CASE d
  .el   CASE y\}\}
  .el   CASE z\}
  ..
  .mymak a 1
  .mymak a 2
  .mymak a 3
  .mymak b 1
  .mymak b 2
  .mymak b 3
  .mymak c 1
  .mymak c 2
  .mymak c 3

will not work without the braces.

You can of course also use macros for grouping, and thereby
avoid the use of braces altogether.  Note that here it becomes
very evident that there is an ".el" for every ".ie":

  .de mymax
  .ie '\\$1'a' .mymax1a  \\$2
  .el  .mymax2  \\$1 \\$2
  ..
  .de mymax2
  .ie '\\$1'b' .mymax2a  \\$2
  .el  CASE z
  ..
  .de mymax1a
  .ie '\\$1'1' CASE a
  .el  .mymax1b \\$1
  ..
  .de mymax1b
  .ie '\\$1'2' CASE b
  .el  CASE x
  ..
  .de mymax2a
  .ie '\\$1'1' CASE c
  .el  .mymax2b \\$1
  ..
  .de mymax2b
  .ie '\\$1'2' CASE d
  .el  CASE y
  ..
  .mymax a 1
  .mymax a 2
  .mymax a 3
  .mymax b 1
  .mymax b 2
  .mymax b 3
  .mymax c 1
  .mymax c 2
  .mymax c 3

This style of coding might appear a bit long-winded at first,
but actually becomes more convenient when lots of non-trivial
processing must be done in the different branches.

Re: problem with mm macros

[Tadziu Hoffmann]

> I've attached your patch to http://savannah.gnu.org/bugs/?57034.

Just a brief follow-up to this: the test in the patch is
for a string expansion that returns nothing, in this case
usually because the string is not defined, and then groff
gives a warning.

There are two obvious ways to fix this: either an explicit
empty string that signifies the end of the author's titles,
or storing the number of titles in a register.  Both require
one extra register per author, but I think the latter is better,
since it easily allows using .ne to request enough space to
output an author's signature block without page breaks.

With that in mind, here's a better patch (relative to the
original m.tmac).  No provision is made for single titles
that are so long that they take more than one line to print.


--- a/contrib/mm/m.tmac
+++ b/contrib/mm/m.tmac
@@ -2975,7 +2975,8 @@
 .\"indent stored in cov*abs-ind
 .\" number of authors stored in cov*au
 .\" author(s) stored in cov*au!x!y
-.\" author(s) title stored in cov*at!x!y
+.\" number of author's titles strored in cov*at!x
+.\" author(s) title(s) stored in cov*at!x!y
 .\"x is the author-index [1-cov*au], y is the argument-index [1-9].
 .\" author(s) firm stored in cov*firm
 .\" new date (if .ND exists) is stored in cov*new-date
@@ -3019,6 +3020,7 @@
 .\" Must appear directly after .AU
 .de AT
 .if \\n[.$]<1 .@error "AT: no arguments"
+.nr cov*at!\\n[cov*au] \\n[.$]
 .nr cov*i 0 1
 .while \\n[.$]>=\\n+[cov*i] \{\
 .  ds cov*at!\\n[cov*au]!\\n[cov*i] "\\$[\\n[cov*i]]
@@ -3304,18 +3306,23 @@
 .nr let*i 0 1
 .while \\n+[let*i]<=\\n[cov*au] \{\
 .  if \\n[let*i]>1 .as let*tmp /
-.  as let*tmp \\*[cov*au!\\n[let*k]!2]
+.  as let*tmp \\*[cov*au!\\n[let*i]!2]
 .\}
 .if !''\\$1' .as let*tmp -\\$1
 .in (u;\\n[.l]/2)
 .nf
 .nr let*i 0 1
 .while \\n+[let*i]<=\\n[cov*au] \{\
+.  ne 3v+\\n[cov*at!\\n[let*i]]v
 .  SP 3v
 .  if \\n[let*i]=\\n[let*k] \{\
 \Z'\h'-(u;\\n[.l]/2)'\\*[let*tmp]'\c
 .  \}
 \\*[cov*au!\\n[let*i]!1]
+.  nr let*j 0 1
+.  while \\n+[let*j]<=\\n[cov*at!\\n[let*i]] \{\
+\\*[cov*at!\\n[let*i]!\\n[let*j]]
+.  \}
 .\}
 .fi
 .in

Re: problem with mm macros

[Tadziu Hoffmann]

> > > Now the problem is that groff doesn't show the author's
> > > title below the author's name. Both heirloom and neatroff
> > > do, so it is maybe a bug in groff?

> > Does this seem to you to be the same as the problem reported in
> > http://savannah.gnu.org/bugs/index.php?57034 ?

> Yes, this seems to be the same problem.

This can be fixed quickly by adding, below the line that
prints the author's name,

  \\*[cov*au!\\n[let*i]!1]

the following lines:

  .nr let*j 0 1
  .while !'\\*[cov*at!\\n[let*i]!\\n+[let*j]]''  \{\
  \\*[cov*at!\\n[let*i]!\\n[let*j]]
  .\}

Since the number of titles for each author is not stored anywhere,
this assumes that an empty value signals the end of the author's
titles, i.e., there can be no empty author's titles (but \& works).


I noticed that the loc-dept-initials/initials line is also different.
Does anyone still use this?  Is it important that this is
historically accurate?

Re: Generic Givens Rotation Matrix in EQN

[Tadziu Hoffmann]

> Would anybody have a version of this in EQN. I do not mean the
> simple 2x2 matrix but the generic nxn square matrix

This is fairly straightforward with a few suitable eqn
definitions to simplify entering the equation.  The attached
PDF was created with the following code and my own paragraph
and section macros.  (Use "left [" and "right ]" instead of
my bracket macro if you want to use the equation with some
other macro package.)  Note that since I've entered the matrix
column-wise it appears transposed in the text editor display.

  $
  define ...   % roman " . . . " %
  define vdots % roman "\v'-.6m'\z.\v'.5m'\z.\v'.5m'.\v'-.4m'" %
  define ddots % roman "\v'-.6m' .\v'.5m' .\v'.5m' .\v'-.4m' " %
  define Gjj % G sub back 30 jj %
  define Gji % G sub back 30 ji %
  define Gii % G sub back 10 ii %
  define Gij % G sub back 10 ij %
  define Gkk % G sub back 10 kk %
  define | % above %
  $
  .SE
  Givens rotations
  .PP
  A Givens rotation is represented by a matrix of the form
  .EQ
  set column_sep 20
  G ( i, j, theta ) =
  bracket { matrix {
  ccol { 1   | vdots | 0   | vdots | 0   | vdots | 0   }
  ccol { ... | ddots | ... | ""| ... | ""| ... }
  ccol { 0   | vdots | c   | vdots | s   | vdots | 0   }
  ccol { ... | ""| ... | ddots | ... | ""| ... }
  ccol { 0   | vdots | -s  | vdots | c   | vdots | 0   }
  ccol { ... | ""| ... | ""| ... | ddots | ... }
  ccol { 0   | vdots | 0   | vdots | 0   | vdots | 1   }
  } } ,
  .EN
  which is, when $i > j$,
  .EQ
  set column_sep 100
  Gkk = 1 roman "  for  " k != i, j , fwd 100
  Gii =   Gjj =   cos ( theta ) , fwd 100
  Gji = - Gij = - sin ( theta ) .
  .EN
  (See https://en.wikipedia.org/wiki/Givens_rotation.)




givensrotation.pdf
Description: Adobe PDF document

Re: multi-page table trouble in ms

[Tadziu Hoffmann]

> I'm attaching my working copy of ms.ms and example ms.ps
> output.  The problem shows up on pages 14 and 15.

Remove the KS/KE bracketing that section.  The purpose of
these is to keep the content together on one page, but this
obviously only works if the content is less than one page in
length, and you're trying to demonstrate a multi-page table
that is intentionally longer than that.