[dropping Guillem from CC, as I'm replying only to auxiliary points] At 2026-09-20T23:15:48-0400, Larry Kollar wrote: > I seem to remember FrameMaker having some hyphenation glitches, > probably in the version 6.x era; but when I ditched it for groff[1], I > set `.hy 14` and only rarely had to make corrections. [...] > If you’re writing long-form[2] (i.e. not -man or -mdoc) documents in > groff, it’s not difficult to set up a hyphenation library and have all > your documents call it (since most people extend -ms to produce PDFs > with groff, you can include your hyphenation preferences automatically > or turn it off completely if that’s your preference). Each house has > its own house style, and it’s not cool to make it difficult for ten > houses because one house insists on doing things different. [...] > [1] TBH, that was in response to Adoobie deciding it was “too > difficult” to port Frame to OSX; but moving to groff reduced > formatting times from about four hours to 3 minutes (two passes on a > blue Mac G3).
Nice!
> No longer did I have to decide whether that formatting glitch was
> worth another half day to fix.
I live in fear of the day someone besides Deri hits the "9,000%
slowdown" I apparently wreaked on PDF bookmark resolution time.
> [2] I’ve heard some people argue that -ms is really meant for
> mid-length documents, and -mm is the true long-form macro package.
I'm pretty familiar with both packages. I can't credit that claim.
> But just about everyone extends -ms to suit their local needs, and I
> regularly produced a 1000-page document using my own -ms extensions
> until customers asked me to break it into four separate documents.
My view is that mm(7) is better suited for people who either (a) needed
to write AT&T internal corporate memoranda in divisions of the company
where failure to adhere perfectly to the prescribed stylesheets
resulted in encumbrances on one's career progression; or (b) greeted the
prospect of writing and maintaining their own macros with fear.
In my reply to Sébastien earlier today,[A] I neglected to mention that
tricks like I illustrated could be bolted onto existing use of the ms(7)
package by appending to the package's existing macros.
Thus:
.am HD
.nr ux 0
..
.am NH
.nr ux 0
..
.am SH
.nr ux 0
..
I have an impression that macro appendment is underutilized in
real-world documents, even where it could be used to great advantage.
On the other hand, our backtrace mechanism isn't designed with it in
mind, and can produce misleading output.
$ nl ATTIC/am-upsets-backtrace.roff
1 .de foo
2 .nr a 1
3 .nr b 2
4 ..
5 .am foo
6 .nr c 3
7 .nr d 4
8 .nr \e 5
9 ..
10 .foo
$ nroff -b ATTIC/am-upsets-backtrace.roff
troff: backtrace: 'ATTIC/am-upsets-backtrace.roff':6: macro 'foo'
troff: backtrace: file 'ATTIC/am-upsets-backtrace.roff':10
troff:ATTIC/am-upsets-backtrace.roff:10: error: expected identifier, got an
escaped 'e'; treated as missing
Fixing that would require elaborating the data structure that tracks
file and line number information, perhaps considerably.[B] In a future
development cycle, when I start replacing more of groff's bespoke
containers with STL ones, I might manage to fry that fish.
Regards,
Branden
[A] https://lists.gnu.org/archive/html/groff/2026-09/msg00060.html
[B] I think we'd need a vector of "location records", each storing a
file name, file line number, and line of the macro where the record
begins. This would also significantly complicate diagnostic
message reporting, and threaten to make it incompatible with the
format used by GCC, to which recent versions of groff conform (at my
instigation). That kind of sucks because lots of tools recognize
that format. On the bright side, we need only emit a
GCC-incompatible diagnostic format if the length of the location
record vector is greater than one. Ooh, ooh--possibly macro
appendments could become additional records in the backtrace. This
idea might be rescuable after all.
signature.asc
Description: PGP signature
