At 2023-04-15T23:08:12+0200, Christof Meerwald wrote: > Unfortunately, previously reported vertical spacing regression for ms > macro package is still present in 1.23.0.rc4.
No change in this behavior was expected for groff 1.23.0.rc4, as a persuasive case has not yet been made for changing it. If you're the same person who filed Savannah #64043[1], then I await a response to comments #6 and #7. If you're not that same person, then I recommend perusing the many directions that ticket took in an effort to brand groff ms's behavior as deviant, and then selecting one, and only one, issue at a time to pursue. > For the document: > > .nr PS 12p It's unusual to change the type size of a document from the default without also updating the vertical spacing. The rule of thumb is that a vertical spacing of 120% or more of the type size prevents a document's text from feeling "crowded" to the reader. I therefore recommend a vertical spacing of at least 12*1.2 points. .nr VS 14.4p This is significant if you're interested in portability; while groff ms will update the vertical spacing to 14p to accommodate the larger PS value in the absence of an explicit VS setting, DWB 3.3 ms and Heirloom Doctools ms will not. [reordered] > And as has previously been pointed out, this regression affects > real-world documents. Which one(s) did you have in mind? groff ms's incrementation of vertical spacing by 2 points if the type size in the PS register is larger than 10 points dates back to the dawn of our repository's history, groff 1.02 in June 1991. You may, if you choose, interpret that, too, as a regression that affects real-world documents. > .nr DD 0p > .LP > A \n[nl] > .NH > B \n[nl] > .EQ > C \n[nl] > .EN > .NH > D \n[nl] > .LP > E \n[nl] > .DS > F \n[nl] > .DE > .NH > G \n[nl] > .LP > H \n[nl] > > formatted with "groff -Tpdf -e -ms" I have attached the generated PDF > files for groff 1.22.4, 1.23.0.rc4 and a fixed version of 1.23.0.rc4 > (together with the fix). Did you re-run the test suite after applying your patch? What was the outcome? Pulling back from the trees a little bit to look over the forest, I can see a reason for displays (and equations displayed with EQ/EN) in ms documents to permit pre-heading space to accumulate with inter-display distance.[2] I don't see a reason for it to accumulate with inter-paragraph distance. If a display is to be "inlined" within a paragraph, ".nr DD 0" (and restoration to the previous DD value after the display) seems like a straightforward and intuitive approach given the _macro package's_ documentation--leaving aside what knowledge of formatter internals an ms document author might possess. As noted in comment #6 to the aforementioned bug, I think more explicitness in the macro package's documentation about vertical space handling would be worthwhile, but my proposals along these lines have drawn no comment from you. Regards, Branden [1] https://savannah.gnu.org/bugs/?64043 [2] For that matter, we could expose a new register to enable user control of pre-heading vertical space.
signature.asc
Description: PGP signature
