Follow-up Comment #5, bug #64043 (project groff): Assuming for the sake of argument that the same "anonymous" is replying as filed the initial report...
[comment #2 comment #2:] > In your screenshots I see 13 pixels vs. 26 pixels of vertical space > before "Rule: Braces can always be..." - this seems significant to me (and I thought that difference was obvious enough). The magnifications of the two windows is slightly different, and may not be a reliable guide. troff output (before post-processing) would be more informative. But that is still somewhat beside the point. There is no specification of whether interdisplay distance should accumulate with other sources of vertical space, and my recollection is making the change improved the document's rendering in other respects. (Otherwise, I wouldn't have bothered.) > I fail to see the relevance of "the equation at lines 437 to 439 is absent, and the top of the next column not correctly aligned (see bug #62686)" in the context of this bug report. Then let's return to... [comment #0 original submission:] > Other examples of documents that are negatively affected by that change can be found in https://github.com/n-t-roff/Plan9_troff/tree/master/sys/doc This remark ruled in three unrelated documents; I think content on the same column of the same page of the same document is well within scope. But I think the objective here is to keep shifting the goal posts until I revert the change, and you will cast about for rationales until you can find one. This is the only explanation I can imagine for your utter indifference to the complete loss of text in the original document when formatted by AT&T Version 7 Unix troff. Rewrite your document to resort to formatter requests as little as possible, and only where the macro package exposes no locus of control for the typesetting feature in question. This is how macro packages have always worked, and it is a lesson that *roff users have imparted to each other with increasing emphasis over the years. Allman's _me_ documentation rules in a limited set of formatter requests that "can be used with impunity" (importantly, even then only _after_ an _me_ macro call to initialize the package) and the DWB 3.3 _mm_ manual says that "one seldom needs to use these requests directly". groff man(7), mdoc(7), and mandoc(1) discourage the use of requests at all (the last, strongly). Peter Schaffter's mom(7) package interposes its comprehensive interface between the formatter and the document. People learned the hard way that they get into unportable trouble when mixing formatter requests with calls to the macros of full-service packages. If you want to format Plan 9 documents _precisely_ as Plan 9 does, I suggest using Plan 9's troff. In the meantime, you may wish to respond to the people who offered feedback on the groff ms(7) changes at the time, to point out how poor their vision or judgment was. https://lists.gnu.org/archive/html/groff/2022-07/msg00000.html _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?64043> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
