Re: units used in `ss` request (was: device-dependent warnings)

[G. Branden Robinson]

[self-follow-up]

At 2023-05-13T02:03:11-0500, G. Branden Robinson wrote:
> At 2023-05-10T12:28:02-0500, Dave Kemper wrote:
> > On 5/10/23, Dave Kemper <saint.snit@gmail.com> wrote:
> > > Nonintuitively, .ss's units aren't in fractions of standard
> > > typographical measurements, but 1/12 of the current font's
> > > ordinary space.
> > 
> > And I just learned (or maybe relearned) this is a deviation from
> > AT&T troff's .ss units, which are a fixed 1/36 em.

I am beginning to think that it was only Ossanna troff for which that
was true, and CSTR #54 was simply never updated in this respect.  My
copies of the 1976, 1981, and 1992 versions all have identical text
documenting the `ss` request, except for the 1992 revision adding
"(i.e., inter-word gap)".

In device-independent troff, whether the space width is 1/3rd of an em
is entirely up to the font description file.  In DWB 3.3 troff,[1] for
the "post" device (a.k.a. dpost, for PostScript), for the Times roman
font "R", "M" has a width of 89, and the "spacewidth" is 25.  For
Helvetica (roman), "M" is 83 units wide, but the "spacewidth" is 28.

So an `ss` default of "12/36 em" cannot possibly be accurately
descriptive of device-independent AT&T troff fonts in general.[2]

> It would therefore appear that groff is not deviating from AT&T
> behavior here, but using 36ths after all, and our documentation is
> wrong (and has been for a long time).

I'm happy to say I can retract the last part of that.  In reviewing
doc/groff.texi, groff(7), and groff_diff(7), I see no misstatements in
this area.

Nevertheless I'm preparing some clarifications for groff's `ss`
documentation.

Regards,
Branden

[1] the closest thing I have to sources for "Unix 4.0" Kernighan troff

[2] Technically, one "em" equals "the current type size in points", not
    the width of the capital letter "M" glyph.  This observation does
    nothing to rescue the language in CSTR #54.  DWB 3.3's devpost/DESC
    file says that the device resolution is "720" and that the the
    "unitwidth" is 10; the latter means that "[q]uantities in [its] font
    description files are in basic units for fonts whose type size is
    [10] [] points."[3]  This doesn't change the analysis as far as I
    can tell.  One third of 72 is 24, and that's not the space width for
    Times (roman) _or_ Helvetica (roman).

[3] groff_font(5) on the master branch since late 2021

signature.asc
Description: PGP signature