Re: Changing header/footer font in mm
Hi Jan, At 2024-04-24T07:53:51+0200, Jan Eden wrote: > On 2024-04-24 00:07, G. Branden Robinson wrote: > > At 2024-04-21T23:52:48-0500, G. Branden Robinson wrote: > > > For mm, what I would do is set up the mounting positions to replace > > > Times with Helvetica. > > > > > > .fp 1 HR > > > .fp 2 HI > > > .fp 3 HB > > > .fp 4 HBI > > > > I retract this advice. Using ".fam H" early in the document (in > > groff 1.23.0) is better. > > This did not work in groff 1.23.0 for the header/footer issue (with > `.fam H` as the very first request in the document), I had to use both > requests – > > .fam H > .fp 1 H > > – as suggested by Thomas. Ah, right. Okay. I un-retract the advice. Yes, Thomas was right. The reason is that, quite apart from environment issues, groff mm is faithful to the DWB mm tradition in that internally it refers to fonts by mounting position rather than a named style, even though it has cognizance of only one family.[1] Jörgen Hägg, the author groff mm, appears to have added some limited support for switching the font family to his multicolumn macro extensions, MULB/MULN/MULE, but it's not clear to me exactly how they work. (Rather, I can read and understand the requests just fine but I'm not sure they're necessary...? Perhaps this was the beginning of an unfinished idea.) This fact is totally separate from the environment stuff I was talking about earlier because, as I noted previously, the list of font mounting positions is global, and consistent among all environments. The concept of mounting positions is a fairly baroque aspect of troff and completely, as far as I know, a consequence of the hardware design of the C/A/T phototypesetter used by the Bell Labs CSRG. They used this indirection to refer to fonts because the machine itself did. You didn't have any idea what font's photographic plate would be loaded into the various positions of the typesetter's mechanical carousel. One of your co-workers could scramble their order, ruining your document and you had no way of knowing until it was printed. I expect this didn't happen often, not with the imploding gaze of an office balrog to fear... I would prefer to wean groff mm off of explicit use of mounting positions altogether, but doing so is not a high-urgency project. (This also means it's good task for a contributor who wants a modestly sized project to learn with. :) ) Regards, Branden [1] I grepped and could find _no_ matches in our m.tmac for `ft [BIR]`, `\\f[BIR] or `\\f\[[BIR]\]`. Replacing "BIR" with "123" is more fruitful. signature.asc Description: PGP signature
Re: Re: Changing header/footer font in mm
Hi Branden, On 2024-04-24 00:07, G. Branden Robinson wrote: > [self-follow-up] > > I had forgotten about a contribution Nikita Ivanov made in 2022. > > At 2024-04-21T23:52:48-0500, G. Branden Robinson wrote: > > For mm, what I would do is set up the mounting positions to replace > > Times with Helvetica. > > > > .fp 1 HR > > .fp 2 HI > > .fp 3 HB > > .fp 4 HBI > > I retract this advice. Using ".fam H" early in the document (in groff > 1.23.0) is better. This did not work in groff 1.23.0 for the header/footer issue (with `.fam H` as the very first request in the document), I had to use both requests – .fam H .fp 1 H – as suggested by Thomas. - Jan signature.asc Description: PGP signature
Re: Re: Avoid page break in tables without box option
Hi Branden, On 2024-04-23 15:11, G. Branden Robinson wrote: > Hi Jan, > > At 2024-04-23T10:56:38+0200, Jan Eden wrote: > > On 2024-04-23 01:10, G. Branden Robinson wrote: > > > Bracket your table with the `DS` and `DE` macros. > > > > This works great, but there's a side effect on one of my machines: > > > > - With groff 1.23.0, the whole document is set in Helvetica (as > > configured via .fam). > > Right. > > > - With groff 1.22.4, the content of the static displays is set in Times > > New Roman (the rest of the document is set in Helvetica). > > > > Is this a known limitation of the older groff package? > > Yes. We considered it a bug; it was reported and fixed by Nikita Ivanov > in 2022. > > https://savannah.gnu.org/bugs/?63067 > > A workaround for groff 1.22.4 (and earlier) is documented in comment #2 > of that report. Excellent – thanks for the pointer. - Jan signature.asc Description: PGP signature
Re: Changing header/footer font in mm
[self-follow-up] I had forgotten about a contribution Nikita Ivanov made in 2022. At 2024-04-21T23:52:48-0500, G. Branden Robinson wrote: > For mm, what I would do is set up the mounting positions to replace > Times with Helvetica. > > .fp 1 HR > .fp 2 HI > .fp 3 HB > .fp 4 HBI I retract this advice. Using ".fam H" early in the document (in groff 1.23.0) is better. > Here's a task for an interested contributor. Already done. https://savannah.gnu.org/bugs/?63067 That bug also documents a workaround for older groffs. Regards, Branden signature.asc Description: PGP signature
Proposed: revised man(7) synopsis macros
Hi folks, I have been dissatisfied with groff man(7)'s SY and YS macros for a long time. My primary grievance is one that has frustrated its uptake by documenters of libraries: the macros are designed for synopsizing Unix commands, not C library functions. After working on the ncurses man pages for a while it became clear to me how to modestly revise the way groff man(7)'s SY and YS macros work to serve both set of authors better. My proposal, as a diff to groff Git HEAD, is attached. Here are the highlights, starting with the most disruptive: 1. The `SY` macro no longer puts vertical space on the output. That's up to you now. You can use whatever paragraphing macro you please to separate multiple synopses. 2. The `SY` macro now initially breaks the output line _only_ if it is encountered repeatedly without a preceding `YS` call. Formerly, it _always_ initially broke the output line because it put vertical space on the output. This is largely a guardrail in case someone forgets to call `YS`. (Using `SY` multiple times before `YS` used to be idiomatic for synonymous command invocations like "foobar --help" and "foobar -h"; no longer. Now you bracket each with `SY` and `YS` and leave out a paragraphing macro if you don't want one.) 3. The computed indentation of synopsis lines after the first now also includes the width of anything on the line _before_ the synopsis. This is so that you can precede the synopsis keyword with other syntax. The most likely application of this is a return type for a C function prototype. 4. The `SY` macro now accepts an optional second argument. This second argument is typeset in bold and replaces the fixed-width space that is appended to the synopsis keyword in `SY`'s single-argument form. As with that fixed-width space, the width of this suffix argument informs the indentation used on subsequent lines of the synopsis if it needs to break.[*] 5. I tested the portability of these changes to DWB 3.3 troff, Heirloom Doctools troff, and Solaris 10 troff, and worked around what appears to be a glitch in their man(7) packages. That helped, but a small problem remains: the computed width marked with an asterisk[*] in the previous item is 1n too short. Concretely, instead of: int wborder(WINDOW *win, chtype ls, chtype rs, chtype ts, chtype bs, chtype tl, chtype tr, chtype bl, chtype br); you get the following on DWB/Heirloom/Solaris 10 nroff. int wborder(WINDOW *win, chtype ls, chtype rs, chtype ts, chtype bs, chtype tl, chtype tr, chtype bl, chtype br); I regarded this defect as too inconsequential to worry about, but if someone wants to research the innards of AT&T man(7) to see if a workaround can be found, I'll be receptive to suggestions. 6. I discovered that mandoc mishandles indentation; it does not honor the rules set forth in §6 of CSTR #54 (supporting evidence attached). The result is merely ugly, however, and no text is lost. Since mandoc is actively maintained I assume that eventually this will get fixed, perhaps after a strident exhortation to migrate one's documents to mdoc(7). ;-) 7. The first argument to `SY` remains the keyword. I avoided the complexity of a three-argument form partly because I didn't need it and partly because I wanted to preserve the invariant of the first argument being the name of the documented thing. A potential advantage to this practice is that we can, in future groff man(7) development, automatically generate hyperlink tags for these items. Need to know where a command or function is synopsized? With tags you can find out much more quickly than with a textual search. (The invariant is actually a bigger advantage for hypothetical external tools--or grep(1)--because the `SY` macro would "know" which item was the keyword based on the argument count.) The payoff is that, if adopted, you can write a function synopsis like this. .P .B int .SY wborder ( .BI WINDOW\~* win , .BI chtype\~ ls , .BI chtype\~ rs , .BI chtype\~ ts , .BI chtype\~ bs , .BI chtype\~ tl , .BI chtype\~ tr , .BI chtype\~ bl , .BI chtype\~ br ); .YS ...and not worry about the line length or line breaking or any of that stuff. Compare to the status quo for the foregoing function in ncurses. .SH SYNOPSIS .nf ... \fBint wborder(WINDOW *\fIwin\fB, chtype \fIls\fB, chtype \fIrs\fB,\fR \fBchtype \fIts\fB, chtype \fIbs\fB, chtype \fItl\fB, chtype \fItr\fB,\fR \fBchtype \fIbl\fB, chtype \fIbr\fB);\fR .fi The foregoing looks messier to me as input, and moreover it does not adapt to the width of the terminal, thanks to those `nf`/`fi` formatter requests. It will waste space on wide terminals and overrun the line on narrow ones. You may notice that I haven't changed `YS` at all. T
Re: Avoid page break in tables without box option
Hi Jan, At 2024-04-23T10:56:38+0200, Jan Eden wrote: > On 2024-04-23 01:10, G. Branden Robinson wrote: > > Bracket your table with the `DS` and `DE` macros. > > This works great, but there's a side effect on one of my machines: > > - With groff 1.23.0, the whole document is set in Helvetica (as > configured via .fam). Right. > - With groff 1.22.4, the content of the static displays is set in Times > New Roman (the rest of the document is set in Helvetica). > > Is this a known limitation of the older groff package? Yes. We considered it a bug; it was reported and fixed by Nikita Ivanov in 2022. https://savannah.gnu.org/bugs/?63067 A workaround for groff 1.22.4 (and earlier) is documented in comment #2 of that report. Regards, Branden signature.asc Description: PGP signature
Re: Re: Avoid page break in tables without box option
Hi Branden, On 2024-04-23 01:10, G. Branden Robinson wrote: > Hi Jan, > > At 2024-04-23T07:28:41+0200, Jan Eden wrote: > > enclosing a table in a box avoids page breaks within the table > > reliably for me – is it possible to get the same behaviour without the > > box? > > Yes. This is what "keep" macros are for, assuming the macro package > you're using offers those (all full-service packages except those for > man pages[1] do). > > Hmm, your recent questions about mm suggest to me that that's the > package you're using, and our groff_mm(7) page does not employ the word > "keep". > > However, mm's display macros can serve this purpose and §7.3 of the DWB > 3.3 mm manual mentions this fact. > > Bracket your table with the `DS` and `DE` macros. This works great, but there's a side effect on one of my machines: - With groff 1.23.0, the whole document is set in Helvetica (as configured via .fam). - With groff 1.22.4, the content of the static displays is set in Times New Roman (the rest of the document is set in Helvetica). Is this a known limitation of the older groff package? - Jan signature.asc Description: PGP signature
Re: Re: Avoid page break in tables without box option
Hi Thomas, On 2024-04-23 10:14, Thomas Dupond via wrote: > Jan Eden a écrit : > > Unfortunately, I failed to describe my requirements properly – sorry > > again. My document contains multiple relatively small tables, and each > > table should appear on exactly one page (i.e. should not cross page > > boundaries). > > > > I attached sample documents and the respective outputs of > > > > groff -mm -t -Kutf8 -Tpdf test_boxed.groff > test_boxed.pdf > > > > to this message, and I would like to achieve the page break behaviour of > > the boxed variant, but without having actual boxes drawn around the > > tables. > > Hello Jan, > > If you are using the mm macros, you can achieve what you want by > following the first advice of Branden, call .DS before each .TS and > .DE after each .TE. You're right, of course – sorry again to Branden (and the list members) for not recognizing the correct solution right away. Thank you – Jan signature.asc Description: PGP signature
Re: Avoid page break in tables without box option
Jan Eden a écrit : > Unfortunately, I failed to describe my requirements properly – sorry > again. My document contains multiple relatively small tables, and each > table should appear on exactly one page (i.e. should not cross page > boundaries). > > I attached sample documents and the respective outputs of > > groff -mm -t -Kutf8 -Tpdf test_boxed.groff > test_boxed.pdf > > to this message, and I would like to achieve the page break behaviour of > the boxed variant, but without having actual boxes drawn around the > tables. Hello Jan, If you are using the mm macros, you can achieve what you want by following the first advice of Branden, call .DS before each .TS and .DE after each .TE. "G. Branden Robinson" a écrit : > Hi Jan, > > At 2024-04-23T07:28:41+0200, Jan Eden wrote: >> enclosing a table in a box avoids page breaks within the table >> reliably for me – is it possible to get the same behaviour without the >> box? > > Yes. This is what "keep" macros are for, assuming the macro package > you're using offers those (all full-service packages except those for > man pages[1] do). > > Hmm, your recent questions about mm suggest to me that that's the > package you're using, and our groff_mm(7) page does not employ the word > "keep". > > However, mm's display macros can serve this purpose and §7.3 of the DWB > 3.3 mm manual mentions this fact. > > Bracket your table with the `DS` and `DE` macros. -- Thomas
Re: Re: Avoid page break in tables without box option
Hi Branden, On 2024-04-23 01:59, G. Branden Robinson wrote: > The foregoing advice could probably use some fine-tuning. Is it okay to > use *roff diversions if you let a macro package that ships with groff do > it for you? > > You seem to be bumping into an anticipated issue, though. > > groff 1.23.0's tbl(1) man page includes the following cautionary note: > > Limitations > Multi‐page tables, if boxed and/or if you want their column > headings repeated after page breaks, require support at the time > the document is formatted. A convention for such support has > arisen in macro packages such as ms, mm, and me. To use it, follow > the .TS token with a space and then “H”; this will be interpreted > by the formatter as a TS macro call with an H argument. Then, > within the table data, call the TH macro; this informs the macro > package where the headings end. If your table has no such heading > rows, or you do not desire their repetition, call TH immediately > after the table format specification. If a multi‐page table is > boxed or has repeating column headings, do not enclose it with > keep/release macros, or divert it in any other way. Further, the > bp request will not cause a page break in a “TS H” table. Define a > macro to wrap bp: invoke it normally if there is no current > diversion. Otherwise, pass the macro call to the enclosing > diversion using the transparent line escape sequence \!; this will > “bubble up” the page break to the output device. See section > “Examples” below for a demonstration. > > I got good results with the attached document. Here are the commands I > used. > > $ nroff -t -mm EXPERIMENTS/table.mm > > $ groff -t -mm EXPERIMENTS/table.mm > table.ps > > Does this help? Unfortunately, I failed to describe my requirements properly – sorry again. My document contains multiple relatively small tables, and each table should appear on exactly one page (i.e. should not cross page boundaries). I attached sample documents and the respective outputs of groff -mm -t -Kutf8 -Tpdf test_boxed.groff > test_boxed.pdf to this message, and I would like to achieve the page break behaviour of the boxed variant, but without having actual boxes drawn around the tables. - Jan .TS box decimalpoint(,) tab(@); lb rb rb - - - l n n. Konto@Rechnungsbetrag@Anteil Haftpflichtversicherung@31,27 EUR@10,70 EUR Heizung Grundkosten@1720,92 EUR@176,73 EUR Heizung Verbrauchskosten@1720,92 EUR@322,99 EUR Gebäudeversicherung@580,68 EUR@198,78 EUR Frischwasser@379,87 EUR@151,95 EUR Grundsteuer B@277,72 EUR@95,07 EUR Straßenreinigung@38,34 EUR@13,12 EUR Abfallentsorgung@368,00 EUR@147,20 EUR Regenwasser@104,88 EUR@35,90 EUR Abwasser@439,25 EUR@175,70 EUR Lichtstrom@80,00 EUR@26,67 EUR Heizungsstrom@120,20 EUR@41,15 EUR Schornstein/ Heizungswartung@92,83 EUR@31,78 EUR \fBGesamtbetrag:@@1427,74 EUR Vorauszahlungen:@@1524,00 EUR Guthaben:@@-96,26 EUR\fR .TE .sp 2 .TS tab(@); lb lb - - l l. Kürzel@Berechnung UN@Anteil an der Zahl der Wohneinheiten im Objekt (1/n) AR@Anteil der Wohnfläche an der Gesamtwohnfläche im Objekt OC@Anzahl der Personen relativ zur Gesamtanzahl der Bewohner*innen des Objektes CO@Anteil am Gesamtverbrauch .TE .sp 2 .TS box decimalpoint(,) tab(@); cb s - - l n. None: Haftpflichtversicherung (AR) Gesamtbetrag@31,27 EUR Anteil (Leistung)@34,2% (85/248 m²) Anteil (Zeitraum)@100,0% (365/365) Anteil (Rechnung)@100% \fBBetrag@10,70 EUR\fR .TE .TS box decimalpoint(,) tab(@); cb s - - l n. None: Heizung Grundkosten (AR) Gesamtbetrag@1720,92 EUR Anteil (Leistung)@34,2% (85/248 m²) Anteil (Zeitraum)@100,0% (365/365) Anteil (Rechnung)@30% \fBBetrag@176,73 EUR\fR .TE .TS box decimalpoint(,) tab(@); cb s - - l n. None: Heizung Verbrauchskosten (CO) Gesamtbetrag@1720,92 EUR Anteil (Leistung)@26,8% (5322/19849 kWh) Anteil (Zeitraum)@n/a Anteil (Rechnung)@70% \fBBetrag@322,99 EUR\fR .TE .TS box decimalpoint(,) tab(@); cb s - - l n. None: Gebäudeversicherung (AR) Gesamtbetrag@580,68 EUR Anteil (Leistung)@34,2% (85/248 m²) Anteil (Zeitraum)@100,0% (365/365) Anteil (Rechnung)@100% \fBBetrag@198,78 EUR\fR .TE .TS box decimalpoint(,) tab(@); cb s - - l n. None: Frischwasser (OC) Gesamtbetrag@379,87 EUR Anteil (Leistung)@40,0% (2/5 Personen) Anteil (Zeitraum)@100,0% (365/365) Anteil (Rechnung)@100% \fBBetrag@151,95 EUR\fR .TE .TS box decimalpoint(,) tab(@); cb s - - l n. None: Grundsteuer B (AR) Gesamtbetrag@277,72 EUR Anteil (Leistung)@34,2% (85/248 m²) Anteil (Zeitraum)@100,0% (365/365) Anteil (Rechnung)@100% \fBBetrag@95,07 EUR\fR .TE .TS box decimalpoint(,) tab(@); cb s - - l n. None: Straßenreinigung (AR) Gesamtbetrag@38,34 EUR Anteil (Leistung)@34,2% (85/248 m²) Anteil (Zeitraum)@100,0% (365/365) Anteil (Rechnung)@100% \fBBetrag@13,12 EUR\fR .TE .TS box decimalpoint(,) tab(@); cb s - - l n. None: Abfallentsorgung (OC) Gesamtbetrag@368,00 EUR
Re: Avoid page break in tables without box option
Hi Jan, At 2024-04-23T08:24:19+0200, Jan Eden wrote: > Sorry for failing to mention that I use the tbl preprocessor, I figured that. It takes exceptional courage and patience with tedium to lay out tables _without_ tbl. :P > which only has a `nokeep` option described as follows: > > "Don't use roff diversions to manage page breaks. Normally, tbl > employs them to avoid breaking a page within a table row. This usage > can sometimes interact badly with macro packages' own use of > diversions—when footnotes, for example, are employed. This is a GNU > extension." The foregoing advice could probably use some fine-tuning. Is it okay to use *roff diversions if you let a macro package that ships with groff do it for you? You seem to be bumping into an anticipated issue, though. groff 1.23.0's tbl(1) man page includes the following cautionary note: Limitations Multi‐page tables, if boxed and/or if you want their column headings repeated after page breaks, require support at the time the document is formatted. A convention for such support has arisen in macro packages such as ms, mm, and me. To use it, follow the .TS token with a space and then “H”; this will be interpreted by the formatter as a TS macro call with an H argument. Then, within the table data, call the TH macro; this informs the macro package where the headings end. If your table has no such heading rows, or you do not desire their repetition, call TH immediately after the table format specification. If a multi‐page table is boxed or has repeating column headings, do not enclose it with keep/release macros, or divert it in any other way. Further, the bp request will not cause a page break in a “TS H” table. Define a macro to wrap bp: invoke it normally if there is no current diversion. Otherwise, pass the macro call to the enclosing diversion using the transparent line escape sequence \!; this will “bubble up” the page break to the output device. See section “Examples” below for a demonstration. I got good results with the attached document. Here are the commands I used. $ nroff -t -mm EXPERIMENTS/table.mm $ groff -t -mm EXPERIMENTS/table.mm > table.ps Does this help? Regards, Branden .LP Here's a document with a boxed table in it. .LP .TS H box; L. .TH 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 .TE table.ps Description: PostScript document signature.asc Description: PGP signature
