Hi Dave! At 2022-04-03T07:32:34-0500, Dave Kemper wrote: > [log entry:] > > It was probably unnecessary to hedge against future changes in > > standard typographical vertical spacing. The 120% ratio > > convention is older than I am and I expect it to long survive > > me. > ... > [added text:] > > +In ordinary circumstances, this quantity is 120% of the type size. > > This sentence feels a little misleading. As your commit log entry > points out, this is the *typographic* convention. But this sentence > appears in groff documentation, and nothing in groff makes this 120% > "ordinary": the user must explicitly specify a .vs value that is 120% > of her .ps value in order to make this true in troff. Just as likely, > the user will specify both of these values as integers (e.g., 12p and > 14p), which works out to close to but not precisely 120%. (As noted > in the http://savannah.gnu.org/bugs/?61710 discussion, groff itself > and many full-service macro packages lack a built-in mechanism to set > the line spacing as a given percentage of the type size; -me and -mom > are two exceptions that do enable this.) > > The ratio of the startup values of these two quantities is 120%, but I > don't think "by default" and "in ordinary circumstances" are > synonymous; the latter phrase can be construed as saying that groff, > in at least some circumstances, maintains this percentage after a > change to the type size.
Fair point. > One alternate way to phrase this (if you're not happy with reverting > to the original wording) could be, "Traditionally, typesetters have > set this quantity to 120% of the type size." This acknowledges both > the typographical precedent you cite in the commit log, and the fact > that the user must explicitly make it happen in groff. I like this. My only worry regarding it is that I've got pleasant page breaks in this part of the typeset form of our Texinfo manual, so I might have to economize output lines. This is a welcome distraction from the build system clean-up stuff that Ingo and I have been quietly working on for the past few days. I still have about 10 commits of that to push. And then some more to address Savannah #62084 properly[1]. (Long story short, we need font/device description directory stamp files for each output device that generates any such files at build time and for which we render groff documents in the build tree, and documents so rendered need to declare dependencies on these stamp files. Some of this is already done, but the naming practice is haphazard and I am not convinced that the dependencies are declared everywhere they should be. The Savannah ticket is suggestive evidence that they're not. Build succeed more often then they have a right to because of an old practice of over-declaring dependencies on every executable that the build creates.) This stuff costs me six builds per commit to test--huge pain in the ass. Documentation fixes are a cool drink of water by comparison. Regards, Branden [1] https://savannah.gnu.org/bugs/?62084
signature.asc
Description: PGP signature
