Follow-up Comment #3, bug #68299 (group groff): At 2026-04-30T16:19:52-0400, Deri James wrote: > Follow-up Comment #2, bug #68299 (group groff): > > On Thursday, 30 April 2026 19:51:36 BST you wrote: >> What distinguishes this ticket from bug #67665? Does this one >> supersede the earlier one? > > That bug concerned pdfms.tmac which operated as an addon (in the same > way as spdf.tmac was an addon to pdfmark.tmac, which required the user > to use the newer NH/XN combination rather than the original NH to > create bookmarks).
Ahhhhaaaaa. </TomBaker> > Given that most historical ms documents would use NH (with XS/XE if a > TOC was required), I wanted to make s.tmac support them without adding > non roffish flag letters to macro calls. The use of ".pdfhref M" to > "mark" a position in the document is unfortunate, I would prefer a > native ms macro such as:- > > .XM name [text] > > instead. I share your preference. > This could also obviate the need for dual working tricks based on > testing PDFFEAT. I didn't feel confident whether extending the s.tmac > repertoire of commands was really my choice. groff_ms(7) (and of course ms.ms) documents many extensions. Some are Berkeley's, some are Unix V10's, and some are ours. Further, groff ms doesn't work in compatibility mode, so a hard-bitten legacy document written in old-school ".dsabcd" style won't work anyway. I've had some exchanges on this subject with Clem Cole, who is using groff to render some early Unix System V-era man(7) and ms(7) documents with groff, to incomplete success. Reinforcing existing good idioms is desirable. Relieving the document author of having to repeat themselves is too. I largely liked Keith's `XN` and `XH` extensions, which reduced the amount of labor required by the document author to get section headings into the table of contents. (Why only "largely"? I don't completely understand the motivation for `XN-REPLACEMENT`, when one can replace `XN` itself. And I regret that there's no ability to suppress the leader dots, as one might desire for bridgeheads. Keith also parameterized `TC-LEADER` as a string, but it's reset only at each TOC in toto, and so is not configurable for the bridgehead application.) > The pdfms bug was the "breeding ground" for the code in this bug, and > allowed you to straighten out the numerous bugs in .asciify upon > which this code relies. So, it does supercede the original bug. Okay. Is there any reason not to resolve that one? >> Revising Summary; see >> [https://lists.gnu.org/archive/html/groff/2026-04/msg00061.html >> mailing list cogitation]. > > I'm happy. Although I must admit to being a bit flummoxed, but if you > are happy to zoom in and correct my mistaken tags, I shan't worry. Doesn't bother me to tidy them up. I can easily keep pace with the influx of groff Savannah tickets, as evidenced by the fact that I've submitted 649 of the 1,801 filed to date. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?68299> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
