Re: On computerese
On 2024-09-12 09:46, Douglas McIlroy wrote: > There it festered, right in the middle of Branden's otherwise high literary > style: "use cases". I've despaired over the term ever since it wormed its > way into computer folks' vocabulary. How does a "use case" differ from a > "use"? Or, what's the use of "use case"? The meaning of the German equivalents "Anwendung" (use) and "Anwendungsfall" (use case) are clearly distinguished, with the former referring to an activity, the latter to the outlines of a potential activity. - Jan signature.asc Description: PGP signature
Re: vim :hardcopy equivalent
Hi Marcus, On 2024-07-21 20:33, me.gr...@mro.name wrote: > Hi list, > > after years of doing my administrative letters with vim :hardcopy plus some > settings[1], I'd like to move on to groffing them with identical look and be > indepenent of the editor. > > So, typewriter look, significant whitespace, page number/total heading. > > Being new to groff and a bit lost in macro packages as well as the docs - how > would I do that, or where has such been documented before? I had the same question (coming from LaTeX’ scrlttr2 document class) a few months ago. Both mm[1] and mom[2] provide options for setting business letters, but not according to DIN 5008. Fortunately, Matthias Schmidt and Christian Schaller provided starting points for DIN-compliant letters, and I used these to create my own macro file[3]. [1] https://tkurtbond.github.io/troff/mm-all.pdf (Appendix D) [2] https://www.schaffter.ca/mom/momdoc/letters.html#top [3] https://eden.one/2024/4/din-briefe-mit-groff Cheers, Jan 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: 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: 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: 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. Sorry for failing to mention that I use the tbl preprocessor, 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." With tbl's `box` option – .TS box; .\" further table config and content .TE – the tables are typeset exactly as intended, but without boxes, some tables are cut in half by a page break. - Jan signature.asc Description: PGP signature
Avoid page break in tables without box option
Hi, 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? - Jan signature.asc Description: PGP signature
Re: Re: gropdf, Ghostscript, and file sizes
Hi Oliver, yes, Branden referred to (the lack of) font subsetting – but two different toolkits are responsible for the largest files (groff/PDF + ps2pdf with standard fonts, groff/PDF with additional fonts), and I wonder why. - Jan On 2024-04-22 21:08, Oliver Corff wrote: > Hi, > > probably the massive difference in size is due to embedding the whole > font in the PDF document, I assume. > > Best, Oliver. > > On 22/04/2024 16:56, Jan Eden wrote: > > Hi, > > > > I learned that gropdf in general tends to create larger files than a > > combination of groff and Ghostscript (ps2pdf): > > > > groff -Tps test.tr | ps2pdf - test.pdf → 18K > > groff -t -Tpdf test.tr > test.pdf → 313K > > > > This holds true even when pdf is specified as groff's output device and > > the output is then piped to ps2pdf: > > > > groff -Tpdf test.tr | ps2pdf - test.pdf → 19K > > > > The results above are based on a single-page file set in an Open Type > > font I added to groff. > > > > But today I came across an interesting effect with the standard fonts > > (results for H, similar for T etc): > > > > groff -Tps test.tr | ps2pdf - test.pdf → 13K > > groff -t -Tpdf test.tr > test.pdf → 12K > > groff -Tpdf test.tr | ps2pdf - test.pdf → 2.6M > > > > Why is gropdf more efficient than groff+Ghostscript with the standard > > fonts – and why does groff create such gargantuan files for the PDF > > output device when coupled with ps2pdf? > > > > - Jan > > -- > Dr. Oliver Corff > Wittelsbacherstr. 5A > 10707 Berlin > GERMANY > Tel.: +49-30-85727260 > mailto:oliver.co...@email.de signature.asc Description: PGP signature
gropdf, Ghostscript, and file sizes
Hi, I learned that gropdf in general tends to create larger files than a combination of groff and Ghostscript (ps2pdf): groff -Tps test.tr | ps2pdf - test.pdf → 18K groff -t -Tpdf test.tr > test.pdf → 313K This holds true even when pdf is specified as groff's output device and the output is then piped to ps2pdf: groff -Tpdf test.tr | ps2pdf - test.pdf → 19K The results above are based on a single-page file set in an Open Type font I added to groff. But today I came across an interesting effect with the standard fonts (results for H, similar for T etc): groff -Tps test.tr | ps2pdf - test.pdf → 13K groff -t -Tpdf test.tr > test.pdf → 12K groff -Tpdf test.tr | ps2pdf - test.pdf → 2.6M Why is gropdf more efficient than groff+Ghostscript with the standard fonts – and why does groff create such gargantuan files for the PDF output device when coupled with ps2pdf? - Jan signature.asc Description: PGP signature
Re: A primer on font installation for groff (was: gropdf(1)'s 'Font installation' section is opaque to me)
Hi Alejandro, On 2024-04-18 20:33, G. Branden Robinson wrote: > Hi Alex, > > At 2024-04-19T00:29:37+0200, Alejandro Colomar wrote: > > While the above is interesting, I've already read similar explanations > > from you in related threads. However, I still have no clue of how to > > drop TINOR from the Linux man-pages repo and generate it from > > something coming from a package. :( > > Well, it's tedious, which is why Peter Schaffter and others have written > shell scripts to help with the process. > > Here's a file- and program-centric overview of what's required. > > 1. You grab a modern font file from some place. This will be a TTF or > OTF file. > > 2. You use FontForge or a similar tool to generate TWO files from a > TTF/OTF file. > > 2a. A PostScript Type 1 font in PFA and/or PFB format. If you want > to embed this font in a groff-generated PostScript file, you have to > use PFA, because that is all grops(1) understands. If you want to > embed this font in a groff-generated PDF, you can use either, > because gropdf(1) understands both formats. > > 2b. If you have a PFB file and need PFA, you can use groff's > utility pfbtops(1) to produce the latter. > > 2c. You will also have to produce an AFM file. This stands for > "Adobe Font Metrics". This describes the dimensions of the glyphs > in the proper font file. The font metrics are not the font itself; > they merely describe it in some respects. > > 3. The formatter, troff(1), must have font metrics so that it can > correctly position glyphs on the page. But GNU troff, like AT&T > troff before it, does not use AFM files directly for this purpose; > AT&T troff is older than Adobe PostScript. Instead it uses a "font > description file", which includes the metrics and other information > important to the formatter. The font description file is what > corresponds to the short, shouty *roff font names we're used to, > like "TR" or "S" or "CBI". > > 4. The *roff font description files must be placed where the formatter > can find them when it runs. They must appear in the > GROFF_FONT_PATH, or the formatter must be told where to look with an > `-f` command-line option. > > 5. When embedding fonts in PostScript or PDF, the _output driver_ > (grops or gropdf) must be told where to look to find them. Each > driver consults a "download" file for this information. > > A package manager has a few things to keep track of to ensure that the > state of all these remains coherent. > > A. If a new "modern" (TTF/OTF) font is installed, a program to generate > PFA/PFB and AFM files must be run to make it available to groff. > > B. afmtodit(1) must be run to produce a groff font description file > from the AFM file. > > C. The font description files must be placed in groff's "font search > path". In practice this means two places, one for PostScript and > one for PDF. > > D. The "download" files for the grops and gropdf programs must be > updated to list the PFA/PFB file in the correct locations. The process is explained in detail by Walter Alejandro Iglesias on the blog I referenced earlier[1], and he also provides a shell script (similar to Peter's explanation and script[2]). [1] https://technicallywewrite.com/2023/09/16/addfonts [2] https://www.schaffter.ca/mom/momdoc/appendices.html#fonts - Jan signature.asc Description: PGP signature
Re: Re: Incorrect list item spacing after pagebreak
Hi Peter, On 2024-04-18 13:42, Peter Schaffter wrote: > Jan -- > > On Thu, Apr 18, 2024, Jan Eden wrote: > > if a list with spaced, single-line items (.ITEM 0.25v) continues across > > a pagebreak in a mom document, the space between the first and the > > second item on the new page is not correct > > Glad you caught this. It will be fixed it the next mom release. For now, > > 1. Open the file om.tmac. > 2. Look for .MAC ITEM END > 3. Add this line immediately underneath > > .if \\n[#START]+\\n[@TOP]>0 .RESTORE_SPACE Thanks! I promise not to flood groff@gnu.org with more .LIST-related posts. - Jan signature.asc Description: PGP signature
Re: Re: Changing header/footer font in mm
Hi Branden,
On 2024-04-18 14:47, G. Branden Robinson wrote:
> Hi Jan,
>
> At 2024-04-18T07:11:44+0200, Jan Eden wrote:
> > there is probably a really simple solution to this,
>
> Not exactly. At the time the mm(7) macro package was developed by the
> Unix Support Group (possibly an anachronistic name selection on my
> part), the notion of a "font family" was not represented in the *roff
> language.
>
> > but I cannot find it in the docs. When selecting a default font in a
> > mm document like this –
> >
> > .nr N 1
> > .fam H
> > .
> > .TL
> > Title
> > .AU "Author"
> > .MT 4
> > .
> > .H 1 "First Heading"
> > .P
> > Some text.
> >
> > – all text is set in Helvetica, except for the header/footer (Times
> > New Roman). Why is that,
>
> As Damian indicated, it is because headers and footers ("titles") use a
> dedicated "environment", a *roff term for a bundle of typesetting
> parameters and state that usually only macro package authors mess with.
> When you create an environment in *roff, it copies its parameters not
> from the current environment's configuration, but from the _formatter's
> default state_. That means you get the Times family and roman style by
> default. You can change these, but you have to remember to do so.
>
> GNU troff also supports an `evc` request for copying environments.
>
> > and how can I change the header/footer font to match the rest of the
> > document?
>
> This looks hard to do portably. Even if you left out all groff language
> extensions, there is the problem of font repertoire varying by output
> device, and AT&T troff imposing little structure on the names of
> available fonts. (Granted, it probably took the de facto
> standardization of PostScript to bring make such an objective feasible.)
>
> But if you don't care about rendering your mm document with DWB 3.3
> troff, here are a few approaches.
>
> 1. If the _layout_ of the headers and footers is fine, and you desire
> only to change the font they use, that is easily done with the mm
> macros `PH` and `PF`. For example:
>
> .PH "'\F[P]Smith'page %'April 2024'"
> .PF "'\F[P]draft'\n[year]-\n[mo]-\n[dy]'groff \n[.x].\n[.y].\n[.Y]'"
> .H 1 Introduction
> Sed ut perspiciatis, unde omnis iste natus error sit voluptatem
> accusantium doloremque laudantium, totam rem aperiam eaque ipsa, quae ab
> illo inventore veritatis et quasi architecto beatae vitae dicta sunt,
> explicabo.
>
> In the foregoing, I lazily neglected resetting the family back to its
> previous value (with `\F[]`) because in this context it simply isn't
> necessary.
Thank you – this is what I had expected as a last resort if my
assumption of a simple solution had proven false.
But Thomas' earlier suggestion to just move the font family to the first
position (.fp 1 HR) is what I was looking for, even though the solution
might not be portable and the behavior of fp with respect to the
different environments is "odd", according to Damian.
In any case, I am very grateful for the detailed explanation (extending
to headers/footers for recto/verso pages) which will come in handy when
a more complex configuration is needed.
- Jan
signature.asc
Description: PGP signature
Re: gropdf(1)'s 'Font installation' section is opaque to me
On 2024-04-18 18:00, Alejandro Colomar wrote: > Hi, > > I find the following section very opaque. > > Font installation > The following is a step‐by‐step font installation guide for > gropdf. > > • Convert your font to something groff understands. This is a > PostScript Type 1 font in PFA or PFB format, together with an > AFM file. A PFA file begins as follows. >%!PS-AdobeFont-1.0: > A PFB file contains this string as well, preceded by some non‐ > printing bytes. In the following steps, we will consider the > use of CTAN’s BrushScriptX‐Italic font in PFA format. > > This mention of an AFM file is the first mention in the page, and has no > information about it at all. > > $ MANWIDTH=72 man gropdf | grep AFM > AFM file. A PFA file begins as follows. > • Convert the AFM file to a groff font description file with the > search path. While groff doesn’t directly use AFM files, it is > > So, I'm supposed to know what that file is, and all steps continue from > it. Well, let's see if it's something easy; maybe a Debian package with > fonts already contains somehting .afm and I can assume it's that what > this manual is referring to. The following instructions (which assume that you start out with TTF or OTF files) should be helpful, because fontforge can generate afm files from pfa files, too: https://technicallywewrite.com/2023/09/16/addfonts Buena suerte - Jan signature.asc Description: PGP signature
Incorrect list item spacing after pagebreak
Hi, if a list with spaced, single-line items (.ITEM 0.25v) continues across a pagebreak in a mom document, the space between the first and the second item on the new page is not correct. The effect is demonstrated on page 13 and in the bibliography section (pages 22-26) of the document at https://eden.one/pdf/2176_mom.pdf, and it does not occur e.g. on pages 5 or 8 (with the first item on the new page using at least 2 lines). The source file is available at https://eden.one/groff/2176.mom. Is there a way to avoid this effect? Thanks, Jan signature.asc Description: PGP signature
Changing header/footer font in mm
Hi, there is probably a really simple solution to this, but I cannot find it in the docs. When selecting a default font in a mm document like this – .nr N 1 .fam H . .TL Title .AU "Author" .MT 4 . .H 1 "First Heading" .P Some text. – all text is set in Helvetica, except for the header/footer (Times New Roman). Why is that, and how can I change the header/footer font to match the rest of the document? Thanks, Jan signature.asc Description: PGP signature
Re: Re: mom, mm, and PDF files
Hi Branden, this is great – thanks for both the explanation (re: font-subsetting) and the positive outlook on the future of groff's macro packages. - Jan On 2024-04-16 13:00, G. Branden Robinson wrote: > Hi Jan, > > At 2024-04-16T19:32:18+0200, Jan Eden wrote: > > after using LaTeX (pdflatex) for several years, I am testing groff > > (with mom and mm) to create PDF documents for the first time. > > > > With mom, the process is straightforward: A PDF outline is created > > automatically, the TOC entries are linked to the headings, and > > additional PDF links can be created according to the docs[1]. > > Yup. mom(7) has had first-class PDF support for several years. > > > It is a bit trickier with mm. I was able to create a PDF outline using > > a tip by T. Kurt Bond[2], and a link using the .pdfhref macro – but > > only with the native gropdf (groff -Tpdf), which creates really large > > files (> 500k). > > The large size may be due to the lack of font subsetting in groff 1.23.0 > and earlier. But I have good news for you; in groff Git, gropdf has, > and in the forthcoming 1.24 release we expect, precisely this feature. > > > The output of pdfmom, on the other hand, can be piped > > to ps2pdf without losing the PDF outline or links (output size: ~ > > 80k). > > > > Is it possible to > > > > - create small PDF files (via pdfroff or groff | ps2pdf) while keeping > > PDF outline/links using the mm package? > > I think Deri James's recent changes to gropdf will indeed reduce the > size of PDF files, but outlining and linking will require some work, > either within the package or via supplementary user-authored macros. > > The latter is not necessarily difficult. For an example, see the > following extension to ms(7). > > https://github.com/g-branden-robinson/retypesetting-mathematics/blob/master/g.mac > > Since Kernighan & Cherry had presciently defined an `SC` macro, local to > the document, to manage section headings for them, it was shockingly > easy for me declare a PDF bookmark within it. > > One line: that's how straightforward it was to add a PDF outline to a > 1970s document. > > > - create links from the TOC to the document headings/sections > > automatically using mm? > > I don't think this is possible with no macro effort from a document > author at present since the mm(7) package has no notion of internal > hyperlinking features or PDF. > > However, having just added these to man(7) and mdoc(7), I have an idea > how to do so for ms(7), me(7), and mm(7), and once that is done, we'll > have hyperlink/navigation parity among all of groff's full-service macro > packages. > > Regards, > Branden signature.asc Description: PGP signature
Re: Re: Enumerator spacing in bullet lists with mom
Hi Peter, On 2024-04-16 13:22, Peter Schaffter wrote: > Jan -- > > On Tue, Apr 16, 2024, Jan Eden wrote: > > I am currently testing the mom and mm macro packages, and noticed that > > mom uses sensible defaults for almost anything out of the box. > > > > Bullet lists (or lists with other static enumerators like dashes), > > however, are set with very little space between the enumerator and the > > item text. This is not true for ALPHA or DIGIT lists, which are set very > > well. > > Processing your test file with the lastest mom (2.6_c), the spacing > between bullets/dashes and subsequent text looks fine and observes > the typographic conventions with which I am familiar. I'm attaching > a pdf of the output (I added a dashed list) so you can verfiy it > looks the same as what you have been seeing. If not, update to > 2.6_c. I did use version 2.5_d, but the sample output you sent is identical (or at least very similar) to my output. I must admit that I oversimplified (shortened) the source code posted to the list; the effect is much more pronounced with list items spanning several lines (s. attached file). > If mom's default bullet/dash spacing is still, to your eyes, not > correct, you change it with the USER argument to LIST. For example, > > .LIST USER "\[bu]\ " > > adds a non-stretching wordspace to the bullet. If you want more > precise control, e.g. 3 points of space, > > .LIST USER "\[bu]\*[FWD 3p]" > or > .LIST USER "\[bu]\h'3p'" > > The first uses mom's inline escape for forward movements, the second > uses groff's native escape for the same thing. The two are > equivalent. \[en] can be used if you want dashed lists with extra > spacing between the dash and the text. Thank you very much – this is similar to what Thomas recommended earlier on the list, and I will follow your advice. Regarding the correctness of mom's default spacing for bullet lists: All other aspects of mom's output were excellent right away, which is why I assumed some error (probably on my part). As it turns out, I just have bad taste or at least a knack for overly spacious formatting. :) > > This is my test file: > > > > .PAPER A4 > > > > .TITLE "Some Title" > > A piece of advice: As a general rule, it is preferable to insert > blank lines (visual spacers) into mom text files by putting a period > (dot) at the start of the line, like so > > .PAPER A4 > . > .TITLE "Some Title" Thanks, I will do so. I already wondered in which context blank text lines (without a dot) create additional space, but this is a great tip. - Jan list-test2.pdf Description: Adobe PDF document signature.asc Description: PGP signature
mom, mm, and PDF files
Hi, after using LaTeX (pdflatex) for several years, I am testing groff (with mom and mm) to create PDF documents for the first time. With mom, the process is straightforward: A PDF outline is created automatically, the TOC entries are linked to the headings, and additional PDF links can be created according to the docs[1]. It is a bit trickier with mm. I was able to create a PDF outline using a tip by T. Kurt Bond[2], and a link using the .pdfhref macro – but only with the native gropdf (groff -Tpdf), which creates really large files (> 500k). The output of pdfmom, on the other hand, can be piped to ps2pdf without losing the PDF outline or links (output size: ~ 80k). Is it possible to - create small PDF files (via pdfroff or groff | ps2pdf) while keeping PDF outline/links using the mm package? - create links from the TOC to the document headings/sections automatically using mm? - Jan [1] https://www.schaffter.ca/mom/pdf/mom-pdf.pdf [2] https://tkurtbond.github.io/posts/2021/07/15/troff-memorandum-macros-documentation/
Re: Re: Enumerator spacing in bullet lists with mom
On 2024-04-16 13:57, Thomas Dupond wrote: > Le 2024-04-16 à 12:18, Jan Eden a écrit : > > [...] > > > > > > You could do something like this: > > > > > > .LIST USER "\[bu]\h[0.3c]" > > > .ITEM > > > First item > > > .ITEM > > > Second item > > > .LIST OFF > > > > That works, thank you (although it is a bit of a hack, and I expected a > > more structured option to control the spacing)! > > If this is to much to bare you can hide it under the carpet with your own > macro like such: > > .de maListe > .LIST USER "\[bu]\h[0.3c]" > .. > .maListe > .ITEM > First item > .ITEM > Second item > .LIST OFF > > Or if you want to be able to change it on the fly you can do: > > .de maListe > .LIST USER "\[bu]\h[\\$1]" > .. > .maListe 0.3c > .ITEM > First item > .ITEM > Second item > .LIST OFF > > Have fun :) Nice – thanks again! I am afraid I came across as overly demanding, whereas I was just genuinely surprised that the mom .LIST macro does not provide a "native" way to change the spacing. - Jan
Re: Re: Enumerator spacing in bullet lists with mom
On 2024-04-16 10:04, Thomas Dupond wrote: > Le 2024-04-16 à 09:49, Jan Eden a écrit : > > [...] > > > > > You can see what a list should look like thanks to the document > > > "mon_premier_doc.pdf" provided with your groff install. > > > > > > On my debian system it is present at > > > /usr/share/doc/groff/examples/mom/mon_premier_doc.pdf.gz > > > > Thanks – this document displays the same (minimal) spacing I described > > above. > > > > > In case you do want to modify the spacing you can follow the > > > documentation: > > > > > > - locally at > > > file:///usr/share/doc/groff-base/html/mom/docelement.html#list > > > - online at http://www.schaffter.ca/mom/momdoc/docelement.html#list > > > > I did read the documentation on lists, but I only found a > > argument to the .ITEM macro, which refers to the vertical spacing > > between list elements. > > You could do something like this: > > .LIST USER "\[bu]\h[0.3c]" > .ITEM > First item > .ITEM > Second item > .LIST OFF That works, thank you (although it is a bit of a hack, and I expected a more structured option to control the spacing)! - Jan
Re: Re: Enumerator spacing in bullet lists with mom
Salut Thomas, On 2024-04-16 09:13, Thomas Dupond wrote: > Hello Jan, > > Jan Eden a écrit : > > Hi, > > > > I am currently testing the mom and mm macro packages, and noticed that > > mom uses sensible defaults for almost anything out of the box. > > > > Bullet lists (or lists with other static enumerators like dashes), > > however, are set with very little space between the enumerator and the > > item text. This is not true for ALPHA or DIGIT lists, which are set very > > well. > > > > I wonder if I am doing something wrong – because the spacing looks really > > bad in an otherwise properly formatted document – and how the spacing can > > be changed manually (in case I did not do anything wrong). > > > > This is my test file: > > > > [...] > You can see what a list should look like thanks to the document > "mon_premier_doc.pdf" provided with your groff install. > > On my debian system it is present at > /usr/share/doc/groff/examples/mom/mon_premier_doc.pdf.gz Thanks – this document displays the same (minimal) spacing I described above. > In case you do want to modify the spacing you can follow the documentation: > > - locally at file:///usr/share/doc/groff-base/html/mom/docelement.html#list > - online at http://www.schaffter.ca/mom/momdoc/docelement.html#list I did read the documentation on lists, but I only found a argument to the .ITEM macro, which refers to the vertical spacing between list elements. - Jan
Enumerator spacing in bullet lists with mom
Hi, I am currently testing the mom and mm macro packages, and noticed that mom uses sensible defaults for almost anything out of the box. Bullet lists (or lists with other static enumerators like dashes), however, are set with very little space between the enumerator and the item text. This is not true for ALPHA or DIGIT lists, which are set very well. I wonder if I am doing something wrong – because the spacing looks really bad in an otherwise properly formatted document – and how the spacing can be changed manually (in case I did not do anything wrong). This is my test file: .PAPER A4 .TITLE "Some Title" .AUTHOR "Jan Eden" .PRINTSTYLE TYPESET .FAMILY Garamond .START .HEADING 1 "First Heading" .PP Some text ... .LIST .ITEM First item .ITEM Second item .LIST OFF Creating a similar document with mm (with the .BL macro) resulted in proper spacing. - Jan
