Re: groff 1.23.0.rc4 regression: ms vertical spacing

[G. Branden Robinson]

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