"G. Branden Robinson" <invalid.nore...@gnu.org> writes: >> I think I have two options for the upcoming podlators 6.0.0 release:
>> * Do nothing. Justification will be broken with groff 1.23 and fixed with >> groff 1.24, which will hopefully make it into the trixie release. >> * Add ".if n .ds AD l" to the preamble, and leave ".if n .ad l" after .TH >> as is. This will make the formatting work everywhere the way that it >> historically has (although will get pod2man output no closer to >> supporting AD properly) and means that the time frame for groff 1.24 >> becomes irrelevant to podlators, at the cost of an additional line in >> every generated man page. [...] > I think Russ went with option (2), which is good because sure enough > _groff_ 1.24.0 is not available for inclusion in Debian trixie > (scheduled for 9 August 2025). Correct. podlators v6.0.0 and later now add ".if n .ds AD l" to every generated page. > My plan is for (1) _groff_'s _man_ (and _mdoc_) packages to check at > package initialization time for defined `AD` string (and defined `HY` > register). **If these exist**, they necessarily represent the user's > preferences (since they weren't read from a document) and are each > copied to a shared private name (prefixed with "andoc*" to communicate > this shared status; (2) upon encountering any new _man_ document at a > `TH` macro call, or new _mdoc_ document at a `Dd` macro call, these > saved user preferences are reasserted to configure the document's > rendering, and existing `AD` and `HY` objects removed; (3) page-local > assignments of `AD` and `HY` continue to be honored as before, and (4) > at every new section, subsection, and paragraph, adjustment and > hyphenation modes are reset to the page's preference if configured and > the user's otherwise. I like the combination of (1) and (2) as a solution for this problem and agree that this should work with podlators. I think the important part for podlators going forward, given this behavior, is to make sure that the ".if n .ds AD l" line stays in the preamble (in other words, before .TH) so that groff can reassert user preferences at .TH and not be confused with (3). That's easy enough (and natural) to do. I have no well-informed opinion about whether (4) is the right thing to do. I feel like that isn't how groff used to behave; changes to hyphenation and adjustment used to persist throughout the page. I'm not sure what problem was being solved by changing that behavior but I'm happy to trust you on that now that we have a mechanism for the page to specify a preference. My main remaining concern about (4) is that it sounds like you're planning on re-enabling hyphenation in the middle of the page. I am trying fairly hard to turn off hyphenation since in my experience the results of hyphenation are confusing and bad for technical documents. (Among other things, the hyphens are easy to confuse with ASCII hyphen-minus and interfere with cut and paste in some situations, and I also have no way of knowing the language the page is written in and English hyphenation rules may be completely wrong.) If the user really wants it and wants to override the page, that is, of course, fine. Do I also need to start doing something with the HY register in order to set a preference for no hyphenation going forward? > I'm uncertain how prominently I want to document the last fact. My own > preference regarding man page authorship practices is that documents refrain > from trying to manipulate these formatting parameters. And of course my preference is that software intended for output in terminals not use typesetting techniques like justification and hyphenation that were designed for typeset pages with fine-grained control over interword spacing and which, in the case of hyphenation, were intended as input to a human process that adjusted the hyphenation rules for the specific needs of that static layout of the document, something that will never apply to man pages formatted on wildly varying devices with wildly varying widths. But the art of living in a civilization is finding useful compromises with people who don't realize that they're wrong about everything they disagree with us on. :) -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
