the 'SS' (slanted symbol) font (was: Original print of V7 manual? / My own version of troff)

[G. Branden Robinson]

Hi Tadziu,

At 2024-01-08T20:38:52+0100, Tadziu Hoffmann wrote:
> > AT&T troff was engineered around the assumption that the
> > lowercase Greek letters typically used for mathematical and
> > scientific typesetting are slanted/italic rather than upright.
> > This assumption is baked into the semantics of special
> > character names *a, *b, *g, and so forth.
[...]
> It is not,

I don't think I've ever had to occasion to contradict you before.

I say it _is_.  Look at Ossanna's CSTR #54.

Source:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/doc/troff/table1

Rendering:
[see attached image, from a scan of Volume 2 of the Seventh Edition Unix
Programmer's Manual]

The ordering of the S and SS fonts is immaterial here because the C/A/T
_had_ no SS font.

Nor do I see any of evidence of an "SS" font for _any_ device in
Documenter's Workbench 3.3 troff.[1]

Barring evidence of pre-groff usage, then, I submit that the slanted
symbol font must be a groffism.

> > [...]
> > If you couldn't guess, I plan to change this in groff.
> and nothing needs to be changed.

I disagree, because nroff output is incorrect, failing to render
lowercase Greek letters in italics when troff output _does_.

$ cat ATTIC/double-angle-identity.roff
.EQ
sin ( 2 theta ) ~ = ~ 2 ~ sin theta cos theta
.EN
$ eqn -Tutf8 ATTIC/double-angle-identity.roff | nroff | head -n 1
sin(2θ)=2sinθcosθ

One will of course have to run the foregoing example oneself to verify
my claim about the typeface, as any change wouldn't copy-and-paste into
my plain text email.

(Note to self: an eqn full space should render as a space on nroff
devices.  File a bug.)

> Which character (slanted or upright) groff uses simply depends
> on the mounting order of the fonts S and SS.

I suggest that you have identified the _mechanism_ by which groff
developers ages ago (probably James Clark) obtained AT&T-compatible eqn
output.

Further, nothing in eqn documents its sensitivity to the font mounting
order when determining the typefaces to be used.  In fact that
sensitivity overrides explicit configuration!

Source:
$ cat ATTIC/to-slant-or-not-to-slant.roff
.\" "letter" means "slanted" in GNU eqn
.\" This is actually redundant with the default configuration.
.EQ
chartype "letter" \[*a]\[*b]\[*g]\[*d]\[*e]\[*z]
chartype "letter" \[*y]\[*h]\[*i]\[*k]\[*l]\[*m]
chartype "letter" \[*n]\[*c]\[*o]\[*p]\[*r]\[*s]
chartype "letter" \[*t]\[*u]\[*f]\[*x]\[*q]\[*w]
.EN
.fp 5 S
.fp 6 SS
\(*A\(*a \(-> upright lowercase alpha
.br
.EQ
sin ( 2 theta ) ~ = ~ 2 ~ sin theta cos theta
.EN
.sp
.fp 5 SS
.fp 6 S
\(*A\(*a \(-> slanted lowercase alpha
.br
.EQ
sin ( 2 theta ) ~ = ~ 2 ~ sin theta cos theta
.EN

Rendering:
[see attached image]

> Example:
> 
>   .fp 5 S
>   .fp 6 SS
>   \(*A\(*a --> upright lowercase alpha.
>   .fp 5 SS
>   .fp 6 S
>   \(*A\(*a --> slanted lowercase alpha.

This is fine, but it's raw *roff, not eqn input.  I am concerned with
eqn output, and nothing I propose would break your exhibit above.

At 2024-01-10T02:10:12+0100, Tadziu Hoffmann wrote:
> > I never knew this.  Where is the reference please?
> > I would like to mention this in my new EQN manual.
> 
> The Troff User's Manual (section 2, "Font and Character Size
> Control") says:
> 
>   The troff character set is defined by a description file
>   specific to each output device.  There are normally several
>   regular fonts and one or more special fonts.
> 
>   Troff begins execution by reading information for a set of
>   defaults fonts, said to be mounted; conventionally, the first
>   four are Times Roman (R), Times Italic (I), Times Bold (B),
>   and Times Bold Italic (BI), and the last is a Special font (S)
>   containing miscellaneous characters.  The set of fonts and
>   positions is determined by the device description file.
> 
>   It is not necessary to change to the Special font;
>   characters on that font are automatically handled as if
>   they were physically part of the current font.  The Special
>   font may actually be several fonts; the name S is reserved
>   and is generally used for one of these.  All special fonts
>   must be mounted after regular fonts.
> 
> However, it does not explicitly say that the special fonts
> are searched in mount-position order.  (I think it is a
> reasonable assumption, but I may be biased.)
> 
> The groff Info file (section 5.17.4, "Using Symbols") is more
> specific:
> 
>   Here are the exact rules how 'gtroff' searches a given symbol:
> 
>    [... current font and explicit declarations using
>      .char and .fspecial ...]
> 
>    * As a last resort, consult all fonts loaded up to now for
>      special fonts and check them, starting with the lowest
>      font number.  [...]
> 
> Since both S and SS contain lowercase Greek characters, placing
> SS before S will result in gtroff picking the slanted alpha for
> \(*a, whereas placing S before SS with pick the upright alpha.
> (Unless of course the current font also contains a \(*a character,
> in which case this will be used, or any other font declared
> as special and containing \(*a is mounted before S and SS.)

I don't propose to change any of this.  It seems to work well and can be
apprehended by users.

> A reasonable default would be:
> 
>   1-4: R, I, B, BI    (standard text fonts)
>   5:   CW             (computer/monospaced)

Heavens no!  "CW" is a System-V-ism.  We have CR, CI, CB, and CBI.

https://github.com/Perl/perl5/issues/21239

>   6-9: SS, S, ZD, ZDR (special)
> 
> but this is simply convention, it is not hardcoded into groff
> (and can be modified by specifying a different DESC file with a
> different setup via the GROFF_FONT_PATH environment variable).

Yes.  That's a nice flexibility feature.

> I believe the leading empty positions in the "fonts" declaration
> of groff's DESC files are related to groff's extension using
> "styles" and "family", which the original troff did not have.

Interesting!  I had never seen a hypothesis, let alone an explanation,
forwarded for that before.  It has occurred to me multiple times to
change it to see what would break, so that I could then document it, but
I never got around to the experiment.

> > Where goes groff and eqn configure their font positions?
> 
> eqn itself doesn't set up any fonts, it simply requests fonts by
> name or number (as specified by "gfont", "grfont", and "gbfont",
> by default "I", "R", and "B", and maybe overridden by eqnrc or the
> document itself) and characters by name (via builtin translation
> tables or as declared via "define": "alpha" --> "\(*a" etc.).

Because eqn uses Greek letters as mathematical symbols rather than
linguistic text, I think it is reasonable for it to explicitly access,
without loss of generality, upright and slanted symbol faces for "Alpha"
and "alpha", respectively.  I claim that by defining these keywords
(really macros, in the eqn language, except in GNU eqn, out of
laziness or optimization their defaults are set up in the lexer[2][3]),
they acquire _semantics_.  For practical purposes, the lowercase Greek
letters become slanted.

In fact, I am tempted to rename the "character types" in GNU eqn from
"letter" and "digit" (the latter being unused) to "slanted" and
"upright", respectively.  (Recognizing the old names for backward
compatibility, yadda yadda yadda.)

In some context that you trimmed away, I mention that accessing glyphs
by "busting down" to *roff special character escape sequences in eqn(1)
input would not be affected by my proposed change.  In other words, they
_would_ be sensitive to reordering of font mounting positions.  But this
seems entirely proper.

> Troff tries to satisfy these requests using the fonts it has
> available/mounted, by default those from the device description
> file DESC, possibly modified by troffrc (and whatever this in
> turn reads), the macro package, and the document itself.

I don't propose to change GNU troff with respect to these matters, but
rather GNU eqn.

[1] https://github.com/n-t-roff/DWB3.3/
[2] 
https://git.savannah.gnu.org/cgit/groff.git/tree/src/preproc/eqn/lex.cpp?h=1.23.0#n174
[3] This in turn means that the definitions of the eqn Greek-letter-name
    macros will _have_ to come out of the lexer and be put in
    eqn-device-specific startup logic--in eqnrc, say--so that the code
    can be appropriately conditionalized.  Only the "ps" device has
    (though, soon, "pdf" will have) a font called "SS" by default.

    So I envision something like this in eqnrc:

ifdef utf8 ! define Alpha \*(A !
ifdef utf8 ! define ALPHA \*(A !
ifdef utf8 ! define alpha \fI\*(a\fP !

ifdef ps|pdf ! define Alpha \*(A !
ifdef ps|pdf ! define ALPHA \*(A !
ifdef ps|pdf ! define alpha \f(SS\*(a\fP !

   ...and so on for the other 23 Greek letters.

cstr_54_1976_table_1.png
Description: PNG image

to-slant-or-not-to-slant.ps
Description: PostScript document

signature.asc
Description: PGP signature