groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] 19/25: [docs]: Be specific re: default vertical spacing.


From: G. Branden Robinson
Subject: Re: [groff] 19/25: [docs]: Be specific re: default vertical spacing.
Date: Mon, 4 Apr 2022 03:43:37 +1000
User-agent: NeoMutt/20180716

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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]